docs: make gate zero ratification-only

[ascorbic]

What does this PR do?

Clarifies the delegated release service delivery plan so Gate 0 is an RFC-clarification and external-validation stage, not an implementation stage.

RFC #1870 remains the product and protocol decision. Gate 0 repository commits may update the tracked spec or plan only when recording an implementation clarification or an external finding that changes an assumption. It must not add test harnesses, prototype services, dependencies, root scripts, CI wiring, or production code. The plan now gives a concise deliverable for each gate and records emdash-plugin as the v1 command.

Related to #1908, #1870, and Discussion #1590.

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• User-visible strings in the admin UI are wrapped for translation (if applicable). Do not include messages.po changes except in translation PRs — a workflow extracts catalogs on merge to main.
• I have added a changeset (if this PR changes a published package)
• New features link to an approved Discussion: RFC: Attested Automated Publishing #1590

Typecheck, full lint, tests, UI localization, and a changeset are not applicable to this planning-only documentation change.

AI-generated code disclosure

• This PR includes AI-generated code — model/tool: OpenCode with GPT-5.6-terra

Screenshots / test output

• pnpm install --frozen-lockfile passes
• Targeted oxfmt --check passes
• pnpm lint:quick returns no diagnostics
• git diff --check passes
• No runtime code, dependencies, generated files, or UI changes

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6b347ef

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	emdash-demo-cache	6b347ef	Jul 10 2026, 02:15 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	emdash-playground	6b347ef	Jul 10 2026, 02:14 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	emdash-demo-do	6b347ef	Jul 10 2026, 02:14 PM

[emdashbot]

This is a documentation-only PR that updates the delegated-release-service planning documents so Gate 0 is framed as ratification and external validation rather than implementation. The approach is appropriate for a feature with an approved Discussion, and it keeps an architectural change grounded in the existing plan files without touching code, packages, CI, or UI.

I read the diff, both changed documents, and searched for remaining "spike" / "prototype" language in those files. The re-framed W0 descriptions are consistent and no AGENTS.md code conventions are violated (no new code, no SQL, no API routes, no UI strings, no changeset needed). However, two places still describe Gate 0 work as code/site-of-experimentation "spikes" and "prototypes," which directly contradicts the new Gate 0 rule that only spec and plan updates may be committed to the repository. These leftovers make the document disagree with itself about what Gate 0 produces, so they should be cleaned up while the PR is focused on exactly this distinction.

---

Findings

• [needs fixing] .opencode/plans/delegated-release-service/implementation-plan.md:126

  The sentence says Gate 0 deliverables are spikes, but the new Gate 0 framing added in this PR explicitly says Gate 0 "must not add test harnesses, prototype services, dependencies, root scripts, CI wiring, or production code" and that only spec/plan updates are committed. Calling them spikes here re-introduces the implementation framing the PR is removing.

  `W3` and `W4` run in parallel with `W1` and `W2` after Gate 0. `W6`, `W7`, and most of `W8` begin once the service API and lifecycle contracts are frozen, without waiting for aggregator history work.
  

• [needs fixing] .opencode/plans/delegated-release-service/implementation-plan.md:998-1002

  The Recommended Merge Sequence and First Execution Set still describe W0.3–W0.6 as code- or experiment-producing spikes and prototypes with their own merge-numbered PRs, which conflicts with the updated workstream text (e.g., W0.3: "Commit only the resulting spec/plan update; keep disposable clients and accounts outside this repository" and W0.6: "Do not add an aggregator prototype to this repository").

  If these merge units are just the spec/plan updates that record external validation conclusions, their names should say that. Otherwise they read like Gate 0 is sneaking implementation work back in.

  | 2        | Create-only PDS compatibility validation                                         | Draft record NSID                                   |
  | 3        | Confidential OAuth/workerd constraints validation                                  | None                                                |
  | 4        | Sigstore verifier selection and field-mapping decision                             | Draft provenance shape                              |
  | 5        | Aggregator historical-event source decision                                        | None                                                |
  

  The dependency labels in rows 11 and 14 should be updated to match (Sigstore decision, OAuth constraints decision), and the First Execution Set items on lines 1084–1087 should likewise use validation / decision wording instead of spike / prototype.