Developer code and generated code

The concern: if generation is failing and a developer simply writes the code themselves, what happens? What is the source of truth afterwards, does the platform understand the change, do the requirements reflect it, and how does the next developer know what is actually executing?

The short answer

While the platform manages the project, the source of truth for an application is the application service's tree on the project's engine fork. A developer edits that tree directly in the studio (a file explorer, an editor, Save, Build and deploy), and every save is a version. The next fleet change starts from the tree as it is, so a hand-written change is never overwritten by regeneration. Requirement status is re-derived from the running implementation, never from a document, so what the requirement list says is implemented is what the code implements. In place

What is not automated: a commit made in the exported git repository, outside the platform, does not flow back into the fork. The export is one-way. A team that wants git as the source of truth takes the delivery and works there; the platform then stops being the place the application is changed. Partial

Where the code is, and who may change it

Place	What it holds	Who writes it
The application service tree on the fork	The application's container definition and source, verbatim	The fleet from a Board card; a developer in the studio; an MCP client with the update tool
The fork's endpoint catalogue	Endpoints (tools, data operations, agent manifests, workflow code steps), each with a version history	The fleet; a developer in the studio; the Agents page for manifests
The project's configuration database	Sources, rules, mappings, declarations, requirement status	Every write is a commit with the author's e-mail
The project's private git repository	Every export as a commit: application services, endpoints as source, infrastructure, runbook	The exporter only

The first three are the source of truth while the platform manages the project. The repository is the record and the delivery.

The cycle

Generation. The fleet claims a card, reads the running service's tree, changes it, rebuilds and verifies it in a browser, and attaches evidence (screenshots, the commit, how it was tested) to the requirement's task.
Developer override. A developer opens the studio's application services page for the project, edits files in the editor, saves, and presses Build and deploy. The save is a new version of the service; the build is the same in-cluster image build the fleet uses. Nothing distinguishes a developer's version from the fleet's except the author.
Commit. The developer, or the next export, commits the state to the project's repository. Exports are attributed and every export commit names the version it came from.
Platform awareness. Two readers keep the project's account of itself true. The as-built reader derives a requirement's implementation status from the live application (the registered services and what each one does), so a requirement the developer's code satisfies is marked implemented and one the code no longer satisfies is flagged missing. The structure check runs after every completed card and re-checks every declared object (screen, service, workflow, agent, requirement) against its implementation. Both read code, never the specification. In place
The next generation. The fleet reads the tree as it now is. There is no stored "generated version" that it regenerates from; the change is a diff on the current tree, verified against the requirements and their tests. A requirement the developer's code already satisfies produces no work. In place

Requirements never regenerate

Once a project has a requirements version, later versions are deltas: a new requirement-source version yields a review of the changed passages only, and the rows it touches are reworked, never the list. Manual status overrides, human edits and task links survive every review. A requirement no longer supported by any source is flagged, never deleted. So a developer's hand-set status ("implemented by hand, see commit") stays. In place

How the next developer knows what is executing

Question	Where the answer is
What is running	The application services page: the current tree, the build log, the image the deployment runs, its hostname and health
Who changed what, when	The version history of the service and of every endpoint; the export commits in the repository
Which requirements the running code satisfies	Docs, Requirements: each row's status with the implementing service, its tasks and their evidence; the Structure page names any declared object whose implementation is gone
Whether it still works	The requirement-linked tests, run every fifteen minutes and after every deploy; the Status page

Two ways of working

Model	Source of truth	The platform's part	Standing
Platform-managed	The fork	Builds, changes, tests, documents, exports on demand; developers edit in the studio or through the update tool	In place
Repository-managed	The customer's git repository after delivery	None at run time; the delivery is complete and ordinary. A later change through the platform needs the repository state imported back into the fork first	Partial Import is manual (re-create the service from the repository tree with the update tool)

Still to do

Gap	Today	Next step
Pulling commits from the exported repository back into the fork	To do The exporter pushes; nothing pulls. A repository-side change is re-applied by hand through the update tool.	A repository sync: the exporter fetches the designated branch, diffs the application-service directories against the fork's trees, and writes the difference as a new service version attributed to the git author, then runs the structure check. The pieces exist (the exporter already clones and diffs for version listings); the missing part is the write-back and its conflict rule. The rule: the fork never overwrites a repository commit it has not seen.
A visible "changed by hand since the last card" marker on a service	Partial The version history shows the author; nothing summarises it on the requirement.	Surface the last human author and version on the requirement's implementation line.