Operating principles
The principles that keep AI-assisted software development developer-owned, bounded, preservation-first and verifiable.
TCAF is built from explicit operating principles rather than a collection of unrelated prompts. The principles define how an AI tool should behave across project analysis, planning, implementation, verification and reconciliation.
They are intentionally broader than any single adapter. Some have been exercised directly in verified scenarios; others are framework-aligned rules whose coverage still needs to be extended across more models, tools and project conditions.
Developer authority and direct authorship
The developer or development team remains the technical authority and active author of the software. They may write, change, delete, reorganize or replace code directly whenever engineering judgement requires it.
The AI does not become the owner of implementation while the developer merely approves or rejects generated output. It receives a bounded assignment and assists the same engineering process already controlled by the team.
Developer changes are authoritative current state. The agent must re-read them, preserve them and integrate with them unless the developer explicitly asks for a different result.
Explicit authorization boundaries
Every consequential task should define what the AI is authorized to inspect, change and report. The Task Contract also identifies preserved areas, acceptance criteria, checks and stop conditions.
The boundary applies to the AI, not to the developer. A developer can intervene anywhere, alter the approach or redefine the task. The AI cannot treat that freedom as permission to broaden its own scope.
Inspect before acting
TCAF requires the agent to observe the actual project instead of filling gaps with assumed architecture, conventions, commands or capabilities.
For an existing project, this means inspecting the relevant files, existing documentation, project structure, nearby implementation patterns, current changes and available verification procedures before proposing or applying a change.
The inspection remains pertinent: the agent should gather enough context to execute the task safely without turning every request into an unbounded repository audit.
Preservation-first and local consistency
When modifying an implemented area, the agent integrates with the working software rather than treating it as material to rewrite. Existing functions, methods, services, validations, guards, utilities, error handling, state-management patterns, naming and folder conventions are the default implementation vocabulary.
A theoretically cleaner abstraction or more modern technique is not sufficient reason to replace local code. New instructions are added where the requested behaviour requires them; working logic is not merged, optimized, generalized or restructured opportunistically.
Preservation-first does not prohibit refactoring. It requires refactoring to be an explicit, justified and authorized objective rather than an unrequested side effect.
Minimum necessary change
The implementation surface should remain as small as the requested result permits. This reduces unintended behaviour changes, review cost and uncertainty about the origin of modifications.
Minimal does not mean superficially small. A correct change may involve several files when the project architecture requires it. The rule is to avoid unrelated edits and speculative improvements, not to force every task into one line.
Whole-process continuity
TCAF connects analysis, architectural understanding, planning, task authorization, implementation, verification, review and status reconciliation.
Project documents and task records are not disposable prompt context. They provide continuity between sessions, tools and contributors so that an agent does not need to reconstruct the project from conversation memory alone.
Small, reviewable steps
Large objectives should be decomposed into bounded units whose intent and result can be understood. Each unit produces a checkpoint at which the developer can review, intervene, amend the contract or select a different next action.
This makes progress observable and prevents a large autonomous execution from hiding multiple unreviewed decisions.
Evidence over claims
The agent must distinguish a result it generated from a result that has been verified. Commands actually executed, manual checks requested from the developer and unresolved limitations must be reported separately.
Outcome labels such as PASS, READY FOR CHECK, PARTIAL, BLOCKED and FAIL communicate the real verification state instead of rewarding a confident final message.
Tool resilience
The operating model must remain useful when an adapter cannot execute commands, request an approval correctly or access a required interface.
The Task Contract can therefore specify the smallest relevant commands or manual procedures for the developer to run. An inability to automate a check must be reported as a limitation, not hidden or converted into an invented PASS.
Model and tool independence
TCAF defines an operating contract rather than depending on a specific model, IDE or agent product. Adapters transport the same principles through different interfaces and document where their capabilities differ.
Model independence does not imply identical behaviour. Each adapter and model combination still requires validation, and unsupported capabilities must remain explicitly unsupported.
Explicit classification of change during a task
Not every new instruction should silently mutate an active contract. TCAF distinguishes clarification, correction of non-compliance, local technical adaptation, amendment, separate task, blocker and collateral issue.
This protects both flexibility and traceability: the developer can change direction at any time, while the agent must identify how that change affects the authorized work.
No implicit capability expansion
A task should not introduce a new testing framework, dependency, service, deployment mechanism, broad refactor or project convention merely because the agent considers it useful.
Capabilities outside the existing baseline require an explicit decision. This keeps the implementation aligned with the real project rather than with an imagined ideal environment.
Honest maturity and validation status
The framework should never present a designed procedure as universally proven. Documentation pages carry separate workflow and editorial states so readers can distinguish verified scenarios, limitations, framework-aligned procedures, planned capabilities and unsupported operations.
The purpose is not to diminish the framework, but to make its evidence and remaining validation work visible.