kami/orchestra
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Hand off with the lifecycle frozen and the plan machinery unproven

Browse Source 
The tag orchestra-conformance-v1 marks the full original lifecycle, live-proven
by run 6. Both deployed halves sit there deliberately.

The four plan-machinery commits above it pass build, vet and test, and have
never run against a live agent. The handoff records what they need before they
can: a verification policy on test-e2e, both halves rebuilt together, and F18
fixed first, since the burn-in will generate the retry loops it exists to make
visible.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVbaKucEYBjMqVeUgJUsc1
This commit is contained in:
kami
2026-08-28 12:25:30 +04:00
parent c76112a309
commit 7700dd60c6
2 changed files with 341 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BURNIN.md
+55
View File
@@ -1900,3 +1900,58 @@ Configuration this needed, for the record: `quality_gate` on `test-e2e` in both
`config.jsonc` (coordinator) and `/etc/orchestra/worker-projects.json` (worker,
which is the copy `finalize` actually reads), plus `ORCHESTRA_REVIEW_ACTORS=kami`
in the compose `.env`.
## Plan machinery, written 2026-08-28, unproven live
Four commits above `orchestra-conformance-v1`. Nothing deployed. Full detail is
in `HANDOFF-2026-08-28-plan-machinery.md`; this is the ledger entry.
| Commit | What |
|---|---|
| `822f086` | Research findings gain id and confidence. The advertised schema becomes true. |
| `57c028f` | `plan.md` replaces the four-bullet-list plan artifact. Renders verbatim into the implement launch. |
| `a221502` | Plan phase progress Orchestra establishes, plus the project verification allowlist. |
| `c76112a` | Typed plan mismatch and the Orchestra-owned reopen. |
### The burn-in it needs
Configuration first: `test-e2e` needs a `verification` block in the
coordinator's `config.jsonc`. Absent policy refuses every plan command, so
without it a plan seals and no phase can ever verify. Both halves must be
rebuilt and redeployed together, because the worker calls two new federation
routes.
Then the ladder:
```text
1. plan seals three detailed phases
-> grep the rendered launch.md for the phase-three verification command
2. phase 1 requests verification
-> worker runs the exact plan command
-> durable state says verified
3. rotation
-> successor gets the complete original plan
-> phase 1 verified, phase 2 explicitly current
4. human correction lands above the plan
5. phase 2 contradiction
-> PlanMismatchRecorded, no improvisation
-> old plan retained until the revised one seals
-> fresh launch carries the revised plan in full
6. a plan command outside project policy
-> refused at seal time, on the planner
7. a legacy plan
-> "phase progress unavailable", task still completes
```
Steps 1 and 3 are the rungs that matter for smaller local models. Steps 6 and 7
were added from what this session's implementation surfaced.
Freeze as `orchestra-plan-v1` if it passes.
### F18 is now blocking
Three more instances landed with this change: every refusal in the new plan
machinery records into the same single `last_error` slot. That is the fourth,
fifth and sixth instance. The plan burn-in will produce exactly the five-second
retry loops the bounded observation ring exists to make visible, so fix F18
before running it.