From 23c08008ef4427dffb2d8df2ab4dbfd40a68acb7 Mon Sep 17 00:00:00 2001 From: Varun Katta Date: Mon, 28 Sep 2026 21:45:34 -0700 Subject: [PATCH] docs(operating-model): projects keep named, versioned launch prompts Co-Authored-By: Claude Opus 5.5 --- operating-model/agent-work-loop.md | 2 ++ operating-model/decision-log.md | 1 + 2 files changed, 3 insertions(+) diff --git a/operating-model/agent-work-loop.md b/operating-model/agent-work-loop.md index 216aa0f..44b16e9 100644 --- a/operating-model/agent-work-loop.md +++ b/operating-model/agent-work-loop.md @@ -163,6 +163,8 @@ transition, then stop. and merge rules). - A project states its values in one table, titled "Overrides of the env work loop", and links to this file. - If a project file and this file disagree on a rule, this file wins. Fix the project file. +- Projects keep their launch prompts as named, versioned files in the repo, with an index. A launch is one line naming + the prompt and its path, plus parameters. The run report names the prompt version it ran. ## Project-set parameters diff --git a/operating-model/decision-log.md b/operating-model/decision-log.md index 7c4534c..8cad8f6 100644 --- a/operating-model/decision-log.md +++ b/operating-model/decision-log.md @@ -39,3 +39,4 @@ Status is intentionally explicit: | 2026-09-28 | Confirmed | Agents on a shared work board never go idle while work exists: finish reviews and repairs before starting a new task, and stop after a bounded number of empty re-checks. Projects inherit the protocol here and override only its parameters. | The owner asked that agents pick the next job instead of idling, with verification and repair ahead of brand-new work, and that projects inherit this protocol from here rather than keep a second copy. See `agent-work-loop.md`. | | 2026-09-28 | Confirmed | Long documents carry a table of contents with jump links | Sections with four or more `##` level headings get a TOC block right after the title. Automated tooling in projects regenerates and validates the TOC. See `working-style.md` and `agent-work-loop.md`. | | 2026-09-29 | Confirmed | The agent launched on a work board is a dispatcher: one fresh, clean-context sub-agent per job, one at a time, up to five jobs per run, then a full stop until a human says go. | Owner: "ideally, you want each agent to work with a clean context, then each agent is launching a sub-agent be the model then, so subagent finishes a bead and changes bead status and reports back to parent agent. parent agent at any point in only running a single sub agent. after the sub agent finished, the parent agent is lanching the next one in a loop, up to a maximum of five and then completely stop until human asks it go again for another five". The dispatcher only reads the board, claims, launches, reads the report and logs; the sub-agent does one job and makes its board transition. Refines the 2026-09-28 work-loop row: the loop and priorities stay, the agent that runs them changes. See `agent-work-loop.md` sections 2, 3, 4 and 6. | +| 2026-09-29 | Confirmed | Projects keep their launch prompts as named, versioned files in the repo, with an index; a launch is one line naming the prompt and its path, plus parameters; the run report names the prompt version it ran. | The owner approved the lead's design ("go") for replacing pasted launch text with checked-in prompts, so a launch is repeatable and a report says which prompt version produced it. Adds to the 2026-09-29 dispatcher row. See `agent-work-loop.md` section 7. |