Verify sealed plan provenance and regenerate once on mismatch #1215

New issue

Open

opened 2026-08-23 00:45:31 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-23 00:45:31 +00:00

Member

Split out of #903 rather than left implied, so the remaining half of that issue is visible on its own terms. #1214 landed #903's fail-closed core and this is what it did not touch.

What already exists

aosRepositoryPlanInput is parsed today and never read:

type aosRepositoryPolicyInput struct {
	Path   string `yaml:"path"`
	SHA256 string `yaml:"sha256"`
}

type aosRepositoryPlanInput struct {
	Identity string
	Revision string
	Policy   aosRepositoryPolicyInput
}

Agent Compose seals the policy revision and digest into the plan. AOS decodes them, holds them in plan.Inputs, and makes no decision from them. So a plan generated from policy sources that have since moved is indistinguishable at launch from one generated a minute ago.

What is missing, from #903's acceptance

Native launch fetches policy sources before final plan validation.
A source revision or policy-digest mismatch triggers exactly one Agent Compose regeneration attempt, then a full plan reload and strict re-validation.
AOS stops before creating worktrees when regeneration is unavailable, fails, or still produces mismatched provenance.
Policy-source worktrees use the exact revision sealed into the validated plan, so session policy cannot be newer than repository selection.
Any temporary JSON compatibility reader emits a deprecation warning and has a stated removal boundary. The v1 JSON path is still accepted silently.

Why this is worth its own issue

It is the only half that reaches outside the process: it fetches, it shells out to Agent Compose, and it has a retry budget of exactly one. Those are three failure modes the schema work has none of, and each needs its own test - regeneration unavailable, regeneration failing, and regeneration succeeding but still mismatched.

The exactly one bound matters. A regeneration loop that retries on a persistent mismatch spends a launch discovering it cannot converge, which is the slow-failure shape #987 and #1034 both argued against.

Not blocked

agent-compose#203, #903's original blocker, closed on 2026-08-05. The sealed fields are present in the plan format today, so this is implementable now.

Split out of #903 rather than left implied, so the remaining half of that issue is visible on its own terms. #1214 landed #903's fail-closed core and this is what it did not touch. ## What already exists `aosRepositoryPlanInput` is parsed today and never read: ```go type aosRepositoryPolicyInput struct { Path string `yaml:"path"` SHA256 string `yaml:"sha256"` } type aosRepositoryPlanInput struct { Identity string Revision string Policy aosRepositoryPolicyInput } ``` Agent Compose seals the policy revision and digest into the plan. AOS decodes them, holds them in `plan.Inputs`, and makes no decision from them. So a plan generated from policy sources that have since moved is indistinguishable at launch from one generated a minute ago. ## What is missing, from #903's acceptance * Native launch fetches policy sources **before** final plan validation. * A source revision or policy-digest mismatch triggers **exactly one** Agent Compose regeneration attempt, then a full plan reload and strict re-validation. * AOS stops before creating worktrees when regeneration is unavailable, fails, or still produces mismatched provenance. * Policy-source worktrees use the exact revision sealed into the validated plan, so session policy cannot be newer than repository selection. * Any temporary JSON compatibility reader emits a deprecation warning and has a stated removal boundary. The v1 JSON path is still accepted silently. ## Why this is worth its own issue It is the only half that reaches outside the process: it fetches, it shells out to Agent Compose, and it has a retry budget of exactly one. Those are three failure modes the schema work has none of, and each needs its own test - regeneration unavailable, regeneration failing, and regeneration succeeding but still mismatched. The `exactly one` bound matters. A regeneration loop that retries on a persistent mismatch spends a launch discovering it cannot converge, which is the slow-failure shape #987 and #1034 both argued against. ## Not blocked agent-compose#203, #903's original blocker, closed on 2026-08-05. The sealed fields are present in the plan format today, so this is implementable now.

coilyco-ops added the

labels

2026-08-23 00:45:31 +00:00

coilyco-ops referenced this issue

2026-08-23 00:47:48 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops referenced this issue

2026-08-23 00:49:30 +00:00