docs: plan platform-owned frontend delivery

docs/superpowers/specs/2026-08-02-platform-owned-frontend-assurance-delivery-design.md

@@ -176,6 +176,27 @@ The platform dual-reads existing v2 JVM manifests during migration. New
 frontend capabilities require v3, and all new platform outputs are v3. There is
 no implicit phase default.
 
+### Artifact suite declaration amendment
+
+A repository cannot know the SHA-256 of a candidate that CI has not built yet.
+The repository contract therefore separates a static declaration from an
+executable suite:
+
+- `ArtifactSuiteTemplate` is repository-owned and declares the suite command,
+  raw artifacts, `executionPhase: ARTIFACT`, and required input artifact IDs
+  and media types. Its schema forbids `sha256` and digest placeholders.
+- `SuiteDefinition` remains the executable v3 contract required above. For an
+  artifact suite it always contains the concrete `requiredInputArtifacts`
+  tuple including SHA-256.
+- after `ci-frontend` freezes the candidate, CI creates the artifact
+  `ExecutionRequest` with that candidate tuple; testctl matches it to the
+  template and materializes the executable `SuiteDefinition` and `WorkItem`.
+
+CI supplies artifact identity but does not construct or reinterpret test suite
+semantics. An unmatched artifact ID/media type, an unresolved template, or a
+digest in a committed template stops planning. Templates never enter raw,
+normalized, evidence, or assessment documents.
+
 ## CI/CD platform changes
 
 ### Test-assurance integration
@@ -236,7 +257,17 @@ both must equal the approved subject before promotion succeeds.
 
 ### Release identity
 
-The release manifest binds:
+The signed release identity is split into two immutable documents so that one
+candidate can be promoted to more than one environment without rewriting its
+candidate manifest:
+
+- `ReleaseManifestV2` binds the candidate, test, supply-chain, policy,
+  toolchain, and platform identities;
+- `PromotionSubject` binds the release-manifest digest to the target
+  environment, approval identity/policy, confirmed publication, and expected
+  Git CAS state.
+
+Together they bind:
 
 ```text
 source revision
@@ -250,6 +281,9 @@ CI policy, capability-registry, toolchain, and platform-catalog digests
 target environment and approval identity
 ```
 
+Promotion history is an append-only record and is not a mutable field inside
+`ReleaseManifestV2`.
+
 A report for another candidate, a rebuilt candidate, a changed policy, an
 expired approval, or an unconfirmed provider mutation blocks promotion.
 
@@ -351,6 +385,12 @@ The platform path is the only candidate producer in shadow. Legacy release and
 promotion commands become read-only comparison probes. No two writers may
 publish or promote.
 
+Before shadow execution, the legacy workflow registration is disabled and its
+required status is detached. The centrally installed workflow runs in shadow,
+and its runner may invoke legacy test/evidence commands only as read-only
+comparison probes. Observed state records zero legacy candidate/provider/
+promotion invocations and exactly one platform candidate writer.
+
 ### Phase 5: Cutover
 
 After parity and fault tests pass, activate the platform capabilities, attach