Developer code and generated code

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

The short answer

While cortex manages the project, the source of truth for an application is the app 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. Requirements are re-derived from the running implementation, never from a document, so what the requirement list says is implemented is what the code implements. Available

What is not automated: a commit made in the exported git repository, outside cortex, 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; cortex 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 app service tree on the fork	The application's Dockerfile 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, requirements' status	Every write is a commit with the author's e-mail
The project's private git repository	Every export as a commit: app services, endpoints as source, infra, runbook	The exporter only

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

The cycle, concretely

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 App 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.
Cortex 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 backfill 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. Available
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. Available

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. Available

How the next developer knows what is executing

Question	Where the answer is
What is running	The App 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's check 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, stated plainly

Model	Source of truth	Cortex's part	Standing
Cortex-managed	The fork	Builds, changes, tests, documents, exports on demand; developers edit in the studio or through the update tool	Available
Repository-managed	Allvue's git repository after delivery	None at run time; the delivery is complete and ordinary. A later change through cortex would need 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)

What is not in place, and what we propose

Gap	Today	Proposal
Pulling commits from the exported repository back into the fork	Not built 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 `app-services/*` against the fork's trees, and writes the difference as a new service version attributed to the git author, then runs the structure backfill. The mechanism exists in pieces (the exporter already clones and diffs for version listings); the missing part is the write-back and its conflict rule. We would build it with a simple rule: the fork never overwrites a repository commit it has not seen.
A visible "changed by hand since 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.