Engineering
The common thread in my work is not a language. It is a preference for explicit systems: local behavior, bounded failure, recoverable storage and architecture that says where each responsibility belongs.
Principles
Local-first is an operational promise
Local-first does not mean "sync later" as an afterthought. It means IDs, locks, storage paths, update checks and user workflows must all have a reasonable behavior when the network is not available.
Security defaults should fail closed
Secrets should be references, not manifest payloads. Paths should be canonicalized. Unsafe development bypasses should be impossible in production builds. Logs should redact secret-shaped values by default.
Architecture is a compatibility boundary
AppCore separates application manifests, deployment manifests and runtime manifests because ownership matters. The same idea appears in Traiteur: frontend intent is not the authority for local filesystem safety.
Performance before abstraction
The goal is not to avoid abstraction. The goal is to avoid abstraction before understanding writes, locks, memory, startup cost, IO volume, recovery paths and the operator's actual workflow.
Trade-offs must be named
AppCore deliberately does not ship RAFT, OAuth, a general database engine or a business workflow engine. Traiteur keeps a short human quote reference, but never treats it as a technical identity.
Tests are contracts, not decoration
The interesting tests are the ones that protect boundaries: manifest conformance, path safety, quote total validation, lock ownership, update signatures, storage package decoding and public SDK consumption.
How this appears in code
- Define the ownership boundary first.
- Keep infrastructure and business concepts in different modules or repositories.
- Make file formats versioned and reject unsupported inputs loudly.
- Use atomic write patterns for critical storage: temporary file, flush, sync, rename and parent directory sync when the platform supports it.
- Prefer deterministic IDs over central counters when offline creation matters.
- Build operational tooling: doctor commands, release gates, diagnostics, recovery scripts and documentation that an operator can actually follow.
A simple architecture map
Application code
-> public facade / commands / queries
-> runtime contracts
-> storage, security, sync, scheduler, ops
-> providers and host composition
The important part is not the diagram shape. It is the direction of knowledge: business code can ask for infrastructure, but infrastructure should not learn a customer's business vocabulary.
Where to read next
- AppCore Runtime shows the principle at runtime scale.
- Primland Devis Traiteur shows it in a real desktop workflow.
- Hardware shows why physical constraints keep influencing the software.
2026 © Daniel Netto. Todos os direitos reservados.