Working from the owner's packs

A prompt pack is a brief the owner handed over: what was wanted, on a date, in an order. The repository keeps every pack byte for byte under campaigns/, and it does not execute them. What a pack asked for becomes the repository's own plan — milestones and issues under .ai/repo/project/ — and the plan is what a worker starts from. This page says how the two are connected, maps the packs of 2026-10-11 and 2026-10-12 onto the records master holds, and says where to begin.

For whom

• A worker picking up work. Start from an issue, not from a pack. The issue says what was measured, what to change and how it is decided; the pack is where to read why it was asked.
• The owner. Each pack below names the records that came of it, the master records its asks were folded into, and what in it was not planned because the repository already has it or has decided otherwise.
• A reviewer. A record cites its pack by path, so the brief behind a change can be opened.

How a pack becomes work

flowchart LR
  zip["a pack in ~/Downloads"] --> kept["campaigns/&lt;pack&gt;<br>kept byte for byte"]
  kept --> manifest["MANIFEST.sha256<br>and the index row"]
  kept --> measured["measured against the tree:<br>what exists, what is planned, what is decided"]
  measured --> records["milestones and issues<br>.ai/repo/project/"]
  records -- "cites campaigns/&lt;pack&gt;" --> kept
  records --> roadmap["roadmap, plan pages,<br>the UI's Work screen"]
  records --> github["GitHub milestones and issues<br>scripts/github-sync"]
  gate["scripts/ci/campaigns-check"] -. "bytes, index,<br>cited or unplanned" .-> kept
  gate -.-> records

1. Kept. The pack directory is copied in unmodified; campaigns/MANIFEST.sha256 records its bytes and campaigns/README.md its row.
2. Measured. Before anything is planned, each thing the pack asks for is checked against the tree and against the plan. Much of it usually exists already, some is planned by a record written from another brief, and some contradicts a decision the repository has made. None of those becomes a new issue.
3. Planned or folded. What remains is written as issues of about one pull request each, under the milestone master already holds for that subject where there is one. An ask that a master issue already plans is folded into that issue: its missing criteria are added there, and the record's why cites the pack file. Every record cites the pack file it came from.
4. Projected. The roadmap, the plan pages of the site, docs/PLAN_STATUS.md and the UI are derived from the records. GitHub receives them when scripts/github-sync --apply is run on the trunk.
5. Held. scripts/ci/campaigns-check fails when a record cites a pack that is not kept, when a pack is neither cited by a record nor named in .ai/repo/ci/campaigns-unplanned.txt with the reason, and when a line of that list names a pack a record has come to cite, so the list only shrinks.

The packs of 2026-10-11 and 2026-10-12, mapped onto master

These packs were first planned on 2026-10-13 by PR #1058 as ten milestones and sixty-three issues, which never landed. Master moved two weeks past that measurement and came to plan or deliver part of it from other briefs, so on 2026-10-30 each of those records was measured again against master 51b38035a71 and either carried under a master milestone, folded into the master issue that already plans it, or dropped because master delivered it. Carried records take new ids (I4480-I4511); the ids of 2026-10-13 are not reused.

Two later packs are planned elsewhere and say so in .ai/repo/ci/campaigns-unplanned.txt: majordomus-convergence-pack-2026-10-14 became I2700-I2709 and the issues campaigns/README.md lists, and majordomus-mission-control-pack-2026-10-22 became a-session-proceeds-through-the-mesh, I4000 and on, whose objectives name its findings B1-B6.

Each record of 2026-10-13, and where it went

The milestones of 2026-10-13 that are not carried are mapped, not lost: started-work-is-explained-bounded-and-survives-a-restart and an-intent-is-followed-to-the-deployment-that-carries-it are spread over the master milestones above, the-ui-starts-work-through-the-executor is the-ui-runs-and-explains, an-intent-is-carried-from-a-sentence-to-a-verdict is idd-reads-at-a-glance, an-outcome-becomes-a-reviewed-plan and the-intent-loop-is-proved-end-to-end, automation-is-scripted-capabilities is automation, and shell-shrinks-to-its-bootstrap is repository-automation-is-typed with the case work in automation.

Asks that a branch, not master, now holds

I4000 is carried differently by chore/a-session-proceeds-through-the-mesh-is-planned, so these asks of campaigns/majordomus-intent-ui-pack/02-ACTION-PLANE.md were not written into it, and whoever lands that branch should weigh them: the same key with another capability or input is refused as invalid input and starts nothing; the key is compared after redaction and leaks no value; a form mints one key per render; docs/EXECUTIONS.md says a key is forgotten with its execution; and two concurrent starts answer one id. I3260's ask that a repeated start of plan.transition answer the first id would add a dependency on I4000 and waits for it.

What was not planned, and why

Each pack was read as a brief, and a brief can ask for what the repository has decided against. These are recorded so that nobody plans them again by accident.

Starting

majordomus plan next
majordomus plan validate

plan next names the issue to take; plan validate checks the graph. An issue's record is .ai/repo/project/issues/<id>.yaml: read its current_state before touching code, because it says what was measured on 2026-10-30 and the tree moves. Work under a task whose scope is the issue's scope, claim the paths on the board before building, and allocate ADR and case numbers from the allocators; no record here reserves one.

Read these before the issues that lean on them:

• I4001 adds the execution states I4480 and I4482 rely on.
• I3123, I3128, I3199 and I3395 assume an effective profile that I4502 is the first to resolve; I0201-I0206 (runtime-adapters) hold the runtime limits and must consume the resolver rather than resolve a profile again.
• I3154 decides how just is derived; I4487 narrows it and depends on it.

Adding the next pack

Copy it in as campaigns/README.md says, regenerate the manifest, add its row. Then measure each ask against the tree and the plan, fold what a master issue already plans into that issue, write the rest as records with their citations, add the planning row, and run the gate. A pack that is executed directly, with no records, is named in .ai/repo/ci/campaigns-unplanned.txt with that reason.

Where it is