[mirror29]

Problem and change

The complete campaign dispatcher omitted the persisted requesting subject from its SQL projection. The real owner model path then stopped at usage identity initialization even though the database retained that subject. Return it internally, with a real database regression and a check that the public response schema still excludes it.

Validation

• Regression failed before the fix with KeyError: requested_by_sub, then passed.
• Fresh migration-chain Evolver database: 357 passed, 1 skipped, 3 fixture warnings.
• Full Evolver application lifespan fault probe: two durable batch responses before SIGKILL, no generation proposal; natural lease expiry and restart completed five generations / 120 implementations with ten offline calls, not twelve. Synthetic ledger totals 0.000780, ten attempts, no unknown reserves. Rejected for insufficient FDR evidence.
• Provider SDK HTTP transport and local signer/credential/event endpoints are fixtures. This is source-process exploration, not same-image, real owner, real provider, full peripheral stack or production recovery. The process harness is temporary; database regression is maintained.
• Ruff checks pass. Target Mypy has ten existing tuple/dict row errors, identical with main source shadow. Existing formatting differences are not rewritten.
• Consistency: 19 passed, 0 failed, 12 existing warnings.

Production observation and remaining work

Normal owner free preflight after confirmations remains BTC 3/8, ETH 0/8, SOL 1/8. BTC legacy warning is absent in the fresh response, without certifying semantic accuracy or causal same-window comparison. No paid model or E2 search started.

Read-only runtime inspection records changed container IDs and mismatched/absent OCI revision labels. Hashes of 200 running Python package source files match the previously reviewed source; this does not cover shared packages, dependencies or client bundles. No redeployment was performed during those observations.

This is a scoped increment to the E2 acceptance plan. Real input sufficiency, owner five-generation authorization/execution, remaining reliability matrix, qualified champion, real 30-day Forward, once-only holdout and explicit adoption remain incomplete. After review, only Evolver needs deployment; no migration or frontend change is required.

Review and plan audit

Independent full-source scoped review found no confirmed new P1/P2. Automated CR reported one MEDIUM concerning other common-projection consumers; complete route/schema/dictionary-row inspection is documented in the review-resolution comment. This is not an automated zero-finding review. Independent plan audit confirms this scoped increment, while explicitly leaving the global E2 criteria incomplete.

[cloudflare-workers-and-pages]

Deploying inalpha-web with    Cloudflare Pages

Latest commit:	cea74c9
Status:	✅  Deploy successful!
Preview URL:	https://18ac6fad.inalpha-web.pages.dev
Branch Preview URL:	https://codex-e2-full-app-response-r.inalpha-web.pages.dev

View logs

[github-actions]

Reviewed PR head: cea74c923464

🤖 DeepSeek Code Review

Adds `requested_by_sub` to the shared `_CAMPAIGN_COLUMNS` projection so the evolver model-usage path can read the campaign owner's identity, plus a regression test and several deployment/validation receipt docs.

Critical	Major	Medium
0	0	1

Findings

1. [MEDIUM] Internal identity field added to the shared campaign projection reaches more consumers than tested

Location: services/evolver/src/inalpha_evolver/storage/campaigns.py:16

• Evidence: `_CAMPAIGN_COLUMNS` is a shared SELECT list reused by several queries (at minimum `claim_next_campaign` and `get_campaign`, per the new test). Adding `requested_by_sub` in the middle of that constant now returns this internal auth subject from every query built on it, not just the dispatch/claim path that actually needs it for usage recording. The only path the new test proves is safe is `CampaignResponse(**projected).model_dump()`, which asserts `"requested_by_sub" not in ...`. Any other endpoint or helper that serializes a campaign row (list/status/loop handoff) is not covered.
• Impact: If any other response path returns the raw campaign row or a model with `extra="allow"`/`extra="forbid"`, the owner's subject (`requested_by_sub`) either leaks into an API payload it was not previously in, or raises a validation error on a field the caller never expected. Consumers relying on the previous row shape (e.g. positional/tuple access) would also see shifted columns.
• Suggested fix: Either select `requested_by_sub` only in the claim/dispatch query that needs it, or audit every consumer of `_CAMPAIGN_COLUMNS` and confirm each response schema strips it (as `CampaignResponse` does). Add a test asserting the field is absent from any other externally serialized campaign payloads.

Review scope and limitations

Reviewed the supplied diff and project rules. No tests were executed by this reviewer.

• Only the diff was available; the full bodies of `_CAMPAIGN_COLUMNS` consumers (list/status endpoints, INSERT/UPDATE builders, tuple-row unpacking) could not be inspected, so positional-shift regressions cannot be ruled out.
• No tests were executed here; the receipt's '357 passed' / regression claims are taken as untrusted PR evidence, and the fix is documented as not deployed.
• The new validation JSON receipts are self-reported artifacts; their internal consistency (e.g. result='passed' alongside non-passing mypy) was not independently validated.

[mirror29]

Review resolution — shared projection identity (MEDIUM)

Finding: An internal subject added to the common campaign projection might leak through uninspected consumers or shift positional rows.

Full-source verification:

• Campaign list (api/campaign_routes.py:272) constructs CampaignListResponse(items=[_response(row) ...]); _response at line 37 constructs CampaignResponse explicitly.
• Campaign detail (:282) returns _response(row). Creation, active-loop reuse and start/reload paths also return that same schema, rather than a raw SQL row. api/loop_routes.py uses the campaign row for internal compare-and-swap and returns a loop response, not the raw campaign row.
• CampaignResponse declares no requested_by_sub; its Pydantic default ignores additional columns. The new real-database regression asserts that absence after dispatch/get. Existing owner-scoped query predicates and route dependencies are unchanged.
• Storage converts fetched rows to dictionaries, uses named keys and the shared connection pool uses dict rows; no positional campaign-column unpacking consumer was found in the actual repository.
• Runtime reads/reacquires campaign rows during execution; preserving persisted usage identity in the common internal projection also keeps those recovered rows complete.

Decision: Retain the internal projection fix. The hypothesized raw-response/positional consumer was not found after inspecting complete sources. Independent scoped review likewise found no confirmed new P1/P2. This does not mean the automated review had zero findings, and neither review replaces production owner execution.