Shared Scaffold Prompt Baseline Delivery Research

Scope and conclusion

This readonly code research grounds the accepted decision that the distributed shared .agents/AGENTS.md is wholly scaffold-owned and that its source must be delivered through the selected baseline. It covers the runtime resolver, baseline publication metadata, scaffold/update ownership, and the operator path from plan through proof. It does not reproduce the historical consumer failure in collective-intelligence or ci-emera; that remains unknown.

The smallest coherent design extends the existing baseline manifest and publisher. A versioned capability declares data/shared-agents.md, its digest, and compatibility with the supporting CLI. The common Scaffold Plan resolves that selected asset for scaffold, check, update, and candidate validation. The CLI owns the complete shared file throughout comparison and replacement; repository-authored scoped AGENTS.md, rules, and custom roles retain their separate ownership. An old baseline without the capability receives an explicit compatibility result and never silently falls back to the installed CLI template.

Lane findings

Runtime and plan seam

The runtime model already carries root, dataRoot, and skillsRoot (resolve.ts:510-577; types.ts:11-22). The selected baseline is threaded through staging and update planning (stage.ts:1353-1379; update/run.ts:5301-5358). The existing shared prompt resolver instead reads the installed process data (output.ts:2500-2544; prompts.ts:51). This is a confirmed source-authority seam: selected baseline identity must be passed into the shared prompt output path, including candidate and readonly check paths.

Publication and compatibility seam

The distribution build copies shared-agents.md into non-TypeScript data, but the stable baseline archive builder currently omits it (build-dist.mjs:46-70; build-baseline.mjs:200-237). Baseline loading already catalogs metadata and checks archive identity (load.ts:44-79; resolve.ts:120-148). The existing compatibility-range mechanism supplies a bounded same-minor gate (compatibility-range.mjs:106-114). Therefore the target is an extension of existing baseline metadata and publisher/resolver seams, not a new registry or execution engine. The first reader/schema migration needs one compatible CLI release; later prompt-only baseline updates can ship without reauthoring consumers.

Ownership and reconciliation seam

Scaffold output classifies the shared file as an agent-prompt, and update currently marks existing agent-prompt files project-authored (output.ts:2587-2590; update/run.ts:1044-1085). Comparison then skips those files through the managed-file filter (update/run.ts:3167-3187). This confirms the ownership defect relevant to #197. The accepted correction is whole-file scaffold ownership across observation, comparison, apply, and completion proof. Existing safe filesystem rules still apply to regular files, copies, and symlinks; a wrong-path symlink must not redirect writes.

Brainstorm trace from the agent seat

The operator path is:

selected baseline + repository facts
  -> Context Plan -> Scaffold Plan
  -> check (observe) or scaffold/update (apply)
  -> verify bytes, manifest and receipt -> handoff/recovery when incomplete

The plan must carry baseline/template identity and the shared prompt's producer and dependency identity. Check must report stale, missing, unsupported, or integrity-failed assets without writing. Update may replace the complete scaffold-owned file, then verifies its digest and records adopted state. A second unchanged run is a no-op. Candidate validation must use the same selected asset and ordinary workspace topology as the plan. Recovery re-verifies current bytes before writing fresh proof and never treats a handoff or stale file as proof.

Required proof and unresolved facts

The delivery plan should prove selected baseline A/B sentinels beat a fixed CLI template C across scaffold, check, update, and candidate paths; stale, missing, locally edited, unsupported, hash-mismatched, blocked-apply, symlink, copy, and mirror cases; no-op rerun; preservation of authored scoped files; and no unrelated scoped reauthoring. These are required verification seams, not claims that implementation exists.

The collective-intelligence and ci-emera invocation details, exact historical error boundary, and whether either consumer currently carries the old file are unknown. Different consumer/root hashes establish divergence only; they do not prove #197's historical cause. Runtime implementation and publication were not performed by this research.

Source conflict resolution

One lane proposed retaining an installed-template fallback. That would combine two authorities and make a selected baseline appear current when its declared asset is absent, so it is rejected. The accepted source-first rule requires a typed unsupported or integrity result for old, incomplete, or mismatched baseline metadata. The separate question of exact metadata field spelling and module boundaries remains owned by the delivery plan.