86 lines
5.2 KiB
Markdown
86 lines
5.2 KiB
Markdown
# 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.
|