Verification manifest v1: apply the four ratified schema revisions and commit .ampere/verify.yml to the Ampere repo and repo B

[wow-miley]

Model/effort recommendation: Sonnet, medium — the schema draft and per-repo gate inventories exist; this ticket applies four ratified revisions and commits the result.

Context

The verification-manifest feasibility recon (ticket #702) proved by execution that a single declarative manifest — working filename .ampere/verify.yml, one per repository — can express 100% of the definition-of-done gates observed across three repositories. A draft schema ("v0") and hand-written manifests exist in that recon's workspace at .context/ampr-290/. The human verdict (comment on #702, dated 2026-08-23) ratified four revisions, producing schema v1:

1. One task per gate. Each gate declares a single Gradle task or command. No bundling several tasks into one gate — the recon proved bundled gates give only partial coverage on failure (Gradle fail-fast skipped a test task when a sibling task in the same invocation failed). Per-gate attribution must come from structure, not log parsing.
2. fresh: true support. A gate marked fresh forces re-execution: for Gradle gates, --no-build-cache plus test-result cleanup (the recon observed a test gate returning FROM-CACHE in 3 seconds having executed zero tests — build caches can silently satisfy a gate).
3. Infrastructure-failure outcome. The manifest/gate contract must allow the runner to classify a failure as infrastructure (host-environment problem, e.g. toolchain divergence or daemon heap exhaustion) as distinct from agent-attributable (the code under test is wrong). The recon's concrete example: :ampere-core:assemble is green in CI but fails on the local host via a Kotlin/JS backend exception. Infrastructure failures must not consume agent retry budget — that accounting rule lives in the verification runner (the "Breaker", separate Wave 2 ticket), but the manifest schema must carry enough per-gate metadata to support it.
4. Exit code is the only pass/fail contract. Failure text was observed to be non-deterministic across retries; logs are diagnostics only.

Terminology for this ticket: "repo B" = the primary consumer application repository, identified in the #702 findings comment by its dependency on Ampere artifacts (name deliberately withheld — this ticket syncs to a public GitHub issue). "Repo C" = the demo consumer application from the same findings; it is excluded here per the verdict, because it has no CI and no green baseline — a manifest lands there only after its own cleanup establishes one.

Objective

Finalize manifest schema v1 (documented), and commit a valid .ampere/verify.yml to the Ampere repository and to repo B, each expressing that repository's full ratified gate inventory from the #702 findings.

Task Sequence

1. Restructure the v0 draft schema per the four revisions above; document the schema (fields, semantics, precondition handling: hard requires refuse the run, soft optional mark dependent gates as not-executed-and-reported, never silently skipped) in docs/verify-manifest.md in the Ampere repo. Validation: every construct used by either repo's manifest is documented.
2. Write .ampere/verify.yml for the Ampere repo: the four per-module JVM test gates, the iOS Kotlin simulator test gate, the three-step ordered iOS Swift-bridge gate (using the schema's ordered-steps construct), the ktlint gate, the per-module assemble gates (split one-per-module per revision 1), and the metadata-compile gate. Validation: each manifest gate's command exactly matches a command from the Recon: verification manifest feasibility - execute DoD gates in each reference repo, test declarative expression #702 execution transcript, adjusted only for the one-task-per-gate split.
3. Write .ampere/verify.yml for repo B: ktlint (with its five documented source-set exclusions), the common-tests leg split into its three constituent tasks as three gates, backend build, desktop build, android lint+test split per revision 1, and the two architectural-isolation check gates. Validation: same transcript-match rule.
4. Extend the recon's throwaway dry-run interpreter just enough to parse v1 and echo the command lines for both manifests. Validation: echoed commands match the intended gate inventory exactly. The interpreter remains throwaway evidence — the production interpreter is the Breaker's (Wave 2).
5. Add a concept cell documenting the manifest contract (invariants: one task per gate, exit-code-only, fresh semantics, infra-vs-agent outcome classes) per the repo's concept-cell conventions in docs/concepts/.

Technical Constraints

• Two PRs: one per repository. The Ampere PR includes the schema doc + concept cell.
• Do not modify any CI workflow — CI and the manifest coexist; reconciling them is out of scope.
• Do not build the production manifest interpreter/runner — that is the Breaker ticket (Wave 2).

Out of Scope

• Repo C manifest (blocked on that repository establishing a green baseline; planned separately in that repository's own team).
• Breaker runtime behavior: retry policy, escalation, cache-cleanup implementation.
• Conditional gates (when: constructs) — deliberately absent from v1; none were observed in any repo.