# Real REST coverage parity probe

Executed successfully against the rebuilt Windows server; see
`release-rest-coverage-verification-20260906.md` for the actual 25-request evidence.
The procedure below remains the reproducible plan, rather than a claim about other
platforms or future source6 features.

The isolated probe executes this against the rebuilt current server, using only synthetic data.
The tracked payload is `harness/fixtures/rest-coverage/coverage-probe.json`: three complete
source bundles (`incomplete`, `repaired`, `invalid`) and an `expected` array of five
exact code/object/field/file tuples. The reserved fixture alias `parent` was corrected
to `activity_group` before the successful complete HTTP run. Its semantics
mirror the core coverage fixtures that passed in the full 367-test core run.

Use a fresh store under `.local/rest-coverage-store`, a verified free loopback
port such as 18787, and a dedicated synthetic token file if authentication is
enabled. Launch only this project's `arcadia-server.exe` with explicit `--bind`,
`--data-dir`, and `--token-file`; start hidden on Windows. Do not use a user's
server/store. Retain request/response JSON and ETags under `.local/rest-coverage`.
All JSON calls use `Content-Type: application/json` and the known test token.

## Exact expected incomplete result

All five are severity `warning`; all locate `work.arcadia` on source-project
validation. The UUID prefix is `f0660906-0000-4000-8000-`.

| Code | UUID suffix | Field |
|---|---|---|
| non_leaf_work_exchange | 000000000051 | source |
| work_without_behavior_context | 000000000013 | null |
| exchange_without_behavior_context | 000000000052 | null |
| mission_without_capability | 000000000021 | null |
| capability_without_behavior_context | 000000000020 | null |

The parent exchange's uncovered-exchange warning is intentionally suppressed.
A/B are covered through their included exchange; C is merely allocated. No
complete-model rejection is expected. Compare **code/object_id/field** across
representations, plus path and valid source span where supplied. Compare codes,
not human message wording or array order.

## Probe sequence and oracles

1. GET `/health/ready`; POST `/api/v1/projects` with
   `{"name":"Coverage probe host"}`. Retain its Location, resource ID and opaque
   ETag. GET its model/source-project and retain exact responses and revision.
2. POST `/api/v1/projects/{id}/validation` with
   `{"format":"source-project","source_project":payload.incomplete}`.
   Expect 200, `valid:true`, exactly the five new warning tuples above, real
   `work.arcadia` locations, no `error`. GET the accepted resource and verify
   model/source/ETag/revision unchanged: candidate validation does not commit.
3. PUT `/api/v1/projects/{id}/source-project` with raw `payload.incomplete` and
   `If-Match` equal to the current ETag. Expect 200, changed revision/new ETag,
   with warning-only admission. GET `/validation`, `/model`, `/source`, and
   `/source-project`. The accepted source bundle must exactly equal the submitted
   three files (all UUIDs are explicit). Normalize the five code/ID/field tuples
   from GET validation and compare to step 2.
4. POST candidate validation twice more: `{"format":"json","model":model}`
   and `{"format":"arcadia","source":canonical_source}` using those exact GET
   representations. Both return 200/valid:true and the identical five tuples.
   Canonical source/JSON need not preserve source-project file paths. Verify
   accepted ETag/revision unchanged after both calls.
5. POST source-project candidate validation using `payload.invalid`. It changes
   only the grouped Interaction's source to existing Entity `crew`, an invalid
   work-exchange endpoint. Expect 200/valid:false, an `invalid_endpoints` Error
   on that relation, and **none of the five new completeness codes**. PUT the
   same invalid source-project with current `If-Match`: expect 422. GET current
   model/source-project/ETag/revision and compare byte/content identity to step 3.
6. PUT `payload.repaired` with current `If-Match`. Expect acceptance and all five
   new codes cleared. The repair names leaf A as the parent exchange's source,
   includes both missing exchanges, connects mission→capability and adds explicit
   process→capability context. Other existing topology warnings, such as the
   deliberately simple sequence's exchange gap, may remain; do not misreport the
   five-code assertion as zero total diagnostics.
7. Stop/restart only the probe server with the same isolated store, then GET
   model/source-project/validation: persisted repaired data and ETag/revision
   must match. Optionally PUT the original incomplete bundle under current
   If-Match and verify the same five tuples reappear. This is an explicit
   replacement, **not server Undo**; core transaction Undo already has its own test.
8. Stop the verified probe process. Preserve the synthetic store and evidence;
   cleanup is optional and must remain scoped to these named probe paths.

The server's actual DTOs are in `oa-server/src/routes.rs`: source-project
validation returns submitted-byte locations; successful bundle writes return
accepted-bundle locations; current validation uses core object/field diagnostics.
No new API route, schema, command type, or service undo is required.