From 7ad69ca8de6afd1eb18b1b00316ef975a7d4df6d Mon Sep 17 00:00:00 2001 From: Chris0Jeky Date: Sun, 6 Sep 2026 06:27:44 +0100 Subject: [PATCH] docs: clarify pre-migration provenance silence --- docs/STATUS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/STATUS.md b/docs/STATUS.md index 97ecca05f..1eadf00cd 100644 --- a/docs/STATUS.md +++ b/docs/STATUS.md @@ -106,7 +106,7 @@ Review and board frontend: Backend: - **Expiry sweeps no longer load proposal operations (`#1261`, PR `#2482`, merge `2bee37628`).** The unused `Operations` eager load is removed from `GetExpiredAsync`; the archived-board partition and expiry behaviour are unchanged. Evidence: `AutomationProposalRepositoryIntegrationTests` 30 passed with a new regression asserting `IsLoaded == false` (which fails on the pre-diff `Include`), Api Integration green at the head; the reviewer traced both consumers (`ProposalHousekeepingWorker`, `AutomationProposalService.ExpireProposalsAsync`) and confirmed nothing reads `Operations` after this query and no lazy-loading proxies exist. The optional chunked-sweep half of `#1261` is dispositioned as not required by that issue. -- **Proposals record the provenance producer triple and expose it through a board-authorized endpoint (`#1987` backend half, PR `#2494`, merge `f5b3225ec`).** `ProposalProvenance` gains nullable `Provider` and `PromptVersion` (64 chars, blank normalized to null, over-long rejected at the domain boundary) under migration `20260904030926_AddProposalProvenanceProducerTriple` — two additive nullable `TEXT` columns, no rebuild and no backfill. `CreateProposalDto` carries the two values as `[JsonIgnore]` init-only properties on the same trusted-input pattern as `TrustedConfidence`, so a client cannot label its own proposal's producer; only `CaptureTriageService` sets them, from the provider that actually ran or the deterministic extractor on fallback, and `BuildCreationProvenance` stamps them server-side. New `GET /automation/proposals/{id}/provenance/metadata` shares the exact board read authorization and 404 parity of the sibling `{id}/provenance` route. The contract fails closed: `Provider` is null when no producer was recorded, `Model` and `PromptVersion` are reported only alongside a recorded provider so an origin sentinel (`chat-tools`, `manual`, `queue`) can never render as a model name, and a proposal with nothing recorded returns 200 with all-null fields. This addresses states 3 and 4 of `#2315`; states 1 and 2 stay open there. Evidence: `ProposalProvenanceTests` 20/20, 428 focused Application tests, the new endpoint's 5 API tests plus `AutomationProposalsApiTests` 56/56 and `MigrationBootstrap` 22/22, Architecture 28 with the pre-existing skip, `has-pending-model-changes` clean, docs governance; the reviewer applied an authz/trust/migration lens and found the endpoint byte-identical in gating (owner and collaborator 200, stranger parity including a body-leak assertion, missing id 404) and the `[JsonIgnore]` properties unreachable from the single `[FromBody]` site. **No frontend change here** — the `usePaperReviewSelectors.ts` source swap is deliberately deferred to avoid colliding with the in-flight Review race-state work, so `#1987` and `#1284` AC4 stay open. MEDIUM plus two LOWs on `#2499`: pre-migration LLM rows with a real `ModelId` but null `Provider` now render silent, and only capture triage stamps the triple. +- **Proposals record the provenance producer triple and expose it through a board-authorized endpoint (`#1987` backend half, PR `#2494`, merge `f5b3225ec`).** `ProposalProvenance` gains nullable `Provider` and `PromptVersion` (64 chars, blank normalized to null, over-long rejected at the domain boundary) under migration `20260904030926_AddProposalProvenanceProducerTriple` — two additive nullable `TEXT` columns, no rebuild and no backfill. `CreateProposalDto` carries its trusted producer and usage fields as `[JsonIgnore]` init-only properties on the same trusted-input pattern as `TrustedConfidence`, so a client cannot label its own proposal's producer; only `CaptureTriageService` currently stamps the complete producer triple, from the provider that actually ran or the deterministic extractor on fallback, and `BuildCreationProvenance` stamps those values server-side. New `GET /automation/proposals/{id}/provenance/metadata` shares the exact board read authorization and 404 parity of the sibling `{id}/provenance` route. The contract fails closed: `Provider` is null when no producer was recorded, `Model` and `PromptVersion` are reported only alongside a recorded provider so an origin sentinel (`chat-tools`, `manual`, `queue`) can never render as a model name, and a proposal with nothing recorded returns 200 with all-null fields. This addresses states 3 and 4 of `#2315`; states 1 and 2 stay open there. Evidence: `ProposalProvenanceTests` 20/20, 428 focused Application tests, the new endpoint's 5 API tests plus `AutomationProposalsApiTests` 56/56 and `MigrationBootstrap` 22/22, Architecture 28 with the pre-existing skip, `has-pending-model-changes` clean, docs governance; the reviewer applied an authz/trust/migration lens and found the endpoint byte-identical in gating (owner and collaborator 200, stranger parity including a body-leak assertion, missing id 404) and the `[JsonIgnore]` properties unreachable from the single `[FromBody]` site. **No frontend change here** — the `usePaperReviewSelectors.ts` source swap is deliberately deferred to avoid colliding with the in-flight Review race-state work, so `#1987` and `#1284` AC4 stay open. The fail-closed projection has a visible pre-migration consequence: a row can retain a real-looking `ModelId` from a prior live-provider run while `Provider` is null, so the metadata endpoint withholds all three display fields rather than guessing; the Paper Review capture-detail fallback can still surface a capture-linked proposal's own recorded provenance. Only capture triage currently stamps the complete triple; non-capture proposals remain silent. - **Not shipped reality:** two Smart CI shadow reds in this range — on PR `#2485`, and again on the still-open `#2496` and `#2500` — are the same planner base-mismatch shape recorded on `#2327`, not a verdict on those branches; PR `#2506` is open as the fix. Open and unmerged at the time of writing: PRs `#2484` (whose review filed `#2501`), `#2496`, `#2497`, `#2498`, `#2500`, `#2502`, `#2503`, `#2505`, `#2506` and `#2507`. Their state lives on the PRs and their issues, and `docs/releases/V0_3_0_READINESS.md` carries the release-gate view. v0.3 integration wave, eighth block (2026-09-04, `main` `65c77a53f` to `c174a517a`; overnight orchestrator lane continued, thirteen merges). Codex review credits stayed exhausted (SC-9) for this whole range too, so **every PR below carried one fresh-context independent reviewer subagent instead of a Codex outcome**, and the connector's usage-limit notice was classified once per PR as informational rather than a finding. Control-plane PRs `#2502`, `#2506` and `#2522` were deliberately **not** merged by the orchestrator: under ADR-0066's 2026-09-03 amendment they wait for the maintainer's review, queued as human-action item SC-10: