The Trilogy Times

## Summary

- remove unsupported lastModifiedDate from the customrecord_cseg1 SuiteQL contract

- keep the raw Team Room lookup limited to fields NetSuite exposes

- align the migration DDL and manifest regression test

## Validation

- uv run --project pipelines/runners/netsuite-raw pytest -q pipelines/runners/netsuite-raw/tests (314 passed)

- uv run --project pipelines/runners/netsuite-raw ruff check pipelines/runners/netsuite-raw/src/field_contracts.py pipelines/runners/netsuite-raw/tests/test_manifest.py

- production cseg1 raw smoke run succeeded with 2,942 rows

- production GL-only refresh succeeded and verified Core GL surfaces

Linear: AI-832

Deployment note: deployed to the active prod task definition for smoke validation; leave this PR draft and do not merge.

The scheduled Ramp Spend pipeline used an invalid Anthropic key from ramp-pipeline-secrets. Classification failed for 18 merchants, preventing the week-38 cost-analysis artifact and blocking the Superbuilders report. Classification and cost analysis now read the dedicated klair/anthropic-api-key secret directly, which matches Klair's working production credential.

Ramp OAuth credentials remain separate. The runner receives read permission for the dedicated secret, with no access to the broader application environment bundles. The loader supports the dedicated plaintext key and explicitly configured JSON fields, and never falls back to the obsolete credential.

## Business Value

Restores the credentials needed to produce the weekly Superbuilders spend report and removes the separately copied Anthropic key that can become stale. This addresses credential selection; the existing scheduling and research-recovery behavior is unchanged.

## Implementation Effort

Estimated 3–5 hours for an average engineer without AI assistance, including investigation, implementation, tests, isolated production deployment, and live pipeline validation.

## Validation

- All 225 Ramp Spend tests pass, including credential-source isolation, plaintext/JSON secret loading, and failure without fallback.

- Ruff formatting/checks passed on the modified Python files; git diff --check passed.

- The replacement key authenticated for claude-opus-4-8; a live Messages request through the changed loader succeeded.

- The isolated CDK diff contains only the task role's secret permission and the task definition's secret setting/image.

- Deployed candidate commit f6816de4 from production base d9ef59a3 to only Pipeline-ramp-spend-pipeline-prod, using --exclusively. CDK reported [1/1]; CloudFormation reached UPDATE_COMPLETE. The five changed files are byte-identical to PR commit 88f0fc18. The live runner is task definition revision 13 with ANTHROPIC_SECRET_NAME=klair/anthropic-api-key.

- Full production weekly_report execution ramp-klair-key-validation-w38-0454e4fd reached SUCCEEDED on 2026-09-21. Run 310453dc-4ac0-4bcc-9c77-df69e195577c fetched/transformed all 38 weeks (13,648 transactions), classified all 18 previously blocked merchants with zero errors, and generated fresh week-38 metrics, chart, and cost analysis. The cost stage analyzed 274 merchants and did not reuse a cached report.

- Preflight validated all three report artifacts and their contracts, including data freshness through 2026-09-19. The previously missing cost-analysis/cost_opportunities_final_results_w38_2026.json now exists.

- Deployed report execution ramp-klair-key-report-dryrun-w38-581cd615 reached SUCCEEDED. Run 67a690df-77a8-4a6b-bc8c-d0b961e73803 returned status=validated, mode=dry_run, and rendered the matching week-38 report. No report email was sent.

- GitHub CI checks passed on the PR commit.

## Linear

[SURTR-1424 — Use Klair production Anthropic secret for Ramp spend](https://linear.app/builder-team/issue/SURTR-1424/use-klair-production-anthropic-secret-for-ramp-spend)

## Summary

- Adds spec 11 under features/surtr/ai-spend-pipeline/specs/11-personal-api-key-mapping/: one hand-reviewed row for core_finance.ai_spend_subject_identity, mapping the Anthropic api key id of Artie2-Key (apikey_01K3B5pLKLc553gxzEDEg7j3) to arthur@trilogy.com. It is the row spec 10 deferred; Jamie Sidey (who runs AI budget tracking) asked for it on 2026-09-21.

- 01-key-seed.sql: first application only, one transaction, no DELETE, in spec 10's guarded idiom (all of spec 10's review lessons built in). Guard 1 aborts if the key already has any registry row; guard 2 re-reads the Anthropic usage feed and aborts unless every row for the id is named Artie2-Key, created by arthur@trilogy.com, and not TrueFoundry-routed (catches a mistyped id, which would silently do nothing, and stale evidence); guard 3 aborts if the id is a registered TrueFoundry provider key (would double count); guard 4 aborts unless exactly one correct row exists afterwards.

- 02-verification.sql: precondition report, before/after checksum over every other row, exact-row assertion, duplicate/chain checks, the feed evidence, the TF-provider-key check, and the expected effect on Klair (the mart cost x Klair's 6.6% uplift).

- 03-rollback.sql: one transaction; deletes only a row matching all four inserted values, and only if it is the one such row; an edited row or an identical later duplicate fails closed.

- spec.md: evidence and apply gate (with its gap stated), how it is applied, verification, rollback. Small doc updates: spec 10's Status line (applied 2026-09-20) and Deferred section now point here; FEATURE.md ticket row, data-source line and changelog row.

- Docs/SQL only. Not applied. The Klair side (KLAIR-3559, #3800) is already merged and released to prod, so applying the row is the only step.

## Ticket

SURTR-1425 https://linear.app/builder-team/issue/SURTR-1425/credit-arthur-michels-artie2-key-in-the-identity-registry-spec-11

Follows SURTR-1403 (spec 10) and KLAIR-3559.

## Business Value

Finishes the per-person attribution fix for one executive's AI spend. His People-tab row is one row at about $44K for the quarter to date, but his active API key (about $4.3K pre-tax, still spending) is shown only on the API Keys tab. With this row his row shows about $48.7K, so the number budget owners and leadership see for him matches what he actually spends, and a follow-up request from the budget owner is closed rather than left as a known omission.

## Manual Effort Estimate

Proposed: ~1.5 hours of focused time to hand-build (spec, seed with in-migration evidence guards, verification, rollback, running the checks read-only against prod). @Keval please confirm or adjust — this is an AI-proposed number.

## Test plan

- [x] Nothing written to a warehouse. 01's guards 1-3 and 03's guard were run read-only against prod today and all pass (each returns 1); all nine queries in 02 ran and returned the expected BEFORE state (total_rows 9, seed_slug_rows 0, other_rows 9, other_rows_checksum 17829572356; feed evidence 785 rows, tf_routed_rows 0; TF provider check 0 rows; expected Klair effect 4,322.45 -> 4,607.73 with uplift).

- [x] All three SQL files parse under sqlglot's Redshift dialect (01: transaction, 3 guards, insert, guard, commit, check; 03: transaction, guard, delete, commit, check); the notes literal is identical in all three files.

- [ ] Before applying: re-check the apply gate (spec.md), run 02 sections 0 and 1 and keep the output.

- [ ] Apply 01-key-seed.sql as one batch (BEGIN ... COMMIT); its closing SELECT returns 1 row. If it aborts on a guard nothing was applied.

- [ ] Run 02 (after): section 1 other_rows = 9 and the checksum identical to before, total_rows = 10; 2b returns 1, 1, 1; sections 3, 4 and 6 return 0 rows; section 5 returns the one feed row with tf_routed_rows 0.

- [ ] klair.ai People tab: the person's row rises by about $4.6K (section 7); company and BU totals unchanged.

- [ ] 03-rollback.sql is the undo; only needed if verification fails or Arthur says the key is not his.

## Reviewer call-outs

- The gap, stated plainly. Spec 10 asked for written confirmation from the key's owner before this row ships. This row does not have that: it has Jamie Sidey's explicit request plus matching feed evidence (all 785 feed rows named Artie2-Key, created by arthur@trilogy.com, none gateway-routed; the only key whose name contains "artie"; not a TF provider key; Klair's API Keys tab already lists him as owner). A creator is not necessarily the user. The cost of being wrong is bounded (about $4.3K of API spend on his People row and in his budget alerts; company and BU totals do not move) and it is fully reversible with 03. The notes value records the request rather than claiming owner confirmation; spec.md records the same gap.

- 01 reads two tables it does not own (staging_finance_ai_spend.raw_anthropic_token_usage, core_finance.ai_spend_tf_provider_keys), read-only, as guards. If either is renamed the migration aborts rather than applying on unverified evidence.

- The key id is stored as Anthropic issues it (mixed case); every registry comparison uses LOWER(), the feed comparison is on the id as issued.

- Julianne-Key (about $8, also created by Arthur) is deliberately not included.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Fetch the configured origin/<baseBranch> before creating a fresh task or batch worktree.

- Pin the worktree to the resolved base SHA and serialize shared-source fetches across concurrent workers.

- Preserve validated publication base SHAs and use the configured GitHub credential provider for refreshes.

## Verification

- pnpm build passed.

- pnpm lint passed.

- pnpm format:check passed.

- Focused workspace/runtime tests: 39 passed.

- Non-Docker suite: 1,290 passed.

- Full suite: 1,294 passed; 1 Docker boundary test could not start because the local Docker daemon is unavailable.

## Summary

- Consume projection_status and exact-date closing_price fields from the governed Surtr/Core SpaceX distribution tranche contract.

- Preserve Actual close provenance and fail closed for malformed Actual rows.

- Keep Projected rows on the existing live scenario-price behavior, including duplicate event dates and the conditional Price trigger row.

- Keep the contract close-only; adjusted-close, dividend, and split fields are not added.

Linear: KLAIR-3560

## Validation

- Backend SpaceX snapshot tests: 15 passed.

- Frontend full Vitest suite: 6,913 passed, 16 skipped.

- Frontend pnpm lint:pr: passed.

- Frontend production build: passed.

## Screenshot

<img width="1424" height="602" alt="image" src="https://github.com/user-attachments/assets/90ba76d6-9fb2-41ac-9912-a36e90916b5f" />

## Summary

- Adds the validated QuickBooks AgedReceivableDetail contract, transport, parser, and fail-closed company runner.

- Adds immutable S3 evidence/manifests, raw staging/run metadata/ledger publication, and the Core AR aging fact/procedure contract.

- Adds landing-only local validation mode and an on-demand-only ECS pipeline manifest; scheduling remains disabled.

- Adds bounded Redshift Data API execution helpers without invoking the Core procedure from the deployed pipeline yet.

## Validation

- AR package: 45 tests passed during the final local validation cycle.

- Existing QuickBooks raw-sync suite: 135 tests passed.

- Ruff lint/format passed.

- Live landing-only run: 57/57 companies, report_date=2026-06-30, immutable S3 evidence complete.

- Live local publication: 951 raw rows, 57 ledger rows, zero duplicate keys.

- Core procedure invocation: FINISHED; 951 Core rows, 24 non-empty companies, zero duplicate IDs, zero missing lineage rows.

- AgedReceivables summary reconciliation: 57/57 reports, exact match to Core open balance total of $117,657.63.

## Production safety

- Production deployment must follow the normal release process; this branch was not deployed directly to production.

- EventBridge scheduling remains disabled.

- Existing raw_invoice, raw_payment, current QuickBooks views, and unrelated Core tables are not modified.

- Q106 Finance document updates are intentionally deferred.

## Linear

- SURTR-1347

## Notes

- The local retry reused a test run ID and created a second immutable S3 evidence version set; production executions use unique IDs as agreed.

- The raw/run/Core DDL and refresh procedure were applied and verified as a separately authorized migration; the code deployment remains release-gated.

## Demo

<img width="2624" height="1636" alt="image" src="https://github.com/user-attachments/assets/ec34b888-493f-4593-9e1a-5fd5fa847211" />

## Summary

- Expose Downsell subcategory tabs for MTD, QTD, YTD, and TTM table views.

- Add an Unclassified tab for missing or unknown values while retaining them in All.

- Make loading, empty, Live Mode, chart, and Compare behavior explicit.

- Add focused coverage for filtering, counts, totals, period changes, and view gating.

## Linear

- AI-855: https://linear.app/builder-team/issue/AI-855/make-downsell-subcategories-visible-in-the-main-report

## Verification

- pnpm test:run (671 files, 6,892 tests passed; 16 skipped)

- pnpm build

- pnpm tsc -p tsconfig.app.json --noEmit

- Changed-file ESLint with --max-warnings 0

## Scope

Charts and Compare mode remain on their existing data paths and now explain that subcategory filtering is table-only.

Linear: AI-832

## Summary

- Add the raw Team Room reference and TransactionLine cseg1/memo contracts, additive DDL, generated comments, and resumable historical backfill support.

- Add period-scoped atomic GL current, historical, and mapped writers in new core_finance_netsuite tables, leaving the existing staging_netsuite.gl_transactions_* tables untouched.

- Reconstruct saved-search amounts and mappings from atomic raw sources, validate grain/rates/Team Room resolution, preserve overlap and historical promotion behavior, and register the replacement after netsuite-raw.

- Add session-local shadow validation and a migration-only validator. Legacy can fill only structurally paired blank fields during validation; production remains raw-only.

- Omit only fallback accounting lines whose transaction header and matching transaction line both lack the required subsidiary. Retain them as session-local evidence and keep every other required-field check fail-closed.

## Validation and production publication

- uv run --project pipelines/runners/netsuite-raw pytest pipelines/runners/netsuite-raw/tests -q — 289 passed.

- /Users/ash/.local/bin/uv run pytest -q in pipelines/runners/netsuite-saved-search-refresh — 130 passed.

- Ruff 0.15.22 check and format check pass; git diff --check passes.

- SQL procedure compilation and June 2026 shadow execution succeeded in production Redshift (finance_dw).

- Raw reconstruction surfaced 221,831 rows. The writer omitted 308 fallback accounting lines with no subsidiary on either source, leaving 221,523 publishable rows and zero remaining invalid required-field rows.

- All 221,502 legacy rows paired to raw with zero structural mismatches. The 19,397 common same-grain transactions (221,498 rows per side) differ by 3.68 in both SUM(amount) and SUM(amount_net) against a 2.477B total.

- After the variances were accepted, period 645 was atomically published to core_finance_netsuite.gl_transactions_current, gl_transactions_historical, and gl_transactions_mapped. Each contains 221,523 rows; current and historical have zero bidirectional all-column differences.

- Published SUM(amount) is 2,476,097,110.23 versus legacy 2,477,373,198.02, a -1,276,087.79 difference (about -0.052%). The 18 Core-only transactions contribute -1,207,614.44, three extra rows across two common transactions contribute -68,477.03, and the same-grain population contributes +3.68.

- Populated-but-different names, currency/rate values, amount formatting/rounding, and small mapping variances are reported rather than overwritten from legacy.

- The temporary preflight evidence table and migration-only procedure were removed; Redshift catalog checks returned zero AI-832 validation objects.\n- Production catch-up refreshed August 2026 (647) and September 2026 (648) into current and mapped in one atomic batch; historical remained capped at July. August published 191,203 rows with a 4.82 same-grain amount difference; September published 172,041 rows with a 1.59 same-grain difference. Both periods have zero invalid required fields.\n\nDraft for review; do not merge until the remaining observed-run gates in the ticket are complete.

## Summary

- Orders workflows, agents, skills, and credentials by updatedAt through tenant-prefixed Convex indexes.

- Replaces offset-style and over-fetch filtering with native continuation cursors and query-level lifecycle/access predicates.

- Updates agent timestamps when attachment or skill-binding snapshots change.

- Adds consistent Updated At columns and newest-first sorting across Forge tables.

- Advances the control-plane contract to 2026-09-20 for the updated discovery metadata and cursor-ordering semantics.

## Pagination semantics

- Pagination is intentionally live rather than snapshot-based.

- A record updated between page requests can move across the cursor boundary.

- Refreshing starts a new traversal from the newest records.

- Credential UI inventory remains complete; only the public control-plane surface uses bounded cursor pages.

## Review guide

1. Start with the indexes in convex/schema.ts.

2. Review query selection and pre-pagination filters in controlPlaneReads.ts, agentDefinitions.ts, skillDefinitions.ts, and credentialBindings.ts.

3. Review the live-cursor contract in convex/lib/controlPlanePaginate.ts.

4. Review public metadata and the version cutover in convex/controlPlaneContracts.ts; the generated OpenAPI diff is collapsed.

5. Finish with the mechanical Forge table changes under src/components.

## Deployment

Convex builds the new indexes before activating functions that query them. Existing rows already contain updatedAt, so this requires no row migration. Deploy to development and smoke-test all four list surfaces before promoting the same revision to production. Coordinate the contract revision with [Aerie #1428](https://github.com/AI-Builder-Team/Aerie/pull/1428).

## Summary

- Sync Aerie's vendored Sindri control-plane OpenAPI contract to revision 2026-09-20 from [Sindri #203](https://github.com/AI-Builder-Team/Sindri/pull/203).

- Advance Aerie's expected Sindri contract version and contract-monitoring coverage.

- Refresh the canonical and compact contract hashes used to detect vendored-spec drift.

## Deployment

Deploy the matching Sindri revision before or with this Aerie change so contract monitoring observes the same Sindri-Version on both sides.

## Changes

- Move seven owned Redshift pipelines to exact Surtr_Service_User using short-lived IAM credentials; prevent shared-secret identity overrides.

- Update pipeline IAM/configuration and runtime-owned FinOps DDL. Preserve shared secrets, colleagues' permissions and PostgreSQL-only Grainne paths.

- Stop PP DDL on failed or unresolved statements. Preserve the deployed SaaS refresh procedure body and publication behavior.

[SURTR-1302](https://linear.app/builder-team/issue/SURTR-1302/move-owned-pipelines-off-cql-download-om) · [Rollout note](docs/plans/surtr-1302-manifest.md)

## Attended rollout — Munawar must be at his desk

1. Merge to main. Before merging main → production, prepare exact manual grants, ownership-only forward/reverse SQL and fresh DDL/ACL backups.

2. Pause affected existing schedules and success triggers; drain active runs. Coordinate the manual DB changes with the production merge, which triggers deployment. No local migration/deployment.

3. Preserve existing readers and shared input owners. Include RAH account-enrichment reads, date-map UPDATE for LOCK, PP orphan-stage ownership checks, and transfer the existing SaaS procedure with ALTER PROCEDURE ... OWNER TO without replacing its body.

4. Verify each deployed runtime identity, required input freshness, publication and cleanup through normal platform execution. Restore prior triggers only after validation; avoid duplicate schedules and unintended risk/Grainne side effects.

5. If validation fails, keep triggers paused, reconcile pending statements, restore the prior release and exact owner/grant state. Retain shared privileges still needed by other migrated pipelines.

Production state: the password-disabled, non-superuser identity exists and isolated probes passed. 0/7 pipelines are migrated. Production grants, ownership handoffs and deployment remain release-window work.

## Summary

- Mercy flagged the spec 10 rollback (03-rollback.sql, landed in #1967) as critical on release PR #1968: its ownership guard accepts COUNT(*) = 2 AND COUNT(DISTINCT added_at) = 1 but never checks that the two matching rows are one per distinct seed slug. If one seed row were removed and an identical duplicate of the other were inserted with the same added_at, the guard would pass and the DELETE would remove both rows, including one not proven to have been written by 01-identity-seeds.sql.

- Fix: add COUNT(DISTINCT t.subject_slug) = 2 to the guard, so the only accepted non-empty shape is exactly one row for each of the two seed slugs written by one INSERT, and document the new failure case in the header comment. The DELETE predicates, the seed script and every other statement are unchanged.

- The file is a documentation artifact (not deployed and not executed by CD); it is in this PR only because it rides in the production release and the finding blocks the merge.

## Business Value

Keeps the safety net for a manual, destructive data operation honest: a rollback that can delete a row nobody proved it wrote defeats the purpose of a guarded rollback. Also unblocks the production release that carries the at-risk pipeline fixes.

## Manual Effort Estimate

About 45 minutes of focused work by hand: reading the guard and the seed script, reproducing the failure shape, writing the fix and the comment, and a scratch replay. Proposed by Claude, Keval to confirm or adjust.

## Test plan

Synthetic rows in a scratch schema (dropped afterwards; nothing in core_finance was read or written), running the guard exactly as written with the table swapped:

| Case | Old guard | New guard |

|---|---|---|

| exactly the two seed rows | pass | pass |

| one seed row removed + identical duplicate of the other, same added_at | pass (would delete both) | abort |

| empty / already rolled back | pass | pass |

| only one seed row present | abort | abort |

- [x] Scratch replay above (the dangerous case now aborts; legitimate cases unchanged)

- [ ] No deployment or data change is needed; the rollback is only run by hand

Linear: SURTR-1415

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

This PR does two things: it fixes Mercy's blocking finding on the release PR (scope known denials to reviewed accounts), and it fixes a regression #1965 introduced in the stored run summary.

1. Known denials are scoped to reviewed accounts

- The known-gap match only checked the error pattern, so a newly onboarded account hitting the same denial was classified as known and the run reported success. A failure is now known only if it matches the pattern AND its account ID is in the reviewed set for that pattern (_REVIEWED_ASSUME_ROLE_ACCOUNT_IDS, 5 accounts; _REVIEWED_SCP_ACCOUNT_IDS, 31 accounts). Anything else is unexpected, so the status is partial_failure.

- The ID is read from the failure record's account_id (set from Organizations discovery), never parsed out of the error text, and matched whole (fullmatch on 12 ASCII digits). A missing or malformed ID, or a padded, prefixed, longer or full-width-digit string, is unexpected.

- The SCP gap is also scoped to the two regions #606 documents (ap-northeast-1, ap-southeast-1). The assume-role gap is account-level, so it is not region-scoped. This is one field and easy to drop.

- Where the sets come from: the 5 EY accounts are exactly the ones #606 names. #606 documents the 31 Umbrella accounts by count, payer, SCP and regions but names only 3, so I enumerated the 31 from the run it cites (b76212dc, 2026-07-07). They are identical in all 96 recorded runs since 06-17, all under payer 764203154397, all denied in exactly those two regions. #269 adds no IDs beyond one already in #606.

2. The run summary stays under the stored size cap

- update-run-success cuts the stored output_summary at 65,535 characters, silently and mid-JSON. #1965 added error_code and operation to each failure record, which pushed a run with ~107 failures past that. Replaying the real 2026-09-20 run through the actual handler (1,822 accounts, the recorded error text, production new mode): 70,396 characters on main, 4,861 over, and the cut loses known_failure_context, total_records, redshift_result, write_mode, payload_s3_uri, manifest_s3_uri and secondary_write. With this PR it is 14,399 characters and nothing is lost.

- Known failures are counted (known_failures, known_failures_by_pattern) and the reviewed account IDs behind them are listed per pattern (known_failure_account_ids_by_pattern), but they are no longer listed record by record; that detail is already in the run log.

- Unexpected failures keep full per-record detail in unexpected_failed_account_regions (replacing failed_account_regions), fitted into the room left under SUMMARY_MAX_CHARS (60,000), with an explicit unexpected_failed_account_regions_truncated count. unexpected_failure_account_ids (sorted, distinct; a record with no valid ID shows as unknown) is capped at 200 with unexpected_failure_account_ids_truncated. Error texts, including secondary_error, are capped at 1,000 characters (full text stays in the log).

- Key order: every small key comes first (including known_failure_context, total_records, redshift_result and the write-mode keys) and the bounded lists are always last. Side effect: the partial-run card renders the summary in key order and keeps the first 1,500 characters, so it now shows the counts and known_failure_context instead of the first two raw failure records.

- Unchanged: the status logic, the reviewed-account matching, the ledger outcome (still partial whenever any account-region fails) and the hard-fail floor.

Reviewer decisions

1. Four accounts fail today and are documented in neither issue. I left them OUT of the sets on purpose, so they surface as unexpected. Until a human decides, the run reports partial_failure again because of them (20 account-region failures per run; replaying the 09-20 run gives known 87 = 25 + 62, unexpected 20). All are assume_role_denied in all 5 regions and have failed in every recorded run since first seen:

- 908937782078 Prod-Crossover-XOApplication (VDI), since 2026-07-11

- 206786789429 Prod-Crossover-XOAppS3 (VDI), since 2026-07-15

- 156299069086 Prod-SaaS-itoperations (VDI), since 2026-07-17

- 691257496645 Wine-Cellar-96 (TotogiMaster0), since 2026-09-16

To accept one, add its ID to _REVIEWED_ASSUME_ROLE_ACCOUNT_IDS once its owner confirms the missing role is intentional; otherwise the role trust needs fixing in that account.

2. Please confirm the 28 SCP IDs that #606 does not name individually (enumerated from its cited run, see above).

3. Not in the sets and not failing now, so no decision needed unless they recur: three Totogi accounts (125579685777, 497201305267, 619891987761) in July and 225677430396 (Wine-Cellar-822) in early September, each for 1 to 3 runs. If they come back they show as unexpected.

4. Summary shape: failed_account_regions no longer exists. New runs carry unexpected_failed_account_regions (unexpected failures only, bounded) plus the counts and account-ID lists above. I found no other consumer of the old key in this repo (Surtr app, observer, CDK lambdas; the notifier tests only use account_region_failures, which is kept). Historical rows keep the old key.

## Business Value

Closes the gap Mercy found: a new account hitting the same denial could have been reported as a healthy run, hiding its missing Bedrock spend. A run is now green only when every failing account is one a human has reviewed, and a partial run lists the account IDs to check. It also keeps the stored run record complete and readable, so total_records, redshift_result and secondary_write are not silently lost once the release ships.

## Manual Effort Estimate

About 4.5 hours of focused work by hand: roughly 1 hour to pull the run history and work out which accounts the two issues actually document (only 8 of the 36 are named), 1 hour for the scoped matcher and its tests, 45 minutes to measure the real summary size and read how the recorder and notifier use it, and 1.75 hours for the bounded, ordered summary and its tests. Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/aws-bedrock-token-metrics: 147 passed (99 on main, 48 added or reworked here: 33 for the scoping, 15 for the summary size). Against the pre-change handlers (with import stubs only) the scoping tests fail (31) and the new size tests fail (16).

- [x] Size tests: a production-shaped run (107 failures) serializes under 50,000 characters; 107 known failures cost under 500 more characters than 87; a worst case of 2,000 unexpected failures stays under SUMMARY_MAX_CHARS and reports how many were truncated; oversized non-ASCII error text cannot break the cap; the summary is valid JSON and the recorder's 65,535 cut is a no-op; small keys precede every list in all three write modes.

- [x] ruff check pipelines and ruff format --check pipelines (ruff 0.15.22, the CI pin): clean.

- [x] Replayed the recorded failures of all 96 parseable runs from 06-17 to 09-20: the 24 runs from 06-17 to 07-10 (the documented population) would report success; from 07-11 the undocumented accounts above appear and the run would report partial_failure. Latest run: known 87, unexpected 20.

- [x] Replayed the real 09-20 run through the handler: 70,396 characters on main, 14,399 with this PR, no keys lost.

- [ ] After merge and deploy: the next run's stored output_summary parses as JSON, contains secondary_write, and shows known_failures: 87 and unexpected_failure_account_ids equal to the 4 accounts above, until decision 1 is made.

Post-merge: deploy through the normal release flow. No backfill or DDL is needed. Decision 1 needs a human before this pipeline can go green again.

Linear: SURTR-1410

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- #1964 (merged) let OPENAI_DAYBREAK_KEY be reported as known_unresolved by name alone. Mercy's review of the release PR (#1968) blocked on that (high, blocking): if the manual registry row that covers the key is deleted or drifts while the name stays listed, the secret is still demoted and the run can go green while the key's spend loses its is_truefoundry_routed flag.

- The name list is replaced by a mapping, KNOWN_UNRESOLVED_OPENAI_SECRETS, from secret name to the OpenAI user_id of the covering row (Daybreak to user-Zu6cuZqkSHd8RtunO7ZjeYra, registry row 16). A listed secret counts as known only while an open, already-effective registry row for exactly that user_id exists. Otherwise it stays in unresolved, its reason says the coverage is missing (or could not be verified), and the run is partial.

- The runner had no registry read to reuse. Every registry reference in it is a write, or an EXISTS inside the write batch, whose results never reach Python. So this adds one read-only SELECT (RedshiftRepository.open_registry_identifiers), made once and only when a listed secret is unresolved. Run against the live cluster it returns the two open OpenAI user_id rows, and Daybreak's mapped id is covered today, so deploying this does not change any run's status.

- Fails closed. The user_id must match exactly (no case-folding, trimming or prefix match). An empty registry, a closed or not-yet-effective row, a row for another provider or user, or a failing read (logged as TFY_REGISTRY_COVERAGE_UNVERIFIED) all leave the secret unexpected.

- Writes are unchanged. The check runs before reconcile() and only changes what is reported. complete_provider_types is untouched, so OpenAI stays out of stale-close, and the SQL batch sent to Redshift is byte-identical with the row present, the row missing and the name not listed (test and replay below). While a listed secret is unresolved OpenAI is never complete, so this run's own writes cannot close the covering row between the check and its use.

- If the manual row is deleted: partial, known_unresolved is empty, and unresolved gains OPENAI_DAYBREAK_KEY with reason expected one OpenAI user match, found 0; required registry coverage is missing: no open openai user_id row for user-Zu6cuZqkSHd8RtunO7ZjeYra.

- ESW and ACADEMICS are unchanged: still unexpected, so the run stays partial for them until the TFY admin confirms ownership and a registry row is added. That follow-up is not in this PR.

For the reviewer:

- The covering row's source is not checked. Any open, effective row for that user_id dedupes its spend, and if it is ever closed the next run reports it.

- Each listed name is validated whenever it is unresolved. A name that resolves, or is absent from the API response, cannot turn a run green, so it needs no coverage check.

## Business Value

Without this, deleting or drifting the one manual registry row could leave the pipeline reporting SUCCESS while about $167k of TFY-routed OpenAI spend (09-04 to 09-19) loses its routed flag and is counted twice. With it, that failure turns the run PARTIAL with a reason that names the missing row, so it is caught on the run that would have hidden it. It also removes the blocking finding on the production release.

## Manual Effort Estimate

About 2 hours of focused work by hand: 30 minutes to re-read the run and stale-close path and design the check, 20 minutes for the registry read and the plan change, 1 hour for the tests (fake registry, exact-id, failed-read and deleted-row cases, mutation checks) and 10 minutes for the README. Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv sync --all-extras then uv run pytest tests in pipelines/runners/tfy-provider-secrets-sync (Python 3.11.11): 57 passed (45 on main); 18 of them fail on unchanged source, and test_handler.py fails at import there

- [x] ruff check pipelines and ruff format --check pipelines (ruff 0.15.22, as CI): clean

- [x] test_known_unresolved_openai_secret_never_closes_existing_openai_registry_rows runs the handler against a fake Redshift with the row present, the row missing and the name not listed: reconciled, partial, partial; the three SQL batches are identical, with no SET effective_to and no NOT IN; the coverage read is a single SELECT, and absent when nothing listed is unresolved

- [x] Real mapping: with the row present ESW and ACADEMICS stay unexpected and Daybreak is known; with the row deleted all three are unexpected and Daybreak's reason names the missing coverage

- [x] Five near-miss user_ids (truncated, extended, case-changed, trailing space, a different open user), an empty registry, an unreadable registry and non-OpenAI providers all leave the secret unexpected

- [x] Eight mutation checks, not committed (skip the check, fuzzy id match, unreadable registry treated as covered, known counted as resolved, eager read, each of the two SQL predicates dropped, provider check dropped): each fails between 1 and 9 tests

- [x] Replay of a synthetic 10-secret set through origin/main and this branch, row present and row deleted: the 13 SQL statements are byte-identical in all three, stale-close is issued only for Anthropic and Gemini, and only the deleted-row case adds the Daybreak coverage reason

- [x] Live read-only check of open_registry_identifiers("openai", "user_id") on the cluster: returns the two open rows, Daybreak's id is covered

- [ ] After deploy, the next 05:00 UTC run still records PARTIAL for ESW and ACADEMICS only, with known_unresolved listing Daybreak and no coverage reason on any secret

- [ ] Follow-up, not in this PR: TFY admin confirms ownership of ESW and ACADEMICS and a registry row is added

Post-merge: no backfill, DDL or registry write. The release PR #1968 has main as its head, so it picks this up once merged; the Lambda changes when that release is promoted to production. I have not deployed anything.

Linear: SURTR-1411

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- The first attempt to apply ddl/003_20260918_source_contract.sql failed at statement 1 with permission denied for schema mart_education (the dedicated owner user surtr_mart_education_guide_roster_owner has no CREATE on that schema). The atomic batch aborted and the live procedure is unchanged (checked against a pre-apply snapshot of its body, owner and ACL).

- Re-running it now returns the same statement id and replays the old failure without executing anything. The script submits with a fixed Data API ClientToken, so a retry is treated as a duplicate of the failed attempt.

- Fix: bump MIGRATION_CLIENT_TOKEN to ...-20260918-v2, the same convention the two GuidePlatform raw migrations used after their first failed attempts. No SQL or logic change.

## Business Value

Lets the GuidePlatform recovery finish: without a new token the consumer procedure migration cannot be re-submitted, and the Guide roster evidence chain stays pinned to the old source contract while the raw publication moves to the new one.

## Manual Effort Estimate

About 30 minutes of focused work by hand: recognising that the retry replayed the old statement id, bumping the token, running tests and lint. Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/mart-education-guide-roster-refresh: 77 passed, 5 skipped (no test references the token)

- [x] ruff check pipelines and ruff format --check pipelines clean (ruff 0.15.22, CI's pin)

- [ ] After merge: run the DDL below (NOT applied yet)

## DDL instructions (post-merge; nothing has been applied)

Runbook: pipelines/runners/guide-platform-raw-sync/contracts/schema-drift-2026-09-18.md, step 2. Keep the Guide roster success trigger disabled (no rule exists today).

1. Snapshot the live procedure (body, owner, ACL) for rollback: SELECT pg_get_userbyid(proowner), array_to_string(proacl,' | '), prosrc FROM pg_proc ... for mart_education.sp_refresh_guide_roster_evidence.

2. Apply. The DDL header says to run as the procedure owner, but that user lacks CREATE on mart_education (statement 1 is denied), so run as admin. Verified in a scratch schema that a superuser CREATE OR REPLACE PROCEDURE keeps the existing owner and ACL of a SECURITY DEFINER procedure, and the batch restores the ACL explicitly. The script's own preflight requires the live owner to be surtr_mart_education_guide_roster_owner first.

   cd pipelines/runners/mart-education-guide-roster-refresh
export REDSHIFT_CLUSTER_IDENTIFIER=redshift-cluster-1 REDSHIFT_DATABASE=finance_dw REDSHIFT_DB_USER=admin
uv run python scripts/apply_ddl.py --apply ddl/003_20260918_source_contract.sql
uv run python scripts/verify_catalog.py --catalog-only

3. Expect "status":"pass" from both. An unknown Data API outcome is a stop condition; do not retry.

Whether the owner user should be granted CREATE on mart_education is a permissions decision for the warehouse owners and is not changed here.

Linear: SURTR-1413

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Migration 004 (GuidePlatform schema additions) failed its own post-condition guard on its first live run (2026-09-20 10:31 UTC, statement 7182ba54-1e91-486f-98e3-b16dcd7e4658): expected_grants was 9, not 12. The atomic batch rolled back and the four views were confirmed byte-identical to a pre-apply snapshot, so nothing changed in the warehouse.

- Root cause: ALTER TABLE ... OWNER TO "CQL_download_OM" on capture_images (owner == writer) makes Redshift discard the writer's explicit grant records, so its three visible SELECT/INSERT/DELETE rows vanish. The three admin-owned views are unaffected.

- Fix: repeat the writer GRANT after the owner change for capture_images (23 statements instead of 22), bump the migration's idempotency token to -v2 (as the earlier 003 migration did after its first attempt), and pin the order in the structural test. No guard is weakened and no expectation changed.

## Evidence

Scratch schema as admin (dropped afterwards, nothing outside it touched), replaying the migration's statement pattern with the guard's own predicate SQL evaluated in the same transaction:

| Statement order for the writer-owned view | ACL | writer S/I/D rows |

|---|---|---|

| live baseline (what the guard expects) | CQL_download_OM=arwdRxtDPA/CQL_download_OM | 3 |

| create, grant, owner (current 004) | same ACL | 0 |

| create, owner, grant | NULL | 3 |

| create, owner only | NULL | 0 |

| create, grant, owner, grant again (this PR) | same ACL as baseline | 3 |

Full guard replay: before this change exactly one predicate mismatches (expected_grants 9 vs 12); after it all 14 predicates match, both in-transaction and after commit (12 expected grants, 18 target columns).

## Business Value

Unblocks recovery of guide-platform-raw-sync, which has failed daily since 09-18 (last green 09-17) and feeds the Guide roster evidence chain. Until this lands the runner deployed in release #1961 fails closed on the clean-view shape check.

## Manual Effort Estimate

About 3 hours of focused work by hand: reading the guard, building a scratch-schema replica of the migration, testing statement orders against real Redshift catalog behaviour, then the DDL, token and test change. Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/guide-platform-raw-sync: 129 passed; the updated structural test fails against the old DDL

- [x] ruff check pipelines and ruff format --check pipelines clean (ruff 0.15.22, CI's pin)

- [x] Scratch-schema replay of the fixed order: all 14 guard predicates match; scratch schema removed (0 remaining)

- [ ] After merge: run the DDL steps below (NOT applied yet)

## DDL instructions (post-merge; nothing has been applied)

Order matters; this follows contracts/schema-drift-2026-09-18.md. Run from main. The next scheduled raw sync is 05:35 UTC; until step 4 succeeds it fails closed (prior publication preserved). Keep the Guide roster success trigger disabled throughout.

1. Confirm no execution of pipeline-guide-platform-raw-sync-prod is running and there is time before the next 05:35 UTC run.

2. Raw migration, guarded and atomic, as admin. An unknown Data API outcome is a stop condition: do not retry.

   cd pipelines/runners/guide-platform-raw-sync
REDSHIFT_DB_USER=admin uv run python scripts/run_ddl.py --apply --apply-migration guide-platform-schema-additions

Expect "terminal success and exact clean-catalog verification". Snapshot the four views' definitions first if you want a rollback reference.

3. Consumer migration, then catalog verification:

   cd pipelines/runners/mart-education-guide-roster-refresh
uv run python scripts/apply_ddl.py --apply ddl/003_20260918_source_contract.sql
uv run python scripts/verify_catalog.py --catalog-only

4. Fresh raw extraction (not a redrive): start the pipeline-guide-platform-raw-sync-prod state machine with {"pipeline_id":"guide-platform-raw-sync","trigger_type":"ON_DEMAND","triggered_by":"<you>","params":{},"run_options":{"skip_failure_notification":false,"reason":"schema-additions recovery"}}. Verify the immutable manifest, all 57 raw and clean tables, primary-key uniqueness, clean projection validation, ledger source_contract_version=68617d..., and the 18 new clean columns in the same publication.

5. Run the Guide roster source inventory and consumer verification against that publication. Only after they pass and the CDK trigger gate passes may the success trigger be enabled.

Rollback: the raw migration is one atomic batch, so a failure leaves the views unchanged (as on 09-20).

Linear: SURTR-1406

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

claude.ai Enterprise spend is not in fct_ai_spend, and _person_cte never read raw_claude_ai_chat_usage, so the People tab showed no claude.ai spend for anyone (it was attributed only to a BU). This adds it per person, end to end.

- New claude_ai branch in _person_cte: cash cost (cost_usd_actual x the 6.6% sales-tax uplift, same as the BU level), the five raw token columns, provider claude_ai, and the person resolved through the alias registry (_registry_email, registry-first) so it merges into the canonical row. product (claude_code / chat / cowork) stands in for the missing model, labelled claude.ai/<product> in the by-model breakdown.

- One shared definition of claude.ai dollars: CLAUDE_AI_DATE / _WINDOW / _ROW_COST / _TOTAL_COST in ai_costs_service.py. All four BU-level claude.ai queries and the new People branch build from them, so the per-person sum and the BU-level provider total cannot drift. The BU-level SQL and params are byte-identical to before (16/16 statements compared).

- Provider plumbing: _person_cte returns a fifth claude_ai_in flag and the leaderboard binds one trailing [start, end] pair per enabled branch. The providers filter includes / excludes the branch.

- Person detail folds the person's claude.ai rows in (_merge_claude_ai_usage, same ownership expression as the leaderboard, so alias rows land on the canonical person and both views agree), includes them in the prior window for the change %, and no longer 404s a person only the claude.ai feed knows. BU filter and detail RBAC gate still key off the directory BU.

- NULL / blank user_email rows are kept under one (claude.ai no-email) person, because the BU-level total counts them (as Unmapped); dropping them would break the tie-out.

- Client: the People tab's By-provider column and the person modal name and colour providers through the shared AICosts constants, which had no claude_ai entry; added the fixed colour (same as the AIAdoptionV2 charts) and the Claude.ai label. No type changes needed: AISpendProvider already has claude_ai, and the People types are Record<string, ...>. The people models use provider: str, so the Provider Literal (BU-level models only) is deliberately untouched.

## Ticket

KLAIR-3558 (https://linear.app/builder-team/issue/KLAIR-3558/add-claudeai-per-person-spend-to-the-people-tab)

PR 3 of a stack: KLAIR-3557 #3799 (merged) -> KLAIR-3559 #3800 (merged) -> KLAIR-3558. Both earlier PRs have merged to main; this PR was rebased onto main (2 commits, no conflicts, tests re-run: 519 passed).

## Business Value

The largest slice of AI spend for heavy Claude Code users becomes visible per person: one executive's ~$39K quarter of claude.ai showed as nothing on the People tab, so budget owners and leadership were looking at an empty row for their biggest spender. Per-person claude.ai numbers now appear alongside the other providers and tie out to the BU-level claude.ai total leadership already sees.

## Manual Effort Estimate

Proposed: ~1-1.5 working days of focused time (about 8-12 hours) to hand-build, incl. backend, client and tests. @Keval please confirm or adjust — this is an AI-proposed number.

## Test plan

Backend (klair-api/):

- uv run pytest tests/test_ai_costs_mart_service.py tests/ai_spend_rank tests/budget_status tests/routers/test_ai_costs_router_bu_scoping.py tests/mart_saas_metrics/test_fct_ai_spend.py -q -> 317 passed, 1 deselected (PR 2: 309 passed, 1 deselected; +8 new tests).

- Same set plus tests/test_ai_costs_service.py (the BU-level claude.ai total / uplift / override tests, which pass unmodified) -> 519 passed, 1 deselected.

- Every test file that imports ai_costs_service / ai_costs_mart_service -> 1018 passed, 2 failed. The 2 failures are tests/test_aws_spend_service.py::TestGetTrends::test_get_trends_without_filters_no_join and ::TestCheckNetAmortizedBudgetExists::test_returns_true_with_dates_when_budget_exists. They fail identically on the unmodified #3800 head, and are unrelated (AWS spend).

- uv run ruff format --check . and uv run ruff check . clean, also with the CI-pinned uvx ruff@0.15.22.

- uv run pyright services/ai_costs_mart_service.py services/ai_costs_service.py -> 1 error, ai_costs_service.py:1722 (ProjectCostItem missing children). Pre-existing: the same error is at :1707 on the #3800 head, and none of it is in a changed hunk.

- sqlglot (Redshift dialect) parse of every generated production statement: 82 captured (leaderboard x3 variants, person detail for canonical / alias / no-email, the four BU-level claude.ai shapes; 32 touch the claude.ai table) -> 82 parsed, 0 failed.

- BU-level SQL identity: total, by-BU, by-period (daily / weekly / monthly) and time-series (3 granularities), with and without a BU filter = 16 statements -> byte-identical SQL and params vs the #3800 head.

- Mutation check: 20 mutants (tax uplift dropped, window edge, registry skipped, sentinel dropped, date pair missing, branch always on / off, detail merge / prior / 404 guard, RBAC gate, token column, model label, provider label, and four in the shared constants) -> 20/20 killed.

Client (klair-client/):

- pnpm vitest run src/screens/AICosts src/screens/AIAdoptionV2 src/hooks/useActivityExplorer.spec.tsx -> 46 files, 535 tests passed (includes the 3 new specs).

- pnpm lint:pr, pnpm prettier --check on the touched dirs, pnpm tsc -p tsconfig.app.json --noEmit, pnpm build -> all clean.

What the new backend tests do (synthetic data only, e.g. jane.doe@example.com): they run the production SQL of both the People views and the BU-level totals on sqlite (%s -> ?, Redshift-only scalar functions shimmed):

- Reconciliation: per-person claude_ai cost sums to _claude_ai_total, _claude_ai_by_bu and _claude_ai_by_period for a window with inclusive edges, an alias in mixed case, NULL and blank emails, an unknown user, and out-of-window rows.

- Alias merge, sum-preserving (with a no-registry control).

- Provider filter includes / excludes the branch; additivity (every other provider's per-person numbers are unchanged with claude.ai rows present; all-providers == others + claude.ai).

- Detail == leaderboard (requested by canonical email or alias): cost, tokens, provider split, models, prior window, and the TF seat-covered $500 row stays $0 cash.

- BU filter and RBAC gate, including a claude.ai-only person and the no-email bucket.

- Drift guard (BU-level queries and the People branch share the constants; literals appear only in their definitions) and param interleaving (every reuse of the CTE binds the trailing claude.ai date pair, and only when in scope).

Existing tests changed (mechanical, no assertion weakened): the _person_cte tuple unpacks now take the fifth flag; test_person_cte_carries_seat_cost_column... counts 4 0.0 AS seat_cost (new branch); test_person_cte_resolves_every_branch_through_one_shared_registry_fragment counts 6 registry copies and 10 %s and checks the new branch's email expression; the shared sqlite DDL gained the claude.ai and override tables (the all-providers CTE now reads the former).

## Reviewer call-outs

1. Product decision (open): should claude.ai count in the per-person cost view? It already counts at BU level (with the tax uplift). After this it also feeds total_cost, cost rank and sort on the People tab. The weekly budget-status email's Top-10 spenders table reads the same leaderboard (services/budget_status/orchestrator.py::_fetch_top_tables, providers=None, bus=[bu]), so it now includes claude.ai too. If the answer is no, the branch is already gated by the providers filter, so "off by default" is a small follow-up.

2. Data check (open): which BU does an individual's claude.ai spend land in? BU level resolves override > directory exact email > guarded local part > Unmapped; the People tab uses only the directory BU of the resolved person. So (a) a user whose email is not in the ESW directory reads Unmapped at BU level and shows here as an Unmapped person; (b) a user attributed at BU level via an admin override or the local-part fallback lands in a different BU here; a BU-filtered People view and the detail RBAC gate follow the People BU; (c) an alias's spend is booked under the alias's own directory BU at BU level and under the canonical person's BU here. Unfiltered totals reconcile; per-BU slices can differ for such users. To check on dev (Redshift), list users where the two BUs differ:

   SELECT c.user_email,
COALESCE(o.bu_override, d.business_unit, dl.business_unit, 'Unmapped') AS bu_level_bu,
COALESCE(d.business_unit, 'Unmapped') AS people_tab_bu,
SUM(c.cost_usd_actual) * 1.066 AS cost
FROM staging_finance_ai_spend.raw_claude_ai_chat_usage c
LEFT JOIN core_finance.ai_spend_bu_overrides o
ON o.provider = 'claude_ai' AND o.entity_id = c.user_email
LEFT JOIN staging_gsheets.esw_people_accounts d ON d.email = LOWER(c.user_email)
LEFT JOIN (SELECT email_local, MAX(business_unit) AS business_unit
FROM staging_gsheets.esw_people_accounts
GROUP BY email_local HAVING COUNT(DISTINCT business_unit) = 1) dl
ON dl.email_local = SPLIT_PART(LOWER(c.user_email), '@', 1)
WHERE c.usage_date BETWEEN '<start>' AND '<end>'
GROUP BY 1, 2, 3 ORDER BY cost DESC;

Rows with people_tab_bu = 'Unmapped' are the Unmapped people; rows where the two BU columns differ are the override / fallback cases. (Approximation: it uses the raw email; the People tab uses the canonical person's directory row.)

3. Reconciliation guarantee. For any window, the sum of per-person claude_ai cost equals the BU-level claude_ai provider total, by construction (one set of constants for rows, date and cost) and by test (production SQL of both views, byte-identical BU SQL, drift guard). It holds for the unfiltered total; see (2) for per-BU slices. On dev: page GET /api/ai-costs/people/leaderboard?providers=claude_ai&limit=100&... and sum provider_cost.claude_ai, then compare with provider_breakdown.other_providers.claude_ai from GET /api/ai-costs/summary for the same dates. The leaderboard rounds per person to cents, so expect rounding-level differences only. Like the BU level, it relies on the ESW directory being one row per email; a duplicated directory email would fan out both views (pre-existing, all providers).

4. No double count (confirmed from the code). fct_ai_spend builds only anthropic / cursor / gcp / bedrock / openai / perplexity (022_fct_ai_spend.sql; _BU_PROVIDER_KEYS is pinned by test_fct_ai_spend.py), so no mart branch carries claude.ai cash; the OpenAI-token branch is zero-cost; and TrueFoundry seat-covered Claude routes (claude-max% / claude-teams% / claude-pro%) are priced at $0 by _TF_CASH_COST. claude.ai actual cash enters only through the new branch. The Anthropic branch (claude_code_key_* API keys) is the Anthropic API org, a separate billing stream.

5. Latency (not measured). One extra branch on raw_claude_ai_chat_usage (windowed on usage_date, its leading sort key) inside the 6 CTE reuses of a leaderboard request; the detail adds 2 small queries (merge + prior window). No warehouse access from here, so no timings; worth comparing /people/leaderboard response time on dev before / after.

6. Unverified. Nothing ran on Redshift. Evidence is sqlite execution of the production SQL plus the sqlglot Redshift parse. Worth a glance on dev: UNION ALL type unification for the new branch's cost / tokens / model, and the 'claude.ai/' || ... concat with its GROUP BY in the detail query.

7. Size. +501 / -51 lines, about 62% tests. If you want it smaller, the split point is the detail path (_merge_claude_ai_usage + prior window + their tests, roughly 130 lines) or the client label / colour commit.

8. Not fixed (known limits). The registry stays flat (one hop); the TF name-fold is not passed through the registry. Other claude.ai readers with their own scope (the /truefoundry page KPIs, the BU-override manager) use pre-tax cost and are untouched.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Adds spec 10 under features/surtr/ai-spend-pipeline/specs/10-person-identity-seeds/: two hand-reviewed source-email aliases for core_finance.ai_spend_subject_identity, both mapping to arthur@trilogy.com.

- 01-identity-seeds.sql: first application only, one transaction in the repo's guarded-migration idiom (SELECT 1 / CASE ...). Non-destructive — no DELETE. Guard 1 aborts if either seed slug already has any row (identical or not), so the file only ever writes into an empty slot and a row for these slugs cannot pre-date it; guard 2 aborts unless exactly the two rows exist, mapped correctly and written by one INSERT (one shared added_at); COMMENT ON TABLE is one short line.

- 02-verification.sql: precondition report, a before/after checksum proving unrelated rows are untouched, seed assertions, duplicate/chain checks, and an assertion that the deferred key row is absent.

- 03-rollback.sql: one transaction; deletes only when exactly the two rows 01 wrote are present — all four values match (slug, target email, notes, added_by; enumerated, never a pattern) and they share one added_at. A later duplicate writer (3+ rows / two timestamps) aborts the guard; an edited row is left alone; already-rolled-back is a no-op.

- spec.md: an Evidence and apply gate table for every row and a Deferred section. FEATURE.md: ticket row, files-touched line, changelog row.

- Docs/SQL only. Not applied: applying is the same manual prod step as specs 1 and 6-9. No effect on Klair surfaces until KLAIR-3557 (and 3558) ship.

## Review follow-up (Mercy, round 1)

- Critical — atomicity / restoration: the DELETE + INSERT is replaced by a guarded, transactional, insert-if-absent seed. Nothing is deleted, so there is nothing to restore; a conflicting pre-existing row aborts the run instead of being replaced. *Class audit:* the only other writer of this registry on main is the spec 3 seed (a one-off DELETE + INSERT of one TrueFoundry row, historical and already applied) — left as is and noted in the spec; new seeds should copy this spec's pattern.

- High — unconfirmed key mapping: the Artie2-Key api key row is removed from every executable file and deferred to a follow-up spec gated on written owner confirmation (02 section 2c asserts it is absent until then). *Class audit:* every remaining row now has its evidence and apply gate recorded in spec.md.

- Critical (round 4) — rollback provenance: matching a row's own values cannot prove it wasn't there before 01. Fixed at the cause: 01 is now first-application-only (aborts on any existing row) so nothing matching can pre-date it, and 03 requires exactly the two rows written together. *Class audit:* 03 is the only cleanup path; no notes/comment provenance tests remain.

- Critical (round 3) — rollback ownership: the rollback used notes LIKE '%SURTR-1403%', a mutable free-text marker. It now matches the exact inserted row values (all four columns) and fails closed. *Class audit:* the only cleanup path using notes as provenance; 02's notes check is exact too.

- Critical (round 2) — COMMENT length: flagged as over a 256-byte Redshift limit; that limit does not appear to exist here (Surtr main has 457 longer COMMENT ON statements), but the comment is now 244 bytes anyway so the seed does not depend on it.

## Ticket

SURTR-1403 https://linear.app/builder-team/issue/SURTR-1403/seed-ai-spend-subject-identity-with-multi-email-person-aliases-arthur

Pairs with KLAIR-3557 / KLAIR-3559 / KLAIR-3558 (the stacked Klair PRs that read these rows).

## Business Value

Makes per-person AI spend attribution correct for a person whose spend is split across several identities: an executive's ~$46K quarter was showing as under $100 per person because it was spread across several emails that the People tab could not merge. Seeding the registry lets the aliases be credited to one person, so budget conversations use the real number. It also sets the pattern for future merges: one reviewed, evidenced row at a time, applied atomically, never name-matching heuristics.

## Manual Effort Estimate

Proposed: ~2 hours of focused time to hand-build (spec, seeds, verification, rollback), plus ~30 minutes for the review rework. @Keval please confirm or adjust — this is an AI-proposed number.

## Test plan

- [x] Static review only. Nothing was executed against a warehouse (no warehouse access in this session). All three SQL files parse under sqlglot's Redshift dialect (01: transaction, guard, insert, comment, guard, commit, check; 03: transaction, guard, delete, commit, check), and the seed literals are consistent across every file.

- [ ] Before applying: clear the apply gate for each row (spec.md), then run 02-verification.sql sections 0 and 1 and keep the output.

- [ ] Apply 01-identity-seeds.sql in one session (BEGIN ... COMMIT); its closing SELECT returns 2 rows. If it aborts on a guard, nothing was applied.

- [ ] Run 02-verification.sql (after): section 1 other_rows and other_rows_checksum identical to before; section 2b returns 1, 1, 2, 2; section 2c returns 0; sections 3 and 4 return 0 rows; section 5 lists slugs by kind.

- [ ] 03-rollback.sql is the undo; only needed if verification fails.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Bump the Shipyard app version to 0.6.0.

- Add the reviewed public release notes for this version.

## Business Value

- Let users create Linear tickets without assigning them to a project.

- Make release creation explicit so opening release history does not start a new release.

## Implementation Effort

- Small: metadata-only release preparation; the underlying product changes are already merged into main.

## Test plan

- pnpm test:release

- git diff --check

## Summary

- Add a persisted No project choice to the Linear project picker.

- Permit Research approval with an explicit no-project choice.

- Omit the Linear CLI --project argument for tickets created without a project.

- Add focused regression coverage for projectless and project-backed issue creation.

## Business Value

Users can create Linear tickets from approved Research artifacts even when the work does not belong to a Linear project.

## Implementation Effort

Estimated 4–6 hours for an average engineer to trace the picker and persistence flow, update ticket dispatch, and add regression coverage without AI assistance.

## Linear

https://linear.app/builder-team/issue/AI-853/add-an-explicit-no-project-choice-for-linear-ticket-creation

## Test plan

- [x] pnpm build

- [x] pnpm test:workflow (30 Node tests and 75 Rust workflow tests passed)

## Summary

The AI Budget Tracking People tab only recovered an Anthropic key to a person when the key was named claude_code_key_<local>_<hash> and <local> mapped to exactly one directory email. Every other key is typed "Product" and shows up only in the API Keys tab, so a person whose real spend sits on a personal key with a non-standard name reads as $0 in People.

Decision (settled, not revisited here): keys are NOT credited to their creator. Product keys are shared infrastructure; creator-based attribution would flood the People leaderboard and per-person budget alerts and move dollars across BU dashboards. Instead this PR credits a reviewed key -> person mapping held in the same registry PR 1 introduced, core_finance.ai_spend_subject_identity: subject_slug = the Anthropic api key id (the mart's entity_id for provider anthropic, entity_type api_key), user_email = the person.

- Anthropic branch of _person_cte, restructured (no behaviour change for existing rows): the directory recovery d is now a LEFT JOIN with the claude_code_key_ name gate moved *into* the join (d.email is NULL for every other key), plus a LEFT JOIN of the collapsed registry irk on LOWER(s.entity_id). A row is kept when either resolves: WHERE s.provider = 'anthropic' AND (irk.email IS NOT NULL OR d.email IS NOT NULL). Previously it was JOIN d ... AND <name filter>.

- Guards live in the irk join, so irk.email is NULL (never a match) for any entity_type other than api_key and for NULL/empty entity_id (billed-remainder rows), even if the registry ever held an empty slug.

- Precedence / no double count: one row per mart row, so a key that is *both* claude_code_key_*-named *and* registry-mapped is counted once and the registry wins. The person is COALESCE(ira.email, irk.email, d.email) where ira is the registry lookup of the key's owner (the mapped email, else the directory email), so a mapped email that is itself an alias resolves to the canonical person (key -> email -> canonical email; no further).

- Person detail (_person_filter) uses the same three joins and the same ownership expression, so leaderboard and detail agree by construction and the detail's per-key list includes registered keys. The BU RBAC gate is untouched and still runs on the resolved person's directory BU before any spend query.

- Case-insensitive: the registry stores the key id as issued (mixed case); the collapsed registry lowercases it and the mart side is LOWER(s.entity_id).

- No new query parameters (every param list / interleaving is unchanged). Company and BU totals are unchanged (BU dashboards read the mart directly); the People total gains exactly the mapped key's dollars, once.

- Unregistered Product keys are unchanged (still API-Keys-tab only).

Out of scope, follow-ups: the API Keys tab still types registered keys as "Product" (_MART_KEY_CLASS); an admin UI for key mappings.

## Ticket

KLAIR-3559 — https://linear.app/builder-team/issue/KLAIR-3559/credit-registry-mapped-personal-api-keys-to-their-person-in-the-people

PR 2 of a stack (KLAIR-3557 #3799 -> KLAIR-3559 -> KLAIR-3558). #3799 has merged to main; this PR was rebased onto main (single commit, no conflicts, tests re-run: 309 passed). The first data row (key id -> person) is deferred: Mercy's review of Surtr PR #1967 / SURTR-1403 asked that it not ship until the key's owner confirms it is a personal key, so it will follow as its own spec. This PR works without any registry row (no row = no change for a key), so it does not depend on that row and can merge independently; there is no visible effect until a key row is applied.

## Business Value

A person's real API spend on a personal key with a non-standard name is now credited to them instead of vanishing from the per-person view (one executive showed $0 for the last month despite ~$1.2K of API spend), without ever crediting shared product keys to whoever happened to create them. Per-person budget alerts and the weekly budget emails become trustworthy for these users, and BU dashboards do not move.

## Manual Effort Estimate

Proposed: ~0.5 working day of focused time (about 3-4 hours) to hand-build, incl. tests. @Keval please confirm or adjust — this is an AI-proposed number.

## Test plan

- cd klair-api && uv run pytest tests/test_ai_costs_mart_service.py tests/ai_spend_rank tests/budget_status tests/routers/test_ai_costs_router_bu_scoping.py tests/mart_saas_metrics/test_fct_ai_spend.py -q -> 309 passed, 1 deselected (PR 1 baseline: 293 passed, 1 deselected; +16 new tests, no regressions).

- New tests use synthetic data only (jane.doe@example.com, omar.roe@example.com, apikey_TESTKEY01..05). The executable ones run the production _person_cte / _person_filter SQL verbatim on sqlite and assert on dollars. One test per acceptance criterion: registered key credited to the mapped person on the leaderboard and in the detail filter (detail == leaderboard, key list included); unregistered non-claude_code_key key still excluded (including a decoy whose 4th _ part equals a directory local part); a key matching both paths counted exactly once, registry wins (same person and different person, and when the directory email has its own alias); NULL and empty entity_id never match, even against a hostile registry row with an empty slug; mixed-case key id matches (registry x mart case matrix); duplicate / case-variant / conflicting / targetless registry rows collapse without fan-out; wrong entity_type / wrong provider rows that merely share the id are never credited; mapped-email alias resolves one more hop and not further; totals sum-preserving (only the mapped key's dollars appear, once). Mock-based tests cover the SQL shape (no INNER join left, guards in the join, no new params) and the RBAC gate (a caller outside the person's BU gets a 404 before any spend query runs).

- Existing tests changed (4), SQL-shape assertions that legitimately moved: test_person_cte_anthropic_recovery_is_lowercased_and_uniqueness_guarded and test_person_detail_recovers_keys_via_directory_email_local (ownership is now COALESCE(ira.email, irk.email, d.email)), test_person_cte_resolves_every_branch_through_one_shared_registry_fragment (same expression; the shared registry fragment now appears 5x, not 4x: the Anthropic branch has two registry lookups), and test_person_detail_for_an_alias_resolves_to_the_canonical_person (ira is keyed on COALESCE(irk.email, d.email) instead of d.email). No assertion was weakened; bound params and the %s count are unchanged.

- uvx ruff@0.15.22 format --check and uvx ruff@0.15.22 check . (CI's pinned version) -> clean. uv run pyright services/ai_costs_mart_service.py -> 0 errors.

- Mutation check: 13 temporary mutations (drop the registry path, the entity_type guard, the empty-id guard; flip precedence two ways; drop the alias hop; INNER JOIN d; drop the name gate; drop the detail join; drop LOWER on the mart side; drop the provider guard in the CTE and in the detail; un-collapse the registry) each make at least one of the new tests fail.

- All 22 generated production statements (leaderboard CTE in every provider scope, count/page/split queries, all person-detail reads) parse under sqlglot's Redshift dialect (uv run --with sqlglot, not a project dependency). Not run against a live warehouse (no warehouse access from the author's session).

## Reviewer call-outs

- The registry must stay flat. Only key -> email -> canonical email is resolved (two lookups, tested). A registry entry *on the canonical email* is not followed for the key's owner. Map keys to the canonical email where possible.

- COALESCE order. ira is consulted before irk because it is keyed on the key's mapped email (falling back to the directory email): that is what resolves an aliased mapped email. The registry still wins over the name path (covered by tests, including the case where the directory email has its own alias).

- API Keys tab Type follow-up. Registered keys still show as "Product" there; only the People tab changes.

- Latency (unverified on Redshift). The person detail runs 5 mart queries, each now carrying one more small registry derived table (irk, so 3 registry scans + the directory subquery, up from 2 + 1). The leaderboard CTE (reused by ~5 queries per request) gains the same one scan in its Anthropic branch. The registry is tiny, but note the Anthropic branch now hash-joins all anthropic mart rows in the window (the name gate moved from WHERE into the d join) instead of only claude_code_key_ rows. Mart grain is day x key x model against tiny dimensions, so I expect it to be negligible; dev deploy is the first real measurement.

- Could not verify (no warehouse access): sqlite executes the same SQL and the sqlglot parse proves syntax, but neither is Redshift. Worth a glance on dev: LEFT JOIN ... ON clauses that carry predicates on the preserved side only (AND s.entity_type = 'api_key' AND s.entity_id <> '', and the name gate on d), and the ira join key COALESCE(irk.email, d.email).

- Data hygiene. A registry row must never map a TrueFoundry provider-side key (those are deduped via ai_spend_tf_provider_keys) to a person: the TF branch already credits that spend to the gateway's users, so it would be counted twice on the People tab. Not guarded in SQL because the rows are reviewed.

- Blast radius. budget_status (weekly budget emails, per-person alerts) consumes get_people_leaderboard, so mapped people's totals rise there too (intended). A mapped key's dollars land in the *person's* directory BU on the People tab / email top-10s, while BU dashboards and the API Keys tab keep the key's mart BU.

- services/ai_spend_rank/leaderboard.py recovers Anthropic keys in Python with its own SQL and does not consult the registry; left as is, consistent with PR 1.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

The AI Budget Tracking People tab showed one human as several rows when they bill under several emails (e.g. Anthropic spend on one address, OpenAI spend on an alias), because only the TrueFoundry branch of _person_cte resolved identities.

- Every direct-provider branch of _person_cte (mart user rows, Anthropic claude_code_key_* recovery, OpenAI Usage-API token recovery) now resolves its person through the same registry the TF branch already uses, core_finance.ai_spend_subject_identity, registry-first: person_email = COALESCE(registry.email, LOWER(<branch email>)). For email aliases subject_slug holds the lowercase source email and user_email the canonical person email.

- The registry is collapsed to one row per key (GROUP BY LOWER(subject_slug), MIN(LOWER(user_email)), non-empty filter) exactly like the existing TF si join, so duplicate or conflicting registry rows can never fan out fact rows. It is built once as module-level helpers (_IDENTITY_REGISTRY, _registry_join(alias, key_expr), _registry_email(fallback, *aliases)); the TF si join now reuses them (generated TF SQL is byte-identical after whitespace normalisation, and nothing resolves a TF row twice). The joins add no query parameters, so the start/end interleaving in get_people_leaderboard and the detail reads is unchanged. Later PRs in the stack reuse the helpers (documented next to them).

- Person detail uses the same expressions (_person_filter now returns (joins, where, params) built from the shared per-branch constants), so a canonical person's detail includes every alias's rows and leaderboard/detail agree by construction. A detail request for an alias resolves to the canonical person instead of 404ing (one extra tiny registry lookup); the response person_key/email are the canonical ones. The BU RBAC gate runs on the *resolved* person's directory BU, exactly what the leaderboard's BU filter matches on, and 404 messages echo the requested email so a denied caller never learns the canonical address.

- Registry only. No directory name-fold guessing for direct rows (some folds are different people; a wrong merge would move dollars across BU dashboards and weekly emails). The existing RBAC-only AI_BUDGET_EMAIL_ALIASES map is untouched.

- Scope notes: budget_status (weekly budget emails) consumes get_people_leaderboard, so it picks up merged rows automatically. ai_spend_rank/leaderboard.py has its own SQL (openai/cursor user rows + Anthropic recovery in Python, no registry, no TF), does not call the mart service, and is intentionally left as is.

- Behaviour to be aware of: a merged person now lives in the canonical person's directory BU on the People tab / weekly-email top-10s (previously the alias's spend sat under the alias's own directory BU). The registry is one hop and expected to be flat.

## Ticket

KLAIR-3557 — https://linear.app/builder-team/issue/KLAIR-3557/resolve-email-aliases-to-one-person-for-direct-provider-spend-in

PR 1 of a stack (KLAIR-3557 -> KLAIR-3559 -> KLAIR-3558). The data seeds live in Surtr ticket SURTR-1403, so this has no visible effect until those registry rows exist.

## Business Value

Budget owners and leadership now see one person's spend across all of their email identities instead of a fragment of it (an executive's ~$46K quarter was showing as under $100 per person). That makes per-person budget alerts, weekly budget emails and spend conversations trustworthy.

## Manual Effort Estimate

Proposed: ~1 working day of focused time (about 6-8 hours) to hand-build, incl. tests. @Keval please confirm or adjust — this is an AI-proposed number.

## Test plan

- cd klair-api && uv run pytest tests/test_ai_costs_mart_service.py tests/ai_spend_rank tests/budget_status tests/routers/test_ai_costs_router_bu_scoping.py tests/mart_saas_metrics/test_fct_ai_spend.py -q -> 293 passed, 1 deselected (main baseline: 282 passed, 1 deselected; +11 new tests).

- New tests use synthetic people (jane.doe@example.com / jane.d@alias.example). Executable ones run the production _person_cte / _person_filter SQL verbatim against sqlite: alias merged into one person across all providers and each branch in isolation (mart user rows, Anthropic key recovery, OpenAI tokens, TF), sum-preserving (merged row == sum of the fragments), registry miss passes through unchanged, duplicate / case-variant / conflicting / empty-target registry rows collapse without fan-out, and the detail filter for the canonical person selects exactly the leaderboard's rows. Mock-based tests cover the SQL shape (one shared registry fragment x4, no new params), alias detail resolving to the canonical person, and the RBAC gate keying off the canonical person's BU without leaking its email.

- Two existing tests updated because their SQL-shape assertions legitimately changed: test_person_cte_anthropic_recovery_is_lowercased_and_uniqueness_guarded (branch now selects COALESCE(ira.email, d.email)) and test_person_detail_recovers_keys_via_directory_email_local (key recovery is now a LEFT JOIN with a registry-first ownership expression instead of an IN subquery; bound params unchanged).

- uv run ruff format --check and uv run ruff check . (ruff 0.15.22) -> clean. uv run pyright services/ai_costs_mart_service.py -> 0 errors.

- Mutation check: temporarily breaking each branch's registry resolution, the registry collapse, alias canonicalisation and the 404 no-leak each makes at least one new test fail.

- All 12 generated production statements (leaderboard CTE, detail reads) parse under sqlglot's Redshift dialect. Not run against a live warehouse (no warehouse access from the author's session): reviewer/CI dev deploy is the first real Redshift execution.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- sales-educrm-mart-sync intermittently marks one mart table failed, and the run PARTIAL, when the Athena UNLOAD hits INVALID_VIEW ... Table '...' does not exist while an upstream dbt run is rebuilding a table the mart view reads. In the last 14 days that happened in 18 of 670 runs, always in the :35 slot, on mart_changelog_dtl (13) or mart_pipeline_agg (5). The missing table was int_dim_program, int_dim_contact or stg_deal_pipeline_stage. No :05 run failed this way, so each table healed on the next scheduled run.

- Retry: an UNLOAD that fails with INVALID_VIEW naming a missing object is retried, 4 attempts in total, sleeping 20s, 40s, then 80s (140s at most). The gap looks short: in the 8 runs where mart_changelog_dtl failed on int_dim_program, mart_pipeline_agg (which reads the same table) UNLOADed successfully 26-28s later. Most transients should therefore clear on the first or second retry.

- Error text: run_query now raises AthenaQueryError (a RuntimeError) carrying the query id and Athena's StateChangeReason, capped at 500 chars. results_by_table[...].error in the run row now shows why a table failed. It previously said only UNLOAD <table> failed with status: FAILED.

- Deliberately narrow: only INVALID_VIEW plus "does not exist" is retried. Permission, syntax, TABLE_NOT_FOUND, other INVALID_VIEW causes (for example an unresolved column) and every other error still fail at once, now with their reason. The same 14 days also had one HIVE_CANNOT_OPEN_SPLIT and one Athena internal error; both are left alone here as separate causes.

- Time budget: a table that stays missing adds about 155s to that table's worker only (140s of sleep plus ~5s per extra attempt). Median run is 76s and the Lambda timeout is 900s. Even with all 39 tables blocked for the whole budget (two waves of the 20-worker pool) the run would take roughly 6 minutes. A test pins the sleep budget to at most a quarter of timeout_seconds.

- For reviewers, log alarms: each failed attempt still logs one ERROR line (existing wait_for_query behavior). The new retry lines are INFO and contain none of the alarm filter terms. A recovered transient now logs 1 ERROR line (was 2) and the run completes. A persistent failure logs about 5 ERROR lines per table (was 2) against log_error_threshold: 10 over 5 minutes, so two tables failing persistently at the same time would now reach the threshold.

## Business Value

About 1 in 37 half-hourly syncs (18 of 670 over 14 days) leaves a mart table stale for an extra 30 minutes and marks the run PARTIAL, a false alarm that heals itself. Retrying inside the run removes both the staleness and the noise for this transient case. When a table does fail for real, the run row now says why, so triage no longer needs a CloudWatch dive to find the Athena reason.

## Manual Effort Estimate

About 3.5 hours of focused work by hand: roughly 1h confirming the failure pattern and the length of the gap in CloudWatch, 30min for the retry and error class, 1.5h for the fake-Athena fixtures and 16 tests, and 30min for lint, CI parity and the PR. Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/sales-educrm-mart-sync: 49 passed (33 existing + 16 new)

- [x] New tests run against main's unchanged source: 15 failed, 34 passed (the one new test that passes on both is the first-attempt-success guard)

- [x] Mutation check on the classifier in a scratch copy: also retrying TABLE_NOT_FOUND, any INVALID_VIEW, or every error each fails the matching no-retry test

- [x] ruff check pipelines and ruff format --check pipelines (ruff 0.15.22, the CI pin): clean

- [ ] After deploy, in /klair/pipelines/prod/sales-educrm-mart-sync, search for view dependency missing, retrying and (attempt 2/4) to confirm recoveries, and confirm INVALID_VIEW stops producing PARTIAL runs over a few days

- [ ] After deploy, if any table still fails, confirm its error in the run row carries the Athena reason

Post-merge: this needs the normal deploy of the runner only. There is no DDL or backfill, pipeline.json and dependencies are unchanged, and there are no new third-party imports, so src/requirements.txt needs no change. Nothing has been deployed.

Linear: SURTR-1402

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- aws-bedrock-token-metrics has reported partial_failure on every daily run since at least 09-12, because any account-region failure flips the status. All 107 failures in the latest run (09-20) are the two known external access gaps from #269 / #606: 45 assume_role_denied (EY, VDI and Totogi accounts that do not trust ESW-CO-ReadOnly-P2) and 62 scp_denied (the Umbrella/Khoros SCP denying cloudwatch:ListMetrics). The run's own known_failure_context already said "All 107 ... match", yet the status stayed PARTIAL, so a genuinely new failure class would have been invisible.

- The status is now partial_failure only for (a) an account-region failure outside the known set, (b) a failed master payer, or (c) a failed secondary write. The summary gains known_failures, known_failures_by_pattern and unexpected_failures, and each failure record gains error_code and operation. This follows KNOWN_UNPRICED_MODELS in openai-usage-pipeline, and it is the product call that #1671 explicitly left open.

- Matching is strict. A failure is known only if its classified reason, exact AWS error code, exact API operation and message marker all match. An AccessDeniedException, an SCP deny on GetMetricStatistics, a ListMetrics deny from a non-SCP policy, a ValidationError that merely names the role, or a throttle all stay unexpected. The scp marker changes from listmetrics to the SCP wording because the classifier files every "explicit deny" under scp_denied.

- Unchanged on purpose: the ingestion-ledger row still says partial whenever any account-region fails (those accounts' usage is still not collected, and PIPELINE_CONVENTIONS 5.4 says changing an outcome string is not a ledger migration), the hard-fail floor, and the write path. test_empty_but_scanned_clears_window_as_partial now uses an SCP deny on GetMetricStatistics so it still exercises an unexpected failure.

- For the reviewer: a new account that fails in the same two classes counts as known automatically (the +5 on 09-16 was one new Totogi account, five regions). A growing known_failures is visible in the summary but nothing alerts on it; alerting on growth would be a separate follow-up.

## Business Value

The Bedrock token-metrics run has looked unhealthy every day for over a week, and the partial-run notifications and at-risk view built on it are noise. Failures owned by external account admins no longer keep the pipeline flagged, so the next real problem (an unrecognised error, a failed master payer, or a failed secondary write) is the only thing that turns it PARTIAL. The known gap stays on the record every day through known_failures and the ledger. No data changes: the same 46 accounts' usage was already landing.

## Manual Effort Estimate

About 4 hours of focused work by hand: roughly 1 hour to trace the status, ledger and known-failure code and confirm the real failure shapes in the logs, 1 hour for the strict matcher and status change, 1.5 to 2 hours for the 18 tests (real error shapes, near-miss cases, ledger and secondary-write guards), and 30 minutes for lint and the PR. Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/aws-bedrock-token-metrics: 99 passed (81 before plus 18 new). Against the old handler, 13 of the new or updated tests fail.

- [x] ruff check pipelines and ruff format --check pipelines (ruff 0.15.22, the CI pin): clean.

- [x] Replayed the recorded failures of the 8 most recent runs (09-12 to 09-20) through the new matcher: 107/107 and 102/102 classified known, 0 unexpected, so each would have reported success.

- [x] Checked the last 2 days of prod logs: every failure line is one of exactly two shapes (AccessDenied on AssumeRole for ESW-CO-ReadOnly-P2, and AccessDenied on ListMetrics with an explicit SCP deny).

- [ ] After merge and deploy: the next 07:00 UTC run reports status: success with known_failures: 107 (45 assume_role_denied, 62 scp_denied) and unexpected_failures: 0, and the pipeline leaves the at-risk list.

Post-merge: deploy the pipeline image through the normal release flow. No backfill or DDL is needed, and earlier PARTIAL runs stay in history unchanged.

Linear: SURTR-1401

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Every run of tfy-provider-secrets-sync since 2026-09-08 (13 of 13) has finished PARTIAL. OPENAI_DAYBREAK_KEY is unresolved on all of them (expected one OpenAI user match, found 0), and OPENAI_API_KEY_ESW and OPENAI_API_KEY_ACADEMICS joined on 09-16 (metadata rows 13 to 15; lookup status unset that day, found 0 from 09-17). SURTR-1222 (09-12 run) is the observer ticket for this; SURTR-1215 (09-11 run) is a duplicate of the same alert.

- #1841 (merged) only added identifiers_written to the summary so the observer stopped reading the run as empty. It did not touch the PARTIAL status, so the alert kept firing.

- Only OPENAI_DAYBREAK_KEY is listed in KNOWN_UNRESOLVED_SECRET_NAMES (reconciler.py) and returned as known_unresolved (also logged at INFO as KNOWN_UNRESOLVED_TFY_PROVIDER) instead of unresolved. It is the long-standing key whose dedupe is already handled by a hand-created registry row. Any other unresolved secret (a new one, an unknown provider value) or nothing resolving still makes the run partial, and hard errors still fail the run.

- ESW and ACADEMICS intentionally stay flagged. They are new, have no registry row, and may carry undeduplicated TFY-routed spend. They stay in unresolved, so the run still reports partial until the TFY admin confirms ownership and a registry row is added (or the keys resolve). This PR only removes the Daybreak noise; it does not stop the daily alert. With today's three unresolved secrets a run reports status=partial, unresolved=[ESW, ACADEMICS], known_unresolved=[DAYBREAK].

- Stale-close hazard, resolved by construction. RedshiftRepository.reconcile closes every open registry row not in the resolved set for each provider in complete_provider_types, then clears is_truefoundry_routed on the affected usage rows. The hand-created OpenAI user_id row in core_finance.ai_spend_tf_provider_keys (id 16, the Daybreak key) is not in that set, because the resolver cannot find the key. So marking OpenAI reconciled would close it. Live check: 1,230 raw_openai_cost_reports rows, $167,138.86 (09-04 to 09-19), are flagged TFY-routed only because of that row.

- The change therefore only splits the reported list, after complete_provider_types is computed from the resolution counters. A known secret still counts as unresolved for its provider, so OpenAI stays out of stale-close and the statements sent to Redshift do not change.

Not done here: real resolution, and the follow-up for ESW and ACADEMICS. The TFY admin has to confirm who owns those keys, after which a registry row is added in core_finance.ai_spend_tf_provider_keys (or the key name is fixed so it resolves). This PR writes nothing to the registry.

For the reviewer:

- ESW and ACADEMICS keeping the run partial is deliberate, so the daily alert keeps pointing at a possible dedupe gap. I could not find them by name in usage (no api_key_name containing esw or academ since 08-01), so I could not size that spend.

- The known list is a code constant, like KNOWN_SKIPPED_PROVIDERS, so an unset config cannot silently mask anything. Its comment and the README say a key may be listed only while a manual registry row covers it.

## Business Value

This removes the long-standing Daybreak noise from the PARTIAL signal, so PARTIAL now points only at the two newer keys (ESW, ACADEMICS) that have no registry row and may carry undeduplicated spend. Those two keep alerting until the TFY admin follow-up lands. It is reporting-only, so the roughly $167k of OpenAI spend that is deduplicated through a hand-maintained registry row stays deduplicated, and the mechanism is in place to demote each remaining key once its registry row exists.

## Manual Effort Estimate

About 3 hours of focused work by hand: roughly 1 hour to read the reconcile and stale-close path and confirm the hazard against the registry and usage tables, 30 minutes for the change and README, and 1.5 hours for the ten tests (fake Redshift client, SQL-identity proof, mutation checks). Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv sync --all-extras then uv run pytest tests in pipelines/runners/tfy-provider-secrets-sync (Python 3.11.11): 45 passed (35 before, 10 new); 11 tests fail on unchanged source (the 10 new and the updated summary test)

- [x] ruff check pipelines and ruff format --check pipelines (ruff 0.15.22, as CI): clean

- [x] test_run_with_the_current_unresolved_openai_keys_stays_partial_for_esw_and_academics_only uses the real known list through the handler and a fake Redshift client: partial, unresolved is ESW and ACADEMICS, known_unresolved is Daybreak, and no SET effective_to

- [x] test_known_unresolved_openai_secret_never_closes_existing_openai_registry_rows (the hazard proof): the SQL batch is identical with and without the known list, with no SET effective_to and no NOT IN

- [x] Mutation check, not committed: counting known secrets as resolved, or dropping them from the completeness count, makes the guard tests fail (2 and 3 failures), and the first one emits the stale-close UPDATE

- [x] Replay of a synthetic 10-secret set (the three unresolved OpenAI keys plus resolved Anthropic, Gemini and OpenAI) through origin/main and this branch: unresolved goes from ESW, ACADEMICS, Daybreak to ESW, ACADEMICS with Daybreak in known_unresolved, status stays partial, the 13 SQL statements are byte-identical, and stale-close is issued only for Anthropic and Gemini

- [ ] After the change is deployed, the next 05:00 UTC run still records PARTIAL, with unresolved listing only ESW and ACADEMICS and known_unresolved listing Daybreak

- [ ] Follow-up, not in this PR: TFY admin confirms ownership of ESW and ACADEMICS and a registry row is added; only then does the run return to SUCCESS and the observer stop ticketing it

Post-merge: no backfill, DDL or registry write. The Lambda changes when main is next promoted to production (CD deploys pipelines when pipelines/runners/ changes); that is for whoever runs the promotion, and I have not deployed anything.

Linear: SURTR-1222

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- sf-transcripts-sync has been PARTIAL on every run since 09-17. One Salesforce Task (00Tfu00000qwqP4EAI) has a Transcript_URL__c with no 069... ContentDocumentId, so it can never be fetched. process_tasks recorded it under errors, and _next_watermark pins the watermark below any failed task, so the S3 watermark has sat at 2026-09-16 12:47:10 while the re-fetch window grew (21, 34, 46, 46 tasks).

- process_tasks now returns those tasks in a separate skipped dict ((ok, n_err, errors, skipped)). Only the "no ContentDocumentId" case moves. no ContentVersion, download failures, HTTP 5xx and auth failures are unchanged: still errors, still partial_failure, watermark still pinned below the earliest failure.

- skipped (task id -> reason) is written to the S3 run summary, returned in the handler output when non-empty, and logged at INFO, so the bad record stays discoverable. The run is complete and the watermark advances. backfill counts skipped tasks instead of reporting them as errors.

What I checked, and what I did not:

- S3 run summaries: 76 runs since 07-08, and the only ones with a non-empty errors are 09-17 to 09-20, each holding this one task.

- Redshift staging_software_salesforce.raw_trilogy_task (read-only SELECT): this task's Transcript_URL__c is a Task Files related-list link (/lightning/r/Task/<id>/related/AttachedContentDocuments/view), not a file link. 20 of 4,790 Tasks with a URL have no ContentDocumentId (read.ai meeting links, Google Docs/Drive links, this one), and none has a raw_trilogy_call_transcript row. So this is a recurring class of source data, not a one-off.

- Not verified: I did not call Salesforce or read credentials. The URL shape above comes from the warehouse's raw copy of Task, which may lag Salesforce. I also did not check whether the transcript file is attached to that Task (a ContentDocumentLink lookup by Task might recover it; that would be a separate change).

For the reviewer:

- This reverses an original design choice. The old _next_watermark docstring and test_malformed_transcript_url_holds_watermark deliberately treated an unparseable URL as a failure that pins the watermark. I moved it because a retry cannot fix it, and PIPELINE_CONVENTIONS.md 5.4 separates execution health from source findings. The classification is a regex miss on the URL, not an HTTP status or a caught exception.

- no ContentVersion for <doc> stays an error. It can be permanent (file deleted) or transient (access, lag), and I have no evidence to split it.

- A skipped task is listed in the run where it falls in the window; once the watermark moves past it, it is not re-listed each day. This is a run-summary finding, not a durable ledger row. To list every such Task, select from raw_trilogy_task where transcript_url__c has no 069... id.

- The new log line is INFO and avoids error/warning wording on purpose: this pipeline's log alarms (threshold 1) fire on those terms, and a source-data skip is not a failure.

## Business Value

sf-transcripts-sync has reported PARTIAL every day since 09-17 over one Salesforce Task with no fetchable transcript link, so its status is permanent noise that would hide a real download or auth failure, and every run re-downloads a growing window. After this change a run with only unfetchable links is complete, a real failure still shows as PARTIAL, and the unfetchable Tasks stay listed in the run output for whoever owns the source data. Downstream is unaffected, since that Task never had a row in raw_trilogy_call_transcript.

## Manual Effort Estimate

About 3 hours of focused work by hand: reading the handler and confirming the pipeline state in S3 and Redshift (about 1 hour), the change across process_tasks, sync, backfill and the handler (about 30 minutes), reworking and adding tests for the skipped, transient and mixed paths (about 1 hour), and lint, CI-parity runs and the write-up (about 30 minutes). Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/sf-transcripts-sync: 32 passed on Python 3.11 (as CI) and 3.12. Against the unchanged handler, 17 of the 32 fail.

- only unparseable URLs in the window: complete, ids under skipped, watermark advances to the batch max, S3 run summary lists the id

- unparseable URL plus a transient download failure: partial_failure, watermark pinned 1s below the transient failure (not advanced, and not dragged down to the skipped task)

- all tasks good: output has no skipped key, watermark advances as before

- backfill counts skipped tasks and stays complete

- [x] ruff@0.15.22 check pipelines and ruff format --check pipelines (the version CI pins): clean

- [ ] After merge and deploy, the next 05:30 UTC run returns complete with the one task under skipped, and state.json moves past 2026-09-16 12:47:10

Post-merge: deploy pipeline-sf-transcripts-sync through the normal release path. No backfill and no hand edit of state.json are needed. The first run after deploy re-fetches the current window (about 50 tasks) once; the upsert is by task_id, so it is idempotent.

Linear: SURTR-1400

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Cause. The usage endpoint pages over per-user result rows, not over days. Alpha's 2-day window outgrew one page on the 09-17 run, so the window's last day now comes back on both pages (page 1 = [day1, day2], page 2 = [day2]). fetch_credit_usage flattened pages with extend, so the handler saw two buckets for one day and its duplicate-day guard (#1703) refused the run: Org 'Alpha' returned more than one day-bucket for day(s) ['2026-09-18']. Same error on the 09-17, 09-18, 09-19 and 09-20 runs (for 09-15, 09-16, 09-17, 09-18).

- Change. In fetch_credit_usage, a day that continues onto a later page is joined into one bucket (results concatenated in page order). handler.py is unchanged, so the guards from #1742, #1746, #1748 and #1845 are untouched. The raw-payload archive now also holds one bucket per day, so it replays through the same guards.

- Still refused, by design.

- A user on both pages of a day: rows are kept, never deduplicated or summed, so _transform_bucket's per-user duplicate check still raises.

- A day repeated within a single page, or two buckets with the same start_time but a different end_time: not joined, so the handler's duplicate-day guard still raises.

- Why this is a page continuation and not overlapping data (CloudWatch logs and Redshift SELECTs only):

- Page 2 is requested with the identical window as page 1 ([1789603200, 1789776000) on 09-20); only the page cursor differs.

- The duplicated day is always the last day of the window, and page 2 always carries exactly one bucket. Alpha was single-page on every run through 09-16. The largest single-page window was 137 rows (~45 user-days, 09-13 + 09-14); the smallest paginated one was 181 rows, consistent with a page cap between those sizes.

- Not a full repeat: 09-14 is in Redshift at 86 rows (published from a single-page response). The 09-17 run returned 181 Alpha rows for [09-14, 09-15], leaving 95 for 09-15. A page 2 that repeated all of 09-15 would need (181 - 86) / 2 = 47.5 rows, which is not an integer.

- Not verified. I did not see the raw API response: failed runs abort before the payload is archived, and I did not read the API key to make a live call. So whether page 2's users are strictly disjoint from page 1's is enforced at runtime rather than proven here. If they overlap, the run still fails loudly (per-user duplicate error naming the users) and nothing is published.

- After merge (not done in this PR). Deploy, then backfill 2026-09-10..2026-09-18. raw_perplexity_usage has no rows for 09-10..09-12 or 09-15..09-18, and the schedule (T-3..T-2) will not revisit them. 09-15..09-18 are the days this fix unblocks; 09-10..09-12 were originally stopped by other guards (Trilogy "no response at all" on 09-10/09-11, the per-org-day skip ceiling on Alpha 09-12), which this PR does not change, so a backfill that stops there is a separate issue.

- Separate issue: PARTIAL may persist. jc.fischer@trilogy.com (Alpha) was skipped on 11 of the 13 runs since 09-08. On recent days it is a promo-only user-day (0 paid) whose Credit Source breakdown is 4 to 5 credits short of its total (e.g. 6 of 11 on 09-17, 13 of 17 on 09-18) against a tolerance of 3; earlier days had no Credit Source breakdown at all. Each skip sets status: partial_failure, so runs will likely still report PARTIAL even though the data publishes. The unaccounted credits are worth at most about $0.05 a day if they were all Paid. Not addressed here.

## Business Value

Restores the daily Perplexity per-user usage feed, which has no data after 09-14 and has failed every run since 09-17 on a false duplicate alarm. Alpha carries essentially all Perplexity spend in the table (about $2.8k to $3.0k a day on 09-13 and 09-14, Trilogy about $0), so AI-spend reporting has been missing four days of the largest Perplexity spender. It also clears a recurring pipeline-failure alert.

## Manual Effort Estimate

About 4 hours of focused work by hand: roughly 1.5 h reading the run history in CloudWatch and Redshift to establish this is pagination and not overlapping windows, 0.5 h re-reading the guards from #1703, #1742, #1746, #1748 and #1845, 0.5 h for the change, and 1.5 h for the ten tests (including two end-to-end handler cases). Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/perplexity-usage-pipeline: 348 passed (338 before this change, 10 new)

- [x] New tests fail without the change: 6 of the 10 fail on unfixed code (the handler case reproduces the production error text); the other 4 pin behavior that must not change (same day twice on one page, differing end_time, distinct days across pages, same-page repeat at the handler)

- [x] ruff check pipelines and ruff format --check pipelines (ruff 0.15.22, as CI): clean

- [ ] After deploy: the next scheduled run (06:00 UTC) completes with Alpha's split day joined (log line continues a day from an earlier page) and no more than one day-bucket error

- [ ] After deploy: backfill 2026-09-10..2026-09-18 via params.start_date / params.end_date (not run from this PR)

- [ ] After backfill: raw_perplexity_usage has rows for 09-15..09-18, and GROUP BY event_date, org_name, user_email, model HAVING COUNT(*) > 1 returns nothing

Linear: SURTR-1399

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Release history navigation was passing a generated request ID into the release window, which started a Codex conversation as soon as the window mounted. The window now loads existing history and opens the requested tab; creating a release remains an explicit action through New release.

## Business Value

Users can inspect release notes and instructions without accidentally starting a release conversation or triggering its drafting workflow. Starting a release now reflects a deliberate action.

## Implementation Effort

Estimated hand-coding effort: about 1–2 hours, including tracing the navigation state, updating the component contract, and adding regression coverage.

## Test plan

- [x] node --test scripts/test-project-releases.mjs

- [x] pnpm build

## Linear

[AI-852: Release history opens without starting a conversation](https://linear.app/builder-team/issue/AI-852/release-history-opens-without-starting-a-conversation)

## Summary

Prepare Shipyard 0.5.2 with the reviewed public release notes.

## Business Value

- Delivers the approved patch release with the latest user-facing reliability improvements and workflow updates.

## Implementation Effort

- Metadata-only change: package.json version bump and public release notes.

## Test Plan

- [x] pnpm test:release

- [x] git diff --check

- [x] Verified the exact diff contains only package.json and releases/0.5.2.md.

## Business Value

Users can address one PR review round per manual run beside Smoke Test. A run captures outstanding feedback, fixes valid findings, replies in the original threads without resolving them, then closes its conversation. Later feedback waits for another explicit run in a fresh conversation. An unused review node does not hold up task completion. Users can also review and publish edited node prompts directly in the app; new runs use the selected immutable version immediately.

## Changes

- Add the fifth workflow node above Smoke Test and an explicit Run PR Review action. Require completed implementation and a linked PR, and reuse the verified implementation worktree, including commits from prior review fixes.

- Keep Smoke Test independent. Deduplicate requests and lost acknowledgments, prevent overlapping rounds, and retain previous conversation IDs in operation history.

- Version the canonical PR Review prompt as 1.1.0, retaining the original request and adding explicit feedback capture and stopping rules. Already addressed but unresolved threads do not trigger duplicate work. Newly arriving feedback waits for the next manual round; the agent must not keep polling automated reviews after pushing.

- Store immutable template content in SQLite and capture each operation's version, hash, and assembled prompt. Upgrading from 1.0.0 preserves the old content and in-flight run snapshots; retries use their captured input.

- Make successfully completed review conversations read-only. Suppress queued follow-ups after live or recovered completion, reject native writes to closed/superseded rounds, and ignore late runtime events that would reopen them. Failed or interrupted turns can explicitly continue the same round. Other conversation types retain normal follow-ups.

- Recover completed review rounds from durable turn/runtime evidence when an older live production instance still owns the conversation. Keep its ownership, exclude active/failed/superseded rounds, and reject writes before routing to an older owner. This unlocks the next manual run after a dev-app restart without replaying prior work.

- Keep newly opened conversations connecting while their first rollout metadata is being persisted, using bounded retries for the specific empty-rollout error. Check status can repair a failed attachment; attachment never resends a prompt.

- Release SQLite locks before creating, replacing, or cleaning up template editor chats. Serialize editor opens separately to avoid freezing the UI and workflow coordinator.

- Derive editor preview status and checksum from the local Markdown bytes on every preview read. Refresh the open preview and sidebar after edits without reopening the editor conversation or losing unsent text. Show Local draft and the version used by new runs; preserve published content, immutable version history, and existing operation snapshots.

- Add Publish to the template preview. Validate the displayed draft checksum and active identity, atomically store and select a new local version, preserve published history and captured runs, and retain local publications across restarts and bundled updates. Duplicate requests are idempotent; stale previews and failed writes do not change the active version. Keep the chat and unsent text intact while preview and publication requests finish.

## Validation

- Rust library suite: 194 passed, 2 existing ignored tests.

- Latest focused frontend regression run: 58 passed across node templates, attachment/recovery, PR Review UI, and task workspace. The earlier broader feature validation passed 128 workflow, review, recovery, conversation store, message, and template checks.

- TypeScript, theme checks, production Vite build, and native builds passed. After the final editor-guidance correction, its focused Rust regression test also passed.

- Publication regressions cover all four templates, simultaneous requests from separate database connections, empty/missing/stale drafts, failed activation rollback, immutable history, restart and bundled upgrade/rollback, preserved editor text, and future review rounds using new content while queued and recovered rounds retain the old snapshot.

- Draft-preview regressions cover edit/revert detection, preserved published identities and conflicts, absent files, unchanged reads causing no SQLite writes, preserved editor text, stale response isolation, hidden/unmounted views, coalesced refreshes, and refresh error recovery.

- Regression coverage includes fresh threads per manual run, read-only completion from live events and reconnect history, queued-message suppression, interrupted continuation, unchanged ordinary chats, superseded-round guards, and 1.0.0 provenance retained through retry while future enqueues capture 1.1.0.

- Native dev testing exposed and reproduced the earlier attachment race and template-editor deadlock. Closure behavior is tested through the actual React hook/components with controlled native calls and the Rust workflow/runtime. The smoke harness regression suite passed 28 tests.

- Restarted the native dev app after the user-triggered review round finished. Verified its runtime is ready with no active turn, PR Review is marked Local draft with a checksum matching the edited file, published 1.1.0 remains active, and both immutable versions remain stored. The dev frontend returned HTTP 200. No new review round was triggered during this check.

- Fixture-backed desktop run e7f0f1ca-8a06-4482-b9fa-f2d9ccd615c5: visually verified the Publish control, clicked it for an isolated PR Review draft, observed 1.1.0+local.1 / Synced and success feedback in the native UI, and confirmed unsent editor text remained intact. Rebuilt/restarted and verified the same version/content/checksum remained active. The harness reported no new integration effects from publication or restart and was stopped afterward. Evidence: .smoke/runs/e7f0f1ca-8a06-4482-b9fa-f2d9ccd615c5/report.json and template-publication-evidence.json.

- Agent stopping behavior has explicit evaluation cases in docs/PR_REVIEW_EVALS.md; those live-model evaluations have not been run. Deterministic tests verify application boundaries, not model compliance with the prompt.

<details>

<summary>Startup-race reproduction and template provenance</summary>

- Classification: deterministic product-code defect in conversation attachment; the reusable template needs no change.

- Observed node: pr-review; workflow run: 46a17006-a764-4945-9469-15ff132727a8; conversation: 01a0bd35-dd52-7251-ad9b-d128af37b1ed.

- Captured template: v1.0.0, SHA-256 133dde24356fb125e7554c918c4d5fa3f1642e885ce81322c5d04914fcba3958, containing: "Check if review feedback is valid and fix. Respond accordingly on the threads but dont resolve the threads".

- Smallest reproduction: open a new review conversation after its thread identity is published but before its first rollout metadata entry is readable. codex_open_thread_stream fails with failed to read session metadata ... rollout at ... is empty, leaving the UI permanently in its attachment-error state while the review turn starts successfully.

- Trace: attachment began at 2026-09-20T05:06:59.174Z and failed after 12 ms. The first rollout metadata entry is timestamped 05:06:59.199Z.

- Expected behavior: wait briefly, attach to the existing conversation, and retain the active turn without replaying its prompt. A later Check status must also restore the event stream after attachment retries are exhausted.

- A subsequent native process sample captured get_node_template → create_thread_with_prompt → local_request waiting to reacquire the SQLite mutex it already held. The main UI thread was then waiting for that mutex in get_task_github. The isolated review worker continued producing output while the app window was frozen. Both node and artifact editor create/replace paths now use short database scopes around a separate editor lock; regression callbacks attempt the same nested settings access with try_lock so failures are deterministic rather than hanging the test.

</details>

<details>

<summary>Review-round reproduction and template provenance</summary>

- Classification: mixed issue. Template 1.0.0 lacked a stopping rule, and product code permitted completed review conversations to reopen through follow-ups.

- Observed node: pr-review; operation 46a17006-a764-4945-9469-15ff132727a8; conversation 01a0bd35-dd52-7251-ad9b-d128af37b1ed. Captured template 1.0.0, SHA-256 133dde24356fb125e7554c918c4d5fa3f1642e885ce81322c5d04914fcba3958.

- One resumed operation kept processing new automated findings after each push. The scheduler had not triggered another run.

- Smallest reproduction: begin with finding A, then post B after A's fix is pushed. The first conversation should finish after A; B should be handled only after another explicit Run PR Review in a fresh conversation.

- Restart testing also reproduced an older production owner recording the successful terminal turn and ready runtime while leaving the PR Review node in progress. The updated coordinator now applies the missing completion rule from those persisted facts; two regression tests cover recovery, idempotence, ownership preservation, and excluded states.

- Candidate template 1.1.0, SHA-256 4c757c14d9faf6632522d4cfe0136ba08ea0b7bb8eeed8155d05eba451572fbb. Existing run prompts are not rewritten.

</details>

<details>

<summary>Draft preview reproduction and template provenance</summary>

- Classification: deterministic product-code defect in preview metadata; no reusable template content changes are needed.

- Observed node pr-review, operation d4bcb232-7458-4368-b885-6200e8c050b5, captured template 1.1.0, SHA-256 4c757c14d9faf6632522d4cfe0136ba08ea0b7bb8eeed8155d05eba451572fbb.

- The editor rendered app-data Markdown with SHA-256 9a49068f5c627a338eab06096e46a340ff5a4fbb5a6a0c8d099cec4466a018c2, but the badge and checksum still used startup metadata. New runs correctly captured the active SQLite version.

- Smallest reproduction: edit the local prompt after startup, then reopen the editor or leave it open while the chat edits the file. The preview must show Local draft and the current local checksum, while identifying the published version used by new runs. Refreshing must not publish or rewrite the draft or send another editor prompt.

</details>

- POC schema: fresh databases accept source=local. The existing development database received a backed-up, one-time local schema conversion; no compatibility backfill was committed. Existing template versions and draft bytes were preserved.

## Linear

https://linear.app/builder-team/issue/AI-847/add-an-optional-user-triggered-pr-review-workflow-node

## Implementation Effort

Estimated 12–16 hours for an average engineer to implement and validate manually without AI assistance.

## Why this PR exists

#139 was stacked on #138 and merged into the stacked branch (jev-verify-independence), not main, after #138 had already been squash-merged. Its commit 6c450b8 is not an ancestor of main, and main has none of its additions (_questions_digest, _verification_row, depth_probabilities).

This is #139's commit cherry-picked onto current main. git diff 6c450b8 HEAD -- harness .github is empty, so the content is byte-identical to what was reviewed in #139: 4 files, +295 / −7. Please review #139 for the substance; there is nothing new here to review beyond confirming the two are the same.

What it adds (telemetry-only; no change to the verdict path or to what is sent to TypeSafe): per-finding numeric calibration rows under typesafe_shadow.verification.evaluations[], a questions_digest on both phases, and strategy.depth_probabilities. Full rationale, the Surtr-ingest compatibility check, and the size measurement are in #139.

## Verification

- On top of current main: harness/tests 560 passed, heimdall/tests 1264 passed / 1 skipped, ruff check and ruff format --check (pinned 0.15.22) clean.

## Context worth knowing

Artifacts from the last 28 Surtr Mercy runs show the pilot has produced no Jev data yet: every strategy artifact is error / missing_key. TYPESAFE_API_KEY exists as a Surtr secret, but Surtr's live caller workflow does not pass it to the reusable workflow (Surtr #1957 adds that and is still an open draft). This PR is unaffected; it just means the rows it adds start filling only once that lands.

## Business Value

Same as #139. The Jev pilot needs per-finding distributions, not argmax counts, to show whether its confidence tracks accuracy on Mercy's findings, and the rubric digest keeps that evidence valid as questions are edited. Honest scope: this only captures the data, and today nothing is flowing (see above), so the value is realised after the key pass-through lands and someone joins rows to outcomes.

## Manual Effort Estimate

~0.25 hours focused, no AI, for this PR by itself (a cherry-pick, a byte-identical check, and re-running the CI commands). *Proposed; Keval to confirm/adjust.* The substantive effort (~4h proposed) belongs to #139's ticket and should not be counted twice.

## Linear

Same ticket as #139 (one ticket, one PR); ID not yet added because Linear isn't reachable from the session that drafted this. Left as a draft until it is.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Stack 3 of 3, built on https://github.com/AI-Builder-Team/Aerie/pull/1408 (navigation), which is built on https://github.com/AI-Builder-Team/Aerie/pull/1407 (classification and payload contract). Base is the navigation branch, so this diff shows only this PR's work.

This is the piece that makes the page answer "where are the differences?" and lets the answer be shared.

- Where the differences are panel at the top: for each of the 19 compared fields, how many joined sites differ on it (real vs formatting only, as a stacked bar), sorted by count descending, each with 3 example sites showing the raw production and Surtr values as literals. Fields that agree everywhere are listed on one line. A field that differs on every site is the tell for a representation artifact rather than a data disagreement, and here the reader can see the actual values that differ instead of guessing (for example null vs []).

- Click a field to filter: the site list narrows to the sites that differ on it. Because that spans mismatched and formatting-only sites, it switches to the All tab, and a chip clears it. The tab counts follow the filter.

- Export CSV: site_id, field, kind, production, surtr for every differing field of every site in the current view (the whole filtered list, not just the 50 rendered). kind is real, formatting or unparseable. Values are the same JSON-style literals the page shows, so null, "" and [] stay distinguishable in a spreadsheet. Written through the shared CSV writer, which neutralizes formula-shaped cells (covered by a test).

- Copy summary: plain text with the headline counts (Matched / Formatting only / Mismatched, production only, Surtr only), any data-quality warnings, and the per-field panel with examples. It always describes the whole payload, independent of the filters. A missing or refusing clipboard raises a toast (through the shared toUserMessage pathway) instead of failing silently.

All client-side; the route and the payload are unchanged in this PR.

One change outside the comparison page: the shared downloadCsv (chat/components/dashboards/shared/csv-export.ts) already caught and logged a failed download but told the caller nothing. It now returns true once the download is triggered and false when it failed, still never throwing, and the Export CSV button raises a toast on false. Existing callers (school ops, diligence, diligence work units, P&L breakdown) ignore the return value and are unaffected; their suites pass. Those four exports still do not tell the user when a download fails; that is pre-existing and left for their own PRs. Mercy noted it as a deferred, non-blocking finding.

## Class audit across the stack

The user asked for whole error families rather than single instances. Across the three PRs:

- Representation differences treated as data disagreement: null vs [], null vs ''/whitespace, timestamp format and precision, and (found while auditing valuesMatch) a blank string silently equal to a real zero and an array equal to a scalar. All fixed or classified in the first PR. Anything not documented stays a real difference and shows up in this panel with its raw values, rather than being guessed away.

- The inverse family, where a UI hides a representation difference: null, [] and '' were all rendered as a dash or blank. Values now render as literals everywhere: table, panel, CSV and copied text.

- Small-row-count and flat-list assumptions: pagination, tabs and search in the second PR; per-field summary here. The route still returns every row in one response (about 1 MB at today's size, a few MB at the cohort's 1000-row soft cap); noted, deliberately not changed.

- Mercy's one finding on the first PR (offset minutes not range-checked) was fixed for the whole parser (every clock component, and years below 100), not just the cited line.

## Business Value

The page exists to decide whether Surtr's REBL3 mirror can be trusted against production. The reviewer's first question is "which fields disagree, and are they real?", and this panel answers it in one screen: on a payload shaped like the live one, a single field disagreeing on every site is visible immediately, with the two raw values side by side, so the team can accept or reject a normalization rule in minutes instead of opening hundreds of rows. Export and copy make the finding portable: a spreadsheet for the Surtr owner and a paste-ready summary for the thread, which is how these questions actually get resolved.

## Manual Effort Estimate (proposal, for Keval to confirm/adjust)

About 5 focused hours for this PR by hand with no AI: per-field summary with samples and ordering about 1.5h; panel, field filter and chip about 1.5h; CSV rows, summary text and clipboard/toast error handling about 1h; tests, including the formula-injection and clipboard-failure cases, about 1h. Whole three-PR stack: about 20 focused hours.

Linear: no ticket filed yet (no Linear tool in this session); to be linked.

## Test plan

- [x] pnpm --dir chat exec vitest run on the report, lib, route, view and page test files: 179 passed, plus the new downloadCsv browser test: 3 passed; and the school ops, diligence, financials and shared dashboard suites that use the CSV helper: 924 passed

- [x] pnpm --dir chat exec tsc --noEmit

- [x] pnpm lint (only 2 pre-existing warnings in an unrelated file)

- [ ] Not verified in a browser: the page is behind Clerk auth and the Next dev server is not run in this workflow. The CSV download and clipboard write are exercised at their boundaries (the shared downloadCsv and navigator.clipboard are mocked), so the real file save and the real clipboard permission prompt are unverified.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Fixes four defects in the Jev verification shadow (#137) that made its Jev-vs-Mercy agreement statistics unreliable. Shadow-only: no change to decide_review.py, the verdict, decision.json, or any GitHub-write path.

| # | Defect | Fix |

|---|---|---|

| 1 | Jev was sent Mercy's own category, severity and verdict (current_decision), then asked to judge category and impact *independently* — it could echo the answer it is later compared against. | Send only {finding, evidence} via an allowlist (_JEV_STATE_KEYS); Mercy's labels stay local. |

| 2 | run_verify read the unfiltered review_output.json, so findings under the keep threshold — which decide_review drops — were verified and counted as if Mercy had reported them. | Verify only findings with confidence >= threshold (resolved from the same --config decide_review gets) and check the count against decision.findings_kept. A mismatch is a loud reported_set_mismatch error, not a silently wrong population. |

| 3 | category is a free string; decide_review normalizes error-handling → silent_bug in memory only. The telemetry validator rejects non-canonical categories, so one such label voided the *entire* verification record (status: invalid, all counts zero) while the artifact itself said ok. | Record decide_review.normalize_category(...) — the category Mercy actually acted on. |

| 4 | Severity disagreement rounded Jev's score, which is the probability-weighted *mean*. A 45/55 split between levels 1 and 3 averages to 2.1 → "warning", a level Jev put no mass on. | Compare the level carrying the most probability mass; an exact tie goes to the higher level. |

Also: --config on typesafe_shadow.py verify and the workflow step passes .mercy-config/${CONFIG_PATH} (same expression as the decide step). Malformed findings (non-object, or unreadable confidence) stay in scope as explicit invalid_finding errors rather than vanishing.

## Impact on existing data

- Verification rows recorded since #137 merged (2026-09-19) had Mercy's labels in the Jev request, so their category_disagreements / severity_disagreements are biased toward agreement. Exclude them, or filter on mercy_version.

- How often #2 bites: the review agent is instructed to emit only findings ≥ 80, so at the default threshold it is mostly latent. It matters for consumers with a higher confidence_threshold, or whenever the agent over-emits. The cross-check makes it detectable either way.

- How often #3 bites is unknown — the schema itself documents that near-miss labels occur. Worth checking typesafe_shadow.verification.status = 'invalid' in Surtr telemetry.

## Testing

- CI commands run locally: harness/tests 556 passed, heimdall/tests 1264 passed / 1 skipped, ruff check + ruff format --check (pinned 0.15.22) clean, actionlint clean.

- Mutation-checked: re-introducing each defect in a scratch copy fails the specific intended test (labels sent to Jev, threshold ignored, cross-check skipped, raw category, rounded mean, --config unwired).

- Includes a boundary test that feeds real run_verify output through the real telemetry reducer — #3 lived in the seam between the two modules, which neither module's own tests covered.

- No live TypeSafe call was made; the network call is stubbed.

## Business Value

Mercy is piloting Jev (~$0.042 / MTok, sub-second) as an independent second signal on review strategy and finding verification, to decide whether it can gate or replace some of the multi-agent LLM passes that dominate a review's cost and latency. That go/no-go rests entirely on the shadow data. Before this PR the verification half of it could not support the decision: the labels leaked into the request, the wrong population was counted, and a single odd category could discard a whole review's record. This PR fixes the *measurement* so the eventual decision is made on real agreement rates rather than on contaminated ones. It is an enabling correctness fix, not new capability — the payoff lands once the stacked calibration PR is merged and someone analyses the data.

## Manual Effort Estimate

~6 hours focused, no AI — *proposed; Keval to confirm/adjust before this leaves draft.* Roughly: tracing the verify → decide_review → telemetry path across three modules (~1h), designing the reported-set cross-check and label separation (~1h), implementation (~1.5h), new tests for each fix, fixture updates to the existing verification tests, and the argmax rewrite of the severity tests (~2h), workflow edit and CI-equivalent verification (~0.5h).

## Linear

Ticket: not yet created (Linear was not reachable from the session that drafted this). Project: *Surtr Agents (Mercy + Heimdall)*, Builder Team (AI-). Left as a draft until the ticket ID is added here; move it In Progress → Done around merge.

## Stack / follow-ups

- Stacked PR (calibration data: per-finding numeric rows + rubric hash in telemetry) builds on this one.

- Deliberately not in this change: the review_depth rubric mixing a code-known truncation flag into the model's score, the multi-hop nature of the support question, pinning an exact model ID before any threshold is set, retry/backoff on 429/529, hostile-input tests, and a data-retention decision for private diffs sent to TypeSafe.

- harness/ is a critical path (.mercy.yml), so this needs a human approval by design.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Stack 2 of 3, built on https://github.com/AI-Builder-Team/Aerie/pull/1407 (classification and payload contract). Base is that PR's branch, so this diff shows only the navigation work. The per-field "Where the differences are" panel, field filtering, CSV export and copyable summary are the third PR: https://github.com/AI-Builder-Team/Aerie/pull/1409. CI only runs on pull requests that target main, so it does not run on the stacked PRs until each base merges; this PR was validated locally with the commands in the test plan.

The hidden /dashboards/real-estate/experimental page rendered every site (about 480) as one flat list of collapsed rows, worst-first, each needing a click to show anything. This PR makes that list navigable.

- Presence tabs with counts: Mismatched, Formatting only, Surtr only, Production only, Matched, All. A Duplicate id tab appears only when the payload has duplicate ids. The page lands on Mismatched, or on All when nothing is mismatched (so it is never an empty landing).

- Site-id search: case-insensitive. Search narrows the list before the tabs are counted, so a tab's count is always the size of the list it opens.

- Pagination: rows render 50 at a time with a "Show N more" step, and the page size resets when the tab or search changes. The whole inventory is never in the DOM at once.

- Row detail: each collapsed row names its differing fields, so a pattern is visible without opening anything. Expanding a row shows a compact production-vs-Surtr table of only the differing fields, with a toggle for all 19.

- Surtr-only note: a neutral note (not an alert) explaining that Surtr-only sites are expected.

- The list logic lives in a pure module, real-estate-surtr-comparison-report.ts, so tabs, filtering and counts are tested at realistic size in the node runtime.

## Surtr-only claim, verified

- Production side, in chat/convex/portfolio/activeSitesCohort.ts: the cohort SQL is FROM rebl3_status loi JOIN rebl3_sites s USING (site_id) ... WHERE loi.system = 'loi' AND COALESCE(s.excluded, FALSE) = FALSE. So the cohort is the REBL3 sites that have an LOI workflow row and are not globally excluded.

- Surtr side, in the Surtr repo mart mart_education.aerie_rebl3_sites (the refresh procedure is a direct passthrough of raw_sites, one row per site id, with no filtering, and its README calls it Surtr's first warehouse representation of REBL3's full site-acquisition inventory).

- So a site that is in REBL3 but has no LOI row (or is excluded) is expected to show as Surtr only. The note says exactly that and no more: it states that this page cannot tell why a particular site is outside the cohort, and it does not claim every Surtr-only site is explained. A production-only site (in the cohort but missing from Surtr) keeps its yellow badge, because that direction is not expected.

## Class audit

Searched the page, view, lib, route and their tests for small-row-count and flat-list assumptions:

- The view's header comment sized the design to a "~180-site cohort" and argued a matrix was unreadable at that count; the list itself had no pagination, filtering or search. Rewritten and replaced by the paginated design above.

- The "N rows" summary tiles are replaced by tabs that carry the same counts, so there is one source and no duplicated labels.

- The route still returns every row in one response (roughly 3 KB per joined site, about 1 MB at today's size; the cohort has a 1000-row soft cap, so at most a few MB). Left as is for an internal, capability-gated page, and noted here rather than silently ignored.

- Tests now run at realistic size: the shared 298 joined + 186 Surtr-only fixture drives the report, view and page tests. Slow accessibility-tree role queries over hundreds of rows are avoided in favor of plain DOM and text queries.

## Unchanged safety semantics

Unparseable-row, duplicate-id and shortfall warnings, the production-empty note, the Surtr-unavailable degradation, zero-row guards, response schema validation and capability gating, including the AccessDenied path, are unchanged and covered by tests.

## Business Value

A validation page is only useful if a reviewer can find what to look at. With about 480 collapsed rows and no summary, the page could not answer even "which sites disagree, and how?", so it produced no usable evidence about Surtr's REBL3 mirror. With tabs, search and pagination the reviewer goes straight to the sites with a real difference, sees which fields differ without expanding anything, and can open just the differing fields for one site. That turns the page from unusable into something a person can complete a check with in minutes.

## Manual Effort Estimate (proposal, for Keval to confirm/adjust)

About 8 focused hours for this PR by hand with no AI: tab and filter model, including counts that stay consistent with the filters, about 2h; paginated list, row detail and toggle about 2.5h; Surtr-only note and verifying the claim against the cohort SQL and the Surtr mart about 1h; tests at realistic size, including making them fast, about 2.5h. Whole three-PR stack: about 20 focused hours.

Linear: no ticket filed yet (no Linear tool in this session); to be linked.

## Test plan

- [x] pnpm --dir chat exec vitest run on the report, lib, route, view and page test files: 152 passed

- [x] pnpm --dir chat exec tsc --noEmit

- [x] pnpm lint (only 2 pre-existing warnings in an unrelated file)

- [ ] Not verified in a browser: the page is behind Clerk auth and the Next dev server is not run in this workflow. Built and tested against realistic fixtures only.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Adds 42-ds.com → Skyvera to DOMAIN_BU_RULES in klair-api/services/ai_spend_domain_rules.py.

- Feeds both surfaces that share the rules module: the Key Attribution modal Suggestions tab and the daily domain_rule_attribution_cron (writes core_finance.ai_spend_bu_overrides, actor system:domain-rule; manual overrides always win).

- Exact whole-domain match only, so subdomains do not match (same semantics as skyvera.com).

- Routes to the existing Skyvera BU, not the separately registered 42DS BU from #3792. This is the requested mapping.

Linear: KLAIR-3556

## Business Value

Keys owned by 42-ds.com addresses currently fall into unattributed or catch-all buckets and need manual triage in the modal. With this rule they are suggested and then auto-attributed to Skyvera, so Skyvera's AI spend and budget-vs-actuals are complete without recurring manual attribution work.

## Manual Effort Estimate

~30 min focused time by hand (find the rules module, add the rule, add tests, run lint/type/test, open PR). Proposed by Claude, for Keval to confirm/adjust.

## Rollout / data

- DDL: none. No schema change; the overrides table already exists.

- Backfill: none needed. The existing daily cron (10:00 UTC) materializes the rule for matching keys on its first run after the change reaches prod. Merging deploys to DEV only, so prod needs the manual workflow_dispatch release for this to take effect.

## Test plan

- [x] uv run ruff format / ruff check on changed files

- [x] uv run pyright services/ai_spend_domain_rules.py (0 errors)

- [x] pytest tests/test_ai_spend_domain_rules.py (54 passed), including the pin that every rule target is in ASSIGNABLE_BUS

- [x] pytest tests/crons/test_domain_rule_attribution_cron.py (16 passed)

- [ ] Cron --dry-run against Redshift was not run (no warehouse access from the worktree)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Stack 1 of 3 for the hidden /dashboards/real-estate/experimental Surtr-vs-production REBL3 comparison page ("literally unusable": 298 of 298 joined sites reported as mismatched, in one flat list of ~480 collapsed rows).

Every joined site had at least one differing field, in a mix of 3, 2 and 1 per row. That pattern points at a representation artifact rather than data disagreement, and the page made it impossible to tell: null and [] were both rendered as a dash, and '' rendered as an empty cell. This PR fixes the classification and the contract. The navigation UX (tabs, search, pagination, row detail) is the second PR in the stack; the per-field summary plus CSV export and copy is the third.

Each differing field is now classified as real or formatting-only, and the page reports joined sites as Matched / Formatting only / Mismatched.

## Normalization rules (documented in chat/lib/real-estate-surtr-comparison.ts, each covered by tests)

Baseline (valuesMatch, unchanged semantics): null equals undefined, arrays compare as sets, numeric strings compare numerically. These are reported as a match.

Formatting-only rules, symmetric, never hidden:

- blankText: '' or whitespace-only text is equivalent to no value and to each other. All fields.

- emptyList: [] is equivalent to no value. All fields.

- sameInstant: timestamp fields only (updatedAt). Both strings carry an explicit UTC offset (Z, +00, +00:00, +0000) and are at most 1000 ms apart. Parsed by hand, so the result never depends on engine leniency or the machine timezone. A timestamp with no offset never qualifies.

Deliberately not normalized, so they stay real: letter case, padding around non-blank text, float tolerance, blank text vs an empty list, timestamps more than 1000 ms apart. An undocumented representation difference will show up as real, where the per-field summary (third PR) makes it visible, rather than being guessed away.

## Where classification is computed: server-side

In buildFieldComparisons (pure lib), not in the client:

- The route counts (matchedCount, formattingOnlyCount, mismatchedCount) and row ordering depend on it, so a client-side classifier would leave the payload counts contradicting the page.

- One node-tested implementation feeds the summary tiles, badges, sort order and (in the next PRs) the per-field summary, CSV and copied text.

- Nothing is lost: the payload keeps the raw production and Surtr values plus the formattingRule name, so the client can always show exactly what each side sent.

## What changed

- real-estate-surtr-comparison.ts: classification, FORMATTING_RULE_LABELS, formatValueLiteral; payload contract match becomes kind + formattingRule, mismatchCount becomes realDifferenceCount + formattingDifferenceCount, new formattingOnlyCount; rows sort real-first, then formatting-only.

- Hardens valuesMatch: a blank string no longer equals a real zero (Number('') is 0), and an array never equals a scalar (String(['a']) is 'a').

- View: formatting-only differences render muted with their rule name; values render as literals (null, "", [], "text") so representation differences are visible; new "Formatting only" tile; Surtr-only rows get a neutral badge (production is the LOI-anchored subset of Surtr's inventory, so Surtr-only is expected).

- Unparseable handling, duplicate-id handling, shortfall warning, zero-row guards, response schema validation and capability gating are unchanged (schema updated for the new shape).

- Tests: realistic-size fixture (298 joined with mixed 1/2/3 formatting differences and a few real ones, plus 186 Surtr-only) used by the lib, route and view tests.

## Stack

Split because the full scope is roughly 3,000 changed lines (about 1,050, 920 and 990 per PR), about two thirds of it tests and fixtures, well past a single reviewable PR. Each PR builds on the previous one and is reviewable alone:

- Item 1 (this PR): classification, payload contract, visible formatting-only rendering.

- Item 2, https://github.com/AI-Builder-Team/Aerie/pull/1408: tabs with counts, site-id search, 50-at-a-time pagination, row detail with only the differing fields, and the Surtr-only note.

- Item 3, https://github.com/AI-Builder-Team/Aerie/pull/1409: the "Where the differences are" per-field panel with field filtering, CSV export and copyable summary.

Stacked PRs 2 and 3 target the previous branch, so CI (which only runs against main) does not run on them until each base merges; they were validated locally with the same commands listed below.

Mercy approved this PR with zero blocking findings; its single non-blocking suggestion (offset minutes were not range-checked independently, so +00:60 was accepted) is fixed for the whole timestamp parser, not just the cited line: every clock component is bounded on its own and years below 100 are rejected.

## Business Value

This page is the evidence for whether Surtr's REBL3 mirror can be trusted against Aerie's production real-estate data. Today it answers "everything is wrong" (298 of 298 mismatched), which makes it useless as evidence and hides any real disagreement inside representation noise. After this PR the headline separates genuine disagreement from documented formatting differences, and every formatting-only difference still shows its raw values and the rule that equated them, so a reviewer can accept or reject each rule instead of trusting a number. On the fixture shaped like the live payload, 298 mismatches become 19 real plus 279 formatting-only.

## Manual Effort Estimate (proposal, for Keval to confirm/adjust)

About 7 focused hours for this PR by hand with no AI: rule design and edge cases (timestamp parsing without engine dependence, blank-vs-zero coercion) about 2.5h, contract and view changes about 1.5h, realistic fixture and test suite about 3h. Whole three-PR stack: about 20 focused hours.

Linear: no ticket filed yet (no Linear tool in this session); to be linked.

## Test plan

- [x] pnpm --dir chat exec vitest run on the lib, route, view and page test files: 133 passed

- [x] pnpm --dir chat exec tsc --noEmit

- [x] pnpm lint (only 2 pre-existing warnings in an unrelated file)

- [ ] Not verified in a browser: the page is behind Clerk auth and the Next dev server is not run in this workflow. Built and tested against realistic fixtures only.

- [ ] Not known: production's actual values for cutBy, cutReason and updatedAt. The fixture encodes the leading hypothesis (production null and +00:00 timestamps vs Surtr [], '' and Redshift format). If production differs, the page will show those fields as real differences with their values, which is the point of showing them.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Follow-up to [PR 1406](https://github.com/AI-Builder-Team/Aerie/pull/1406) (merged), which fixed the Real Estate tab's shape error so it renders. Reviewing the rendered tab exposed two real problems, plus a family of siblings with the same cause.

- A stale OK read as healthy. Surtr's Observer stopped evaluating on 2026-09-18 while the pipeline kept running daily, yet the tab showed a green OK, "evaluated 2d ago" next to "Last Run 1h ago", and said nothing about the mismatch. That OK is a verdict about an earlier run, not current assurance.

- "Disabled" schedule wording was misleading for event-driven pipelines. mart-aerie-rebl3-sites-refresh has no schedule; it runs whenever aerie-rebl3-raw-sync succeeds. The tab said "Disabled / no upcoming run".

## Problem A: stale verdict

isRealEstateVerdictStale (pure, in real-estate-health.ts) decides whether the Observer's verdict is about an earlier run than the latest one. Nothing is claimed, and nothing is an error, when the run is still in progress (completedAt null), there is no last run, or lastEvaluatedAt is null (already the UNAVAILABLE path in the builder).

1. Which run, when both ids are known (added after Mercy's review): the same run id means current whatever the clocks say. Different ids and an evaluation stored at or after the latest run finished means stale; Surtr evaluates a run after it finishes, so that only happens when an operator re-evaluated an older run, which leaves the latest run unevaluated and looks current by timestamp alone.

2. Otherwise, and whenever an id is missing, the timestamps decide: stale when lastRun.completedAt is more than REAL_ESTATE_VERDICT_STALE_GRACE_MS (30 minutes) after observer.lastEvaluatedAt.

3. An unreadable timestamp is stale, never current (fail closed; see the class audit).

Why 30 minutes (read from Surtr, not modified): Surtr/src/derive/observer/sweep.ts has DEFAULT_LOOKBACK_MIN = 15 and a sweep only evaluates runs that finished inside it (findRecentTerminalRunsRedshift filters on ended_at >= since); infra/lib/surtr-app-stack.ts fires the sweep every 5 minutes. So the last sweep that can still see a run starts about 15 minutes after it finished. Twice that leaves room for evaluation latency, the concurrency cap and a 409 while an earlier sweep runs. A run not evaluated within about 30 minutes of completing never will be automatically.

Semantics: staleness never improves a verdict.

- OK becomes a non-green Stale badge and Observer card, with the note "Verdict is for an earlier run — last evaluated Xd ago; the latest run finished Yh ago and has not been evaluated by the Observer."

- WARN and CRITICAL keep their badge and tone exactly as before and gain the same note (bad news stays visible). UNAVAILABLE, whether a failed fetch or Surtr's own verdict, is unchanged and gets no second caveat anywhere on the tab.

- Surtr's verdict vocabulary and the fail-closed unavailable behaviour are untouched. STALE exists only as a display state (getRealEstateDisplayState), not as a verdict; normalizeRealEstateVerdict("STALE") is still UNAVAILABLE.

- The "Open findings" card no longer shows a green 0 when it is read off a stale evaluation; a non-zero count is always shown as before.

Client-side, not server-side. Everything the rule needs is already in Surtr's response, so it stays one pure helper with no clock, shared by the page and the tests. The payload gains five optional fields, all plain pass-throughs of what Surtr serializes: schedule.expression, lastRun.triggerType, lastRun.triggeredBy, lastRun.runId and observer.lastEvaluatedRunId. No verdict is computed server-side; a server-side flag would only be one more field for the guard to trust.

## Problem B: schedule wording

- Verified in Surtr: presentRun serializes trigger_type and triggered_by (?? null), the detail endpoint serializes schedule.expression, and the fetch schema here already had all three optional or nullable, so no schema change was needed.

- Wording (describeRealEstateSchedule): no expression and not enabled is Not scheduled, and only when the last run's trigger type is EVENT and triggeredBy is a non-empty string it adds "Runs when triggered by <triggered-by>" (never a hard-coded pipeline id). Expression present and not enabled is Schedule disabled (warn). Enabled keeps "Enabled" with the next run.

- Schedule existence is never inferred from the expression alone (Mercy, second round). pipeline-config.ts allows an empty expression and defaults enabled to true, and registry-sync stores the empty string as null, so no expression with enabled: true is a real shape: it reads Enabled with "no schedule expression is set" as a warning, not the neutral Not scheduled. And because the registry records only the primary schedule, not additional_schedules, the plain case says "no schedule reported by Surtr" rather than claiming nothing is configured. All seven combinations of expression (string, null, not reported) and enabled are pinned by a table test.

- The literal UNKNOWN is treated as missing: create-run-record stores it when an event carries no triggered_by.

## Deferred nit from PR 1406's Mercy review

A finding whose open state Surtr's run ids cannot settle now reads Status unknown instead of rendering no status. It fit naturally (three lines in the findings list).

## Class audit

Searched the tab, payload, guard and tests for every health signal shown without freshness or provenance, and every missing or unknown value shown as a definite one. Fixed siblings:

- Item 1: header said "Checked" for Surtr's as_of (the later of the last run and the last evaluation), which is not when the tab looked. It now reads "Surtr data as of X" with a tooltip; only a placeholder payload, which carries our own check time, still says "Checked".

- Item 2: an unavailable source rendered the builder's placeholders as facts: 0 open findings in green, "Disabled", "No run recorded / never run", "No Observer findings". Those cards now read Unknown and neutral, and the findings list is not rendered.

- Item 3: last-run tone was green for any completed status except lowercase failed, so partial, timeout, FAILED and unrecognised statuses were green. Now only a finished success is green; partial is warn, failed and timeout are bad, unknown is neutral.

- Item 4: formatRelativeTime returns "just now" for any future timestamp, so every scheduled pipeline showed "next just now". Added formatTimeUntil ("in 5h", "due now"). An enabled schedule whose next run Surtr could not compute (nextRunAt is null for an unparseable expression) now reads "next run unknown", not "no upcoming run".

- Item 5: a run with no timestamps read "never run"; it now reads "time not reported". A green tone also needs a finished run.

- Item 6: the findings empty state ("No Observer findings...") carries a caveat when the verdict is stale.

- Item 7 (Mercy): freshness must be tied to the evaluated run, not only to timestamps. Audited every consumer of last_evaluated_at (the builder's null check, the stale helper, the Observer card's "evaluated X ago", the fetch schema); only the stale helper made a freshness decision, and it now compares run ids first.

- Item 8 (Mercy): every Date.parse in the freshness and schedule code now fails closed: an unreadable evaluation or completion time is stale, the note says "at an unknown time" rather than printing a dash, and an unreadable next run reads "next run unknown". The guard and fetch schema already reject such values, so this only hardens direct callers.

- Item 9 (Mercy, second round): do not infer schedule existence from the expression alone. Audited every branch combining enabled, expression and nextRunAt, including the not-reported path: no expression with enabled: true is now a warning instead of Not scheduled, and the guard rejects an upcoming run with no expression (Surtr's nextRunAt returns null without one).

## Guard invariants (each traced to Surtr, with a "why" comment as in PR 1406)

- schedule.expression is a string, null or absent: registry-sync writes p.schedule?.expression || null.

- lastRun.triggerType / triggeredBy are strings, null or absent: presentRun serializes them with ?? null.

- lastRun.runId is a string or absent: presentRun serializes run_id: run.id.

- observer.lastEvaluatedRunId is a string, null or absent: observerDetail serializes last_evaluated_run_id: view.latest?.runId ?? null.

- nextRunAt non-null requires enabled: the API computes next_run_at as scheduleEnabled ? ... : null.

- nextRunAt non-null requires an expression: Surtr's nextRunAt(expression) returns null as its first step when there is none.

Deliberately not added: "expression null implies enabled false". pipeline-config.ts allows an empty expression and defaults enabled to true, and registry-sync stores the empty string as null, so no expression with enabled: true is a real shape, and an existing server test already accepts it. Rejecting it would recreate PR 1406's failure mode; the card shows it as a warning instead.

## Known limits

- In the seconds-to-minutes between a run finishing and its evaluation being stored, the previous verdict reads Stale. That is accurate and can only understate health. If it proves noisy for a pipeline that runs more often than the grace, gate on time since completion (needs the clock threaded in).

- Two runs evaluated out of order also read Stale, because Surtr calls the newest evaluation "latest". That only understates health and cannot happen for a daily pipeline.

## Testing

- Live 2026-09-20 shape is the primary fixture (OK, evaluated 2026-09-18T04:08:10Z, run completed 2026-09-20T04:08:09Z, expression null, enabled false, EVENT triggered by pipeline:aerie-rebl3-raw-sync): run through the fetch schema, builder and guard end to end, through the route, and through SyncPage (badge Stale, no OK anywhere, exact note text, "Not scheduled" + "Runs when triggered by pipeline:aerie-rebl3-raw-sync", not green).

- Also covered: evaluation 2 minutes after the run (not stale), the exact 30:00.000 boundary and one millisecond past it, run in progress, no last run, CRITICAL plus stale (stays Critical, gains the note), same run id (current), older run re-evaluated after the latest (stale, also through SyncPage), missing ids (timestamp fallback), unreadable timestamps, Surtr's own UNAVAILABLE verdict over a retained old evaluation (no caveat anywhere), expression present and disabled, enabled schedule (in 5h, in 12m, under a minute, due now, unknown), missing or blank or UNKNOWN trigger fields (no invented text), and the placeholder-as-unknown state.

- Mutation check: I broke each new behaviour in turn (38 mutations across the boundary, grace, run-id identity, out-of-order re-evaluation, fail-closed parsing, display state, in-progress handling, unavailable suppression, schedule and trigger wording including the enabled-with-no-expression branch, every guard invariant, builder pass-through, status classification, and the page tones, banner, header and Status unknown label). Every one made a dedicated test fail; none survived.

- Passing locally: the five affected test files (207 tests), tsc for app and convex, and pnpm lint (boundaries, convex-paths, read-bounds, test-architecture, knowledge, biome). Biome reports two pre-existing warnings in chat/skill/forge-api/scripts/sindri.mjs, outside this diff.

- Not verified in a browser: Clerk auth blocks it from this session, so UI behaviour is covered by the component tests only. Keval will check it visually in a local preview.

Diff is about 1,830 changed lines, roughly two thirds tests.

## Business Value

The Real Estate Data Health tab is how operators decide whether the REBL3 sites mart can be trusted. Since 2026-09-18 the Observer has been silent while the tab showed a green OK, which is worse than no signal because it reassures. This makes that failure visible the moment the Observer falls behind, without ever softening a bad verdict, and it stops a healthy event-driven pipeline from reading as "Disabled". The class fixes remove the other places the tab could look healthy or definite without evidence (green zeros on an unreachable source, green for partial/timeout runs, "next just now", a re-evaluated old run passing as current), so the next silent failure shows up as what it is.

## Manual Effort Estimate

About 10 hours of focused work by hand, no AI: roughly 1.5h tracing Surtr (sweep cadence, presentRun, registry-sync, status and trigger vocabularies, run ids), 1.5h for the payload, guard, builder and schema check, 2h for the stale helper, display state, banner, wording and the class-audit UI fixes, 4h for the lib, guard, builder, end-to-end, route and page tests with a pinned clock, and 1h for the mutation check, lint, typecheck, review round and this write-up. For Keval to confirm/adjust.

Linear: no ticket linked; this session has no Linear access, so Keval to attach one.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

The hidden experimental Surtr comparison page (/dashboards/real-estate/experimental) was unusable in a real browser for two reasons that no test could catch, found by driving the page in Chrome:

1. It could not be scrolled. The (main) shell's <main> is overflow-hidden, and the page rendered a plain block with no scroller of its own. Everything below the first screen (the comparison list, its pagination, the per-field panel) was unreachable by wheel or touch.

2. Blank 260px column on the left. The shell reserves the context panel's width for the whole dashboards section (sectionHasPanel), but this page registered no panel content, so the reserved space rendered empty.

Both are the same miss: every dashboards subpage supplies its own scroller and registers the shared DashboardsContextPanel (see real-estate-site-detail-page.tsx). This one did neither.

## What changed

- page.tsx: the page wrapper gets min-h-0 flex-1 overflow-y-auto (same idiom as the Sync page), and the page registers DashboardsContextPanel via useContextPanelSlot with cleanup on unmount, exactly like the sibling site-detail pages.

- New page.scroll.test.tsx pins both contracts (scroll wrapper classes, panel registered and cleared). jsdom cannot lay out or scroll, so this pins the wrapper contract rather than the pixels.

- page.test.tsx: added the two mocks the hook needs (it throws without a provider).

## Verification

- Driven in a real browser against a local dev server: before, the wheel does nothing and a 260px blank strip sits on the left; after, wheel scrolling reaches the end of the list and the left column shows the Dashboards navigation. The DOM tweak (overflow-y: auto on the wrapper) was tried live first to confirm the root cause.

- vitest for the folder (14 passing), biome check, lint:test-architecture and tsc (chat + convex) all pass locally; the pre-commit hooks ran clean.

- Not verified: production behaviour of the panel contents (this was checked against a local dev deployment).

Independent of the comparison-UX stack: it touches only page.tsx and its tests. If the stack merges first, the only expected conflict is the mocks block at the top of page.test.tsx (keep both sides).

## Business Value

The internal REBL3-vs-Surtr comparison is the tool the team uses to gain confidence before switching production reads to Surtr. Without scrolling it was effectively unusable regardless of the data behind it; this makes the whole page reachable and removes the dead layout space, so the migration-validation work can actually proceed.

## Manual Effort Estimate

About 1.5 hours of focused time by hand (reproduce in a browser, find the shell's overflow and panel-slot contracts, fix, write and run tests). Proposed for Keval to confirm or adjust.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- gpt-6-astra has no row in core_finance.ai_spend_token_pricing. Since 2026-09-04 its 262 usage rows (311.6B input tokens, 1.78B output, $292,658 billed) load with $0 calculated cost, and openai-usage-pipeline reports PARTIAL (observer CRITICAL) every run.

- Adds spec 9 following specs 7 and 8: an idempotent pricing INSERT at the official standard rates ($10 input / $1 cached / $50 output per 1M tokens, from OpenAI's model page, verified 2026-09-20), a reprice script covering 09-04 through 09-19 in weekly windows (dry-run by default), and verification queries.

- Docs and SQL only. Nothing has been applied to prod. The INSERT was validated with EXPLAIN against the real table (parses, wrote nothing), and the prod table still has 0 astra rows.

## Notes for review

- The calculated cost is list price and billed cost stays the source of truth. Rows have batch=false and a NULL service_tier, so Batch/Flex (50%), fast mode (2x) and the over-272K long-context surcharge cannot be applied per row. Billed/list is 0.49 over 09-04 to 09-18 (about $292.7K billed vs about $596K list).

- Rates cannot be inferred from billed cost (regression was unstable and billed/calc ratios vary 0.25x to 8.8x across models), so the rate card is the source.

- Applying it is a manual prod step (governed core_finance table): run 01, then 02 --execute, then 03.

## Business Value

Restores calculated cost on the fastest-growing OpenAI model line (about $292K billed in 15 days that currently shows $0 in calculated-cost views), clears the daily PARTIAL/CRITICAL alert on openai-usage-pipeline, and gives spend reporting a documented basis for list vs billed on this model.

## Manual Effort Estimate

About 1.5 hours of focused work by hand (locate the official rate, reconcile against billed data, write the SQL, reprice script, verification queries and spec). Proposed by Claude, Keval to confirm or adjust.

Linear: ticket pending (belongs in Surtr Pipeline Reliability & Observability).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Part 2 of 2 · stacked on #1803 — review and merge that one first.

Pure dead-code removal. Everything here became unreachable when #1803 removed

the page and its tRPC procedures. Nothing in this PR is user-visible.

Split out of #1802 at Mercy's request — that PR was 651 KB, over the 600 KB

review cap. This half is 516 KB; #1803 is 120 KB. The two together are

byte-identical to the original.

> Base note: this targets claude/remove-heimdall-dashboard-ui, so the diff

> shown here is only part 2's own changes.

## What comes out

- src/heimdall/board.ts (3,534 lines) and its 6,099-line test

- The read/aggregate halves of src/heimdall/store.ts (529 → 127) and

src/heimdall/types.ts (368 → 133)

- scanTriageRows and its identityUnreadable helper — the factory board was

their only caller. getTriageIssues, which the pipelines page's Triage tile

uses, is untouched.

## The one helper that had to survive

monthBucket() stays. It derives gsi_bucket, the partition key of the

all-completed_at-index GSI, and it sits directly beside bucketsInRange(),

which *was* dashboard-only and is deleted here.

Sweeping both out as "aggregation helpers" would have left ingest returning 200

while writing rows that never appear in that GSI — the control tower queries it

by exactly that key, so its telemetry view would have gone quietly empty for new

runs while older rows kept rendering. Precisely the silent-data-failure shape

this repo exists to avoid. Three assertions in

test/api/heimdall-telemetry.test.ts pin that gsi_bucket is written.

## IAM: code removed now, grants held one cycle

Only the env vars change in this PR. The two IAM statements are restored

verbatim after @mercy's finding, so the policy here is byte-identical to main:

- dynamodb:Query on surtr_heimdall_telemetry and its two GSIs — retained

- dynamodb:Scan alongside Query on the triage table — retained

- Board-only env vars HEIMDALL_TRIAGE_REPO and TRIAGE_PENDING_TTL_MINUTES — removed

The task role is shared across task-definition revisions, and CloudFormation

applies a policy change the instant it updates while ECS keeps pre-change tasks

serving until the new ones pass health checks and the old ones drain. Removing

the permissions in the same change as the code would leave a multi-minute window

where an old task still serving /heimdall calls a GSI the role can no longer

read — AccessDenied on a page we are deleting, rather than the page simply going

away. Both statements carry a comment saying so, so they are not tidied away

later without the sequencing.

Env vars have no such hazard: they live on the task *definition*, so a change

mints a new revision and pre-change tasks keep their own values. That is why

that half stays.

Follow-up needed: a third PR drops both statements once this revision is

fully rolled out and no running task can issue the call.

The live table and its GSIs are not touched — fromTableAttributes is

synthesis-only, and the control tower reads with local credentials, a different

principal from the ECS task role.

## Verification

| Check | Result |

| --- | --- |

| pnpm lint (biome) | pass |

| pnpm build (tsc) | pass |

| pnpm test:unit | 715 passed, 49 files |

| Retained ingest tests | 33 passed |

| npm run build (infra CDK) | pass |

| @mercy high finding | addressed in 644bb856 |

## Business Value

Deletes ~11,600 lines of unreachable code, most of it board.ts's

provenance-backfill, live-window and partial-state reasoning — every branch of

which was a thing Mercy re-reviewed on every touching PR and a future reader had

to understand before changing anything nearby. Also removes two standing IAM

grants and two env-var couplings to the dispatcher that had to be kept in step by

hand, one of the quiet drift risks the code comments themselves called out.

## Manual Effort Estimate

Covered by the 1-hour estimate on #1803 — the two PRs are one change.

---

⚠️ No Linear ticket yet — see #1803.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Phase 5 — the final phase — of the no-Braintrust mercy telemetry/evals plan. Stacked on #1907 (Phase 2: the disputed/override_merge/human_reaction schema fields and the /internal/mercy/feedback ingest route this reads). Extends the existing /mercy dashboard rather than building a new surface, per the steer to wire this into Surtr's own page.

- store.ts / trpc.ts: listMercyReviewsPage gains a hasFeedback filter — reviews carrying override_merge, disputed, or human_reaction — via the same buildReviewFilter/FilterExpression mechanism the existing event/status/search predicates already use. A plain attribute_exists check works here (unlike, say, "does any finding have deferred: true") since all three feedback fields are top-level scalars/objects on the review record, not nested inside the findings list.

- types.ts: computeStats gains disputedCount / overrideMergeCount / humanReactionCount — review-level presence counts (not raw reaction totals) — feeding a new "Feedback" stat card alongside the existing ones.

- app/(app)/mercy/page.tsx: new FeedbackSection — a lightweight, unpaginated "recent 10" list (deliberately not another full paged table like "Recent reviews"), server-filtered via hasFeedback, showing a badge per applicable signal (⚠️ overridden merge, 🔴 false positive / 🟡 other dispute label, 👍/👎 reaction counts — a review can carry more than one, all render) with a link back to the PR on GitHub.

Same data source, same page, no new route — matches the steer to extend the existing dashboard rather than build something new.

## Business Value

Closes the loop the whole plan exists for: mercy's ground-truth signal (human reactions, override-merges, confirmed false positives/negatives) is now visible on the same dashboard people already check for cost/latency, not buried in a script's stdout or a separate tool. This is also the piece that makes the "mercy is too strict/stupid" complaints tractable — anyone can now see, at a glance, how often that's actually happening and on which repos.

## Manual Effort Estimate

~2 hours by hand (a new server-side filter reusing the existing FilterExpression builder, three new aggregate counters, a new dashboard section with badge logic for three independent signal types, plus tests) — flagging for Keval to confirm/adjust.

## Test plan

- [x] npx tsc --noEmit — clean

- [x] npx biome check on all changed files — clean

- [x] New/updated tests: buildReviewFilter (hasFeedback alone + combined with another predicate + explicit false), computeStats (4 new cases for the three counters), plus existing listMercyReviewsPage/dashboard-adjacent coverage untouched

- [x] Full unit suite (npm run test:unit, excluding DB/integration suites needing live infra): 1174 passed, up from 1167 on #1907, 0 regressions

Not done: this was verified via typecheck + unit tests, not a live browser render — the dashboard needs a live DynamoDB table + Clerk-authenticated session to actually load, which this scratch environment doesn't have wired up. Worth a quick look in a real deploy before/after merge.

## Linear

[SURTR-1352](https://linear.app/builder-team/issue/SURTR-1352/mercy-dashboard-feedback-section-phase-5-no-braintrust-telemetry-final)

## Summary

The Real Estate tab on Data Health (/sync) showed "Unable to load real estate health — Real estate health response did not match the expected shape." whenever the Observer had raised a finding earlier in the trust window, even though the latest evaluation was clean. This PR makes the payload and its client guard model Surtr's actual contract instead of rejecting a valid response.

## Root cause

Surtr's detail endpoint deliberately returns two scopes (pipeline-api/routes.ts: latestFindings, observerDetail, collapseFindings):

- open_finding_count and worst_severity cover the latest evaluation only.

- findings is every distinct finding across the whole trust window, with window_finding_count / window_days carrying the window totals ("Broader than open_finding_count on purpose").

isRealEstateObserverSummary required openFindingCount === findings.length and rejected any non-empty list with an OK verdict. The Observer's 2026-09-17 evaluation of mart-aerie-rebl3-sites-refresh recorded one L finding and the 2026-09-18 evaluation was clean, so Surtr returned OK / 0 open / one window finding and the guard rejected it. Both shapes (09-17: OK with one open L; 09-18: OK, 0 open, that L now only in the window) are valid Surtr output, and the old guard rejected both.

## What changed

- Payload: openFindingCount / worstSeverity stay latest-scoped, findings is the window list, new optional windowFindingCount and windowDays, and a per-finding optional open flag.

- open flag: last_fired_run_id === last_evaluated_run_id. Provable from Surtr: collapseFindings reads evaluations newest-first (GSI ScanIndexForward: false) and stamps each finding with the newest evaluation it appeared on; run_id is the observation table's hash key, so unique. Left absent when either id is missing, never guessed.

- Guard: the two false invariants are replaced by ones Surtr's code guarantees, each with a one-line "why" comment (see below). The existing error implies sourceUnavailable invariant is unchanged.

- UI: the count is labelled "Open findings (latest evaluation)"; the list is "Findings in the last N days" with first/last fired; each finding is tagged Open or "Not in latest evaluation" when provable.

## Invariants (audited against Surtr)

Kept, each traced to Surtr:

- open findings imply a non-empty window list (latest evaluation is part of the window; both drop the same muted findings)

- open count is zero if and only if worst severity is null (both derived from one array)

- windowFindingCount equals findings.length when present (same array in observerDetail)

- OK verdict never has a Critical worst severity (computeScoreAndVerdict: any C forces CRITICAL)

- findings flagged open never outnumber the open count

Two suggested invariants were deliberately not used, because they are false against Surtr and would recreate this bug:

- "verdict OK implies zero open findings": computeScoreAndVerdict deducts C=25, H=10, M=4, L=1 and returns OK at a score of 90 or more, so a lone L, M or H on the latest evaluation is still OK. The 09-17 evaluation itself is an example (OK with one open L). Surtr's own comment that counts "always agree with verdict" overstates this; worth a follow-up comment fix in Surtr, not blocking here.

- "open count <= window list length": the window list is de-duplicated by category+title while open_finding_count is a raw per-evaluation count, and the model can repeat a category+title within one evaluation.

I also checked that the store's ignore/unignore flows only touch the separate ignored-findings record and never rewrite a stored observation's verdict or findings, and that a verdict can be CRITICAL with 0 open findings (muted findings still count toward the verdict), so verdict-to-count implications are not asserted in that direction either.

## Class audit

Producers and consumers of this payload: the route, rebl3-pipeline-health-server.ts, real-estate-health.ts, the /sync page, and all four test files (fixtures included). Fixed siblings:

- the guard's two false invariants

- the page's "Open Observer Findings" heading and "No open Observer findings" empty state, which treated list contents as current

- three test fixtures encoding the same false assumption (the OK-with-open-finding "contradiction" tests in the lib and page suites, and the server-lib fixture with window_days: 30 and an "open" count on a finding that last fired on an older run)

No other Aerie code reads Surtr observer counts. platform-error-coverage-inventory.ts (route entry) and docs/product/journey-suites/data-health-and-monitoring.md were checked and need no change. rebl3-surtr-gateway-server.ts uses the same host but not the observer.

## Testing

- New end-to-end regression tests run the exact 09-17 and 09-18 Surtr JSON through the fetch schema, the builder and the browser guard.

- Negative tests prove true contradictions still fail closed: open with an empty list, worst severity with nothing open, open with null worst severity, OK with a Critical worst severity, window count not equal to list length, malformed window fields, more flagged-open than open.

- Mutation check: I disabled each new invariant in turn and confirmed a dedicated test fails (one redundant type check survived, so I removed it).

- Passing locally: the four affected test files (103 tests), tsc for app and convex, and pnpm lint (boundaries, convex-paths, read-bounds, test-architecture, knowledge, biome).

- Not verified in a browser: Clerk auth blocks it from this session. UI behavior is covered by the SyncPage component tests only.

Diff is about 910 changed lines, roughly three quarters tests.

## Business Value

The Real Estate Data Health tab is how operators tell whether the REBL3 sites mart is healthy. It hard-failed to "Unable to load" for any pipeline with a finding anywhere in the last 7 days, including on a clean latest run, and would have recurred after every L, M or H finding, hiding the very signal the tab exists to show. This restores that signal, stops historical findings from reading as current problems, and aligns the client guard with Surtr's real contract so the next Observer finding does not break the tab. The end-to-end tests make a producer/consumer disagreement on this payload fail in CI instead of in front of a user.

## Manual Effort Estimate

About 6.5 hours of focused work by hand, no AI: roughly 1.5h tracing Surtr's routes and Observer scoring to verify each invariant, 1h for the payload, guard and builder, 1h for the UI, 2.5h for the guard, builder, end-to-end, page and route tests, and 0.5h for lint, typecheck and the PR. For Keval to confirm/adjust.

Linear: no ticket linked; this session has no Linear access, so Keval to attach one.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Phase 2 of the no-Braintrust mercy telemetry/evals plan (see [mercy#133](https://github.com/AI-Builder-Team/mercy/pull/133), which reverted the Braintrust integration per Benji's call). Extends the mercy telemetry substrate Surtr already owns — rather than a new system — so mercy's ground-truth labels (human reactions, override-merges, confirmed false positives/negatives) land in the same surtr_mercy_telemetry table as the review they're about.

- src/mercy/types.ts: additive-only schema changes (no MERCY_TELEMETRY_VERSION bump, per the file's own forward-compat rule):

- MercyFindingSchema gains deferred / deferred_reason — release_gate.py's second-opinion outcome, not previously carried.

- MercyReviewRecordSchema gains lens_pass_summaries (per-lens/arbiter pass breakdown — the same shape the now-reverted emit_braintrust.py computed, moving to emit_telemetry.py in Phase 3), and a feedback block: human_reaction, override_merge, disputed.

- src/mercy/store.ts: new mergeFeedback(reviewId, patch) — an UpdateCommand that SETs only the provided feedback fields, gated on attribute_exists(review_id) so a feedback POST for an unknown review_id 404s instead of silently creating a garbage row with no review data. Throws MercyReviewNotFoundError on that case.

- src/api/mercy-feedback-route.ts (new): POST /internal/mercy/feedback, symmetric with the existing POST /internal/mercy/telemetry route — same shared-bearer-token pattern (MERCY_FEEDBACK_TOKEN, deliberately separate from MERCY_TELEMETRY_TOKEN so either can be rotated independently), same body-size/JSON validation. Accepts either review_id directly or (repo, pr_number, head_sha), hashed with the identical sha256(repo|pr_number|head_sha) emit_telemetry.py uses to compute review_id — so callers that never saw mercy's own telemetry payload (backfill_feedback.py, which scans GitHub PR history directly) can still resolve the right row.

- Registered in src/api/server.ts alongside the telemetry route.

Not in this PR (Phase 3, mercy-central): repointing backfill_feedback.py / collect_feedback.py / apply_feedback.py to POST here instead of Braintrust, and moving the lens_pass_summaries computation into emit_telemetry.py.

## Business Value

Gives mercy's PR-review quality signal (the "mercy is too strict/stupid" complaints) a real, low-cost feedback loop: human reactions, override-merges, and confirmed false positives/negatives become queryable alongside the cost/latency data already on the /mercy dashboard, in infrastructure Surtr already runs — no new vendor, no quota ceiling (Braintrust's score quota was hit twice this month), and it's the concrete substrate Phases 4-5 (regression tests, judge-agreement scoring, a dashboard section) build on next.

## Manual Effort Estimate

~2-3 hours by hand (new Zod schema fields against an existing .loose() convention, a new UpdateCommand-based store function with a not-found guard, a new Hono route mirroring an existing one, plus route/store unit tests) — flagging for Keval to confirm/adjust.

## Test plan

- [x] npx tsc --noEmit — clean

- [x] npx biome check on all changed/new files — clean

- [x] New tests: test/mercy/store-feedback.test.ts (5 cases — SET-only-provided-fields, multi-field SET, no-op on empty patch, MercyReviewNotFoundError on ConditionalCheckFailedException, other errors re-thrown) and test/api/mercy-feedback.test.ts (8 cases — auth gate, JSON/schema validation, review_id vs (repo, pr_number, head_sha) hash resolution matching emit_telemetry.py, 404/503/500 paths)

- [x] Full existing unit suite (npm run test:unit, excluding DB/integration suites that need live infra): 1167 passed, 0 regressions

## Linear

[SURTR-1348](https://linear.app/builder-team/issue/SURTR-1348/mercy-feedback-surtr-schema-ingest-route-phase-2-no-braintrust)

## Summary

core_education.vw_site_capacity_utilization (CFO-50 Q3, SURTR-408) has been silently returning zero rows in production. Fixes that plus two more bugs found while validating it, and adds the Finalsite enrollment leg Marcin Pindral asked for in his 2026-09-04 audit finding.

1. Critical: view was dead. Rhodes' status taxonomy dropped 'open' entirely (only active/paused/cancelled remain now) — WHERE s.status = 'open' matched nothing. Fixed to status = 'active' AND stage = 'operating' (34 sites qualify today, verified live).

2. Found while validating #1: ambiguity check over-scoped. ambiguous_hubspot_codes was scored against the *entire* raw_sites table, so an operating campus got wrongly blocked the moment its brand had *any* other row (a future buildout site, a paused diligence attempt) sharing its hubspot_program_code. Unscoped: 29 of today's codes flag ambiguous. Scoped to the same open population the view reports on: 1 genuinely is (Texas Sports Academy's two real concurrent locations).

3. Marcin's original ask: enrollment doesn't tie to Finalsite. Added a second, independently-sourced enrollment leg (enrolled_count_finalsite / finalsite_data_quality_flag) from core_education.finalsite_student_school_year_current, via a hand-verified crosswalk (no governed Finalsite↔Rhodes identity mapping exists yet). utilization_pct is unchanged — still driven by the original enrolled_count — so nothing already consuming this view's accepted contract breaks.

Known gap surfaced, not fixed here: current_capacity/initial_capacity are NULL on every one of today's 34 open sites — verified live, not a query bug. Even with #1 and #2 fixed, utilization_pct is currently uncomputable network-wide. Suspected cause (unconfirmed): Marcin's 2026-09-11 message describes capacity moving to a new "Alpha School Platform API" that doesn't appear to be ingested into this warehouse under any name. That's a new ingestion pipeline, not a view fix — documented in the file header, raising it back rather than guessing at a source.

## Business Value

Restores CFO-50 Q3 (capacity utilization by campus) from silently answering nothing to actually answering it, and gives the audit a second, independently-sourced enrollment number to check the accepted metric against — directly closing the two-part finding Marcin Pindral raised against this exact view on 2026-09-04. Also surfaces a previously-unknown, much bigger gap (capacity data itself missing network-wide) before it was assumed fixed.

## Manual Effort Estimate

Proposed: 1.5–2 days for an engineer unfamiliar with this view — diagnosing why a "working" view returns nothing, tracing the Rhodes status-taxonomy change, discovering and re-scoping the ambiguity bug (easy to miss since it only shows up once the first bug is fixed), building the Finalsite crosswalk by hand from two mismatched naming schemes, and validating each change live. Keval: please confirm/adjust.

## Test plan

- [x] All 3 new/updated view-contract tests pass (test_scoped_to_open_sites_only, test_ambiguous_hubspot_codes_scoped_to_open_sites_not_whole_table, test_duplicated_site_ids_deliberately_not_scoped_to_open_sites)

- [x] New Finalsite-leg tests pass (5 tests)

- [x] Full pipeline suite: uv run pytest tests/ — 77/77 pass

- [x] View body validated live against Redshift (Klair Data API) before and after every change, including the CTE reorder

- [ ] Needs a Linear ticket (SURTR-) filed — no Linear tool access in this session to create one

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- sf_auth called raise_for_status(), which discards the response body. The fionn org has failed token requests since 09-18 and the run summary only says 400 Client Error: Bad Request for url ..., with no reason.

- On a non-2xx token response, raise with Salesforce's error / error_description (each truncated to 120 chars), the HTTP status, and the token URL. Nothing else from the body is included, and the client id and secret are never echoed.

- Behavior is otherwise unchanged: the caller still catches the exception, records auth failed: ... for that org, and continues with the other org.

This does not fix fionn's credentials. It makes the cause (for example invalid_client, inactive_user, or a changed connected app) visible in the next run so it can be fixed on the Salesforce or Secrets Manager side.

## Business Value

sf-raw-sync has synced only the trilogy org for two days while all 23 fionn tables fail, and the run summary cannot say why. Surfacing the Salesforce error shortens diagnosis of the fionn outage from a credential probe to reading one log line. It also applies to any future auth failure for either org.

## Manual Effort Estimate

About 45 minutes of focused work by hand (read the auth path, write the helper, add five tests). Proposed by Claude, Keval to confirm or adjust.

## Test plan

- [x] uv run pytest tests in pipelines/runners/sf-raw-sync: 44 passed

- [x] ruff check and ruff format --check clean

- [ ] After merge and deploy, confirm the next run's errors.fionn shows the Salesforce error and reason

Linear: ticket pending (belongs in Surtr Pipeline Reliability & Observability).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- require workflowInstanceId and runAccess on every workflow run

- make agent definitions and versions canonical-only and remove apiKeyHash

- remove completed one-off migration functions, compatibility readers, migration tests, and cutover runbooks

- regenerate Convex API bindings and update the workflow-instance feature contract

## Deployment prerequisite verified

The transitional checkpoint and backfills have completed in both persistent Convex environments. This repository has no other database environment that requires migration.

- Production audit: ready: true; 75 runs with 0 legacy rows, 22 agents with 0 apiKeyHash rows, 22 definitions with 0 legacy rows, and 130 versions with 0 legacy rows.

- Development inspection: 3 runs with all required instance/access fields, 2 agents with 0 apiKeyHash rows, 2 canonical definitions, and 7 canonical versions.

This is a greenfield project. The migration functions were one-off rollout machinery, not product behavior. Keeping them after both environments are clean would preserve obsolete write paths and legacy-shape handling indefinitely. The strict schema is now the deployment guard: Convex rejects the contraction before applying it if incompatible documents exist.

## Summary

- Exercise the /skill/forge-api/guide delivery route from the Forge skill delivery test.

- Verify the Markdown response headers and packaged authoring-guide content.

- Verify a missing packaged guide returns the clean 404 response.

## Validation

- vitest run app/skill/forge-api/forge-api-delivery.node.test.ts --maxWorkers=1 — 5 tests passed

- Chat TypeScript check passed

- pnpm lint passed with the repository's existing two template-string warnings

Adds Forecast V2 right-card drilldowns over the active Admissions Pipeline publication. The 19 source/filter counts open a shared list/detail panel with safe source links, sorting, CSV export, keyboard navigation, and distinct mismatch/truncation states.

- Propagates HubSpot IDs, deposit/enrollment dates and DBT eligibility flags through Pipeline sync, storage and DTOs; carries the January count operands through Forecast sync.

- Adds a Forecast-authorized, year-scoped query with indexed predicates and a shared 2,000-record budget for Guide/Offer. Eligibility-dependent metrics return unavailable for incompatible Pipeline publications; raw Total/Deposit/Without Deposits remain usable.

- Keeps open-panel counts and school names current across Forecast refreshes, clears disappeared/unavailable selections, and distinguishes Start Year from January selections.

- Uses a focused program/year visibility lookup after atomic publication validation; older publications retain full validation until refreshed. The publisher rejects ambiguous program codes.

- Keeps raw counts separate from January-eligible operands and derived forecasts. Reuses Pipeline presentation infrastructure and shared SIS navigation controls.

Validation: focused Convex, sync, contracts, and React tests, including all metric populations, authorization, publication isolation, cap handling, malformed dates, keyboard navigation, and source links. Three isolated review/fix iterations completed. Client, Convex, and sync typechecks and repository lint pass. Full CI passes: lint/boundaries, typecheck, tests, app/Cloudflare builds, Docker builds, and secret scanning.

Rollout: verify the prerequisite #1386/#1387 DBT models are deployed in the warehouse, then deploy the optional Convex fields/indexes before the sync worker; new January drilldowns remain unavailable until Pipeline refreshes with eligibility fields. The focused visibility path activates after the next Forecast refresh writes validation metadata. No new detail table or upstream writeback.

Closes #1389

## Change

- Add one source-routing breadcrumb to /meta: student-level balances, deposits, payment plans, and aid → staging_education_finalsite.contacts.

- No warehouse, schema, authentication, or dependency changes.

KLAIR-3546

## Summary

- Add default-off TypeSafe Jev strategy and finding-verification shadows around Mercy's existing review pipeline.

- Persist full bounded artifacts and emit only prose-free calibration signals.

- Add the Surtr canary caller reference without changing any review verdict or routing threshold.

## Why It's Needed

Mercy's measured failure mode is recall: 63 of 65 confirmed major or critical misses were never surfaced. This pilot measures whether a fast typed pre-review judgment can identify relevant risk lenses, while independently measuring finding support and categorization after Mercy has already finalized its deterministic decision.

## Changes

- Add a stdlib HTTPS client for jev-latest with strict response validation, short timeouts, redaction, cross-file sampling, bounded concurrency, and fail-open envelopes.

- Run strategy after the accepted size gate and verification only after decision.json exists.

- Upload shadow artifacts and add reduced strategy/verifier fields to telemetry.

- Keep the Jev key isolated to the two shadow steps and pin those invariants with workflow-contract tests.

## Breaking Changes

None. MERCY_TYPESAFE_MODE defaults to off, the secret is optional, and no Jev output reaches run_review.sh, decide_review.py, or submission.

## Test Plan

- pytest harness/tests/test_typesafe_shadow.py harness/tests/test_emit_telemetry.py harness/tests/test_workflow_contract.py -q — 90 passed.

- ruff check harness heimdall and ruff format --check harness with CI-pinned Ruff 0.15.22 — passed.

- actionlint -shellcheck= — passed.

- Full Windows harness run reached 473 passed with 10 unrelated existing Windows path/newline failures; changed-area tests are green.

## Verification Artifact

A real synthetic-fixture request returned HTTP 200 from POST /v1/systemone, resolved through jev-latest, passed the complete typed-response validator, and completed in 346 ms. No production PR content was sent.

## Impact Estimate

Default-off outside Surtr. On the Surtr canary, one strategy request runs per accepted review and up to 12 finding checks run with four-worker bounded concurrency. The pilot records cost, latency, truncation, and calibration disagreement signals before any later routing decision.

## Summary

Add a GitHub section below the task workflow with per-PR review status, approval, readable review comments and a persisted refresh timestamp. Fetch all review information only after the user clicks Refresh.

## Business Value

Task owners can assess PR approval and read inline feedback, replies, and conversation comments in the task they are already working in. Saved snapshots make review context available after reopening the app while keeping GitHub requests under the user's control.

## Implementation Effort

Estimated 8–12 hours for an average engineer to implement, test, and document the SQLite persistence, authenticated GraphQL fetch and pagination, task detail UI, and error handling.

## Linear

[AI-846: Add manually refreshed GitHub reviews to task detail](https://linear.app/builder-team/issue/AI-846/add-manually-refreshed-github-reviews-to-task-detail)

## Test Plan

- Focused GitHub review UI tests and Rust tests with fixture data.

- Existing task workspace tests.

- TypeScript compilation, theme validation, and whitespace checks.

- No live GitHub API requests in tests.

## Summary

History reconstruction and live stream events could render two rows for one user send, stop an active reply from streaming, or leave a finished turn marked Working. This change reconciles sends by client command identity, preserves distinct repeated sends, safely merges active history, and applies transcript repair without replaying stale runtime state.

## Business Value

People see each message and reply once, in the right order, and can trust the conversation status after refreshes and reconnects. This prevents duplicate prompts and misleading long-running indicators in task conversations.

## Implementation Effort

An average engineer would likely spend 3–4 hours tracing the event and history paths, implementing the reconciliation changes, and adding focused reducer and rendered-chat regressions.

## Linear

[AI-844: Harden Codex conversation message reconciliation](https://linear.app/builder-team/issue/AI-844/harden-codex-conversation-message-reconciliation)

## Test plan

- [x] 115 focused Node tests for conversation storage, recovery, message parsing, rendered chat, and memory budgeting

- [x] TypeScript check and frontend production build (pnpm build)

- [x] git diff --check

- [x] GitHub reported a clean merge state; its only check, [code]smith, was skipped

- [x] Squash merged as e9bb9199942ad1fc8cbf13cea3289b670121d79b

## Summary

- Bump Shipyard to 0.5.1.

- Publish the reviewed release notes for the release workspace and conversation-startup reliability improvements.

## Business Value

- Gives users a guided, reviewable workflow for preparing Shipyard releases.

- Makes release conversations more reliable to start and resume.

## Implementation Effort

- Metadata-only release change: authoritative version and public release notes.

## Test Plan

- pnpm test:release

- git diff --check

## Business Value

Starting a Shipyard release now opens a usable Codex conversation with its selected model immediately, avoiding the transient empty-session error and persistent “Model pending” state.

## Implementation

- Persist the effective runtime settings returned by thread/start before the release workspace opens.

- Wait briefly for the new rollout to become readable before returning the workspace.

- Retry only the known session-initialization race and surface unrelated failures immediately.

## Validation

- The local development app recompiled and relaunched successfully through ./start.sh.

- git diff --check passed.

## Linear

https://linear.app/builder-team/issue/AI-841/add-shipyard-release-review-workspace

## Implementation Effort

Approximately 2–3 hours for an engineer to reproduce the timing failure, trace the missing runtime settings, implement the bounded readiness check, and validate the desktop startup flow.

## Summary

- Compare Forecast V2 milestones with planned Buildout capacity at each milestone date

- Centralize sequential dated-capacity projection in the shared contracts utility

- Expose target-date capacity, coverage, and totals through the Admissions public API and agent guidance

## Why

The forecast capacity outlook compared future Admissions milestones with capacity as of today. That could misclassify a January forecast when a planned Buildout phase is expected to add seats before the milestone. The resolver now uses the milestone date and the canonical Buildout phase plan, while preserving current capacity as context and failing closed when required dates or capacities are unresolved.

## Business Value

Admissions questions such as whether a School is forecast to be full by January now use the capacity expected at that same checkpoint. This produces a more accurate, coverage-safe answer from one bounded endpoint.

## Breaking changes

getAdmissionsForecastCapacityOutlook now requires both admissions.forecastAggregates.read and operations.portfolio.read because its response includes forward-looking Portfolio Buildout capacity. Callers with only the Admissions aggregate scope receive 403 api_key_scope_missing.

## Test plan

- [x] pnpm check

- [x] 46 shared Buildout, capacity, and agent-policy contract tests

- [x] 38 Admissions public API edge-runtime tests

- [x] 55 Admissions schema, OpenAPI, and agent-context node tests

- [x] Architecture boundary, Convex path, read-bound, and test-runtime checks

Implements #1387 (DBT-only follow-up to #1386). Adds Forecast V2 January eligibility to the Admissions Pipeline inputs and threads it into Forecast Session 3. No Convex/UI changes (separate later ticket).

## What changed

Pipeline mart (mart_admissions_pipeline_dtl)

- Carries enrollment_date on the EduCRM Community Commitment arm (from stg_educrm_pipeline.enrollment_date, straight through int_educrm_community_commitment at deal grain) — the same Pipeline field the Finalsite arm already carries (#1386).

- Adds two columns:

- is_january_forecast_eligible = enrollment_date IS NULL OR enrollment_date <= Jan 31 of school_year (Jan 31 included, Feb 1 excluded; cutoff derived per row; null → eligible). Non-null on the five in-scope stages (finalsite 030_app/040_shadowing/050_guide_approved/060_offer_sent, educrm 028_community_commitment), null elsewhere. It is not general Pipeline validity.

- is_community_age_eligible via the shared age-five-by-September-1 macro; non-null on Community rows, null elsewhere.

- New macro january_forecast_eligible centralizes the rule (fail-closed regex-gated cutoff).

Forecast (int_admissions_forecast / mart_admissions_forecast)

- Session 3 now publishes BOTH the raw Pipeline cross-check counts (unchanged) AND January-filtered operands:

session_3_<channel>_january_eligible_no_deposit_count / _deposit_count (application/shadow/offer) and session_3_community_january_eligible_count / _january_age_eligible_count / _january_age_not_eligible_count.

- Session 3 applies each conversion rate to only the January-eligible No-Deposit count, sums only January-eligible deposits in its 100% subtotal, and splits the Community contribution on the January age buckets.

- Session isolation: every session_1_* operand and the Admissions Pipeline report counts are byte-for-byte unchanged.

## Fail-closed / tests

- New severity='error' guard assert_admissions_pipeline_january_enrollment_date_parseable: an in-scope Finalsite row whose source date is populated but unparseable FAILS the build (never silently null-and-eligible). Community is fail-closed at staging's ::timestamp cast.

- New guards: assert_admissions_pipeline_january_flag_scope (non-null in scope / null outside), assert_admissions_pipeline_community_enrollment_date_grain (deal grain preserved), assert_forecast_january_pipeline_reconciles (Session 3 January operands reconcile to date-eligible Pipeline rows; buckets partition; each January bucket ⊆ raw), assert_january_forecast_eligible_macro (null/Jan31/Feb1/rollover/malformed-cutoff), and a mart_admissions_pipeline_dtl_january_eligibility unit test.

- Updated existing tests for the Session 3 January semantics and the Community enrollment_date (deposit-split, deposit-overlay, community-buckets, nonneg, enrollment-date-source, lead-columns-null).

## Verification (full dbt build + tests against Redshift)

- Full prefixed build green (only a stale in-flight edit to one test errored on the first pass; re-run PASS). Forecast rebuild int_admissions_forecast+: PASS=45, ERROR=0.

- psql reconciliation (pr build vs live): Admissions Pipeline report row counts identical (0 diffs); Session 1 operands identical across all 106 program-years (0 diffs); Session 3 Offer no-deposit 61 → 60 (the single Alpha San Francisco 2027-02-01, deposit_paid=false record excluded — exactly the ticket's evidence); Community January buckets partition (161 = 89 + 72); session_3_pipeline_additions internal reconcile 0 bad rows.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

Add a Shipyard-only release workspace with a Codex conversation and Markdown notes preview. Editable release instructions persist in SQLite, while each release keeps a snapshot of the instructions and initial prompt. The release agent drafts notes and waits for explicit in-chat approval before moving on to version changes, a PR, merge, or publication.

## Business Value

Shipyard maintainers can prepare public release notes and move into the existing CI-backed release workflow from the app, with review of the proposed notes before publication begins. Project-specific instructions and conversation history remain available for later releases.

## Implementation Effort

Approximately 4–6 hours for an engineer working without AI assistance, including the app view, SQLite persistence, Codex thread handling, tests, and integration with the Shipyard release process.

## Test plan

- pnpm test:release

- cargo test --locked --manifest-path src-tauri/Cargo.toml --lib

- pnpm theme:check

- pnpm build

## Linear

[AI-841: Add Shipyard release review workspace](https://linear.app/builder-team/issue/AI-841/add-shipyard-release-review-workspace)

## Summary

- Bump Shipyard to 0.5.0.

- Publish the reviewed public release notes for the latest user-facing capabilities and fixes.

## Business Value

- Delivers the next backward-compatible feature release with Memory diagnostics, managed workflow-template visibility, improved repository and workflow feedback, and conversation reliability fixes.

## Implementation Effort

- Metadata-only release change: one version bump and one public release-notes file.

- No application source, workflow, or credential changes.

## Validation

- pnpm test:release — 15 Node tests and 13 Python tests passed.

- git diff --check passed.

- Exact diff limited to package.json and releases/0.5.0.md.

## Summary

- route existing Codex threads through a read-only ownership lookup instead of an immediate SQLite write transaction

- retain atomic ownership claims and takeovers with a transactional recheck

- show a single actionable error when attachment and status checks fail together

- add native concurrency and chat UI regressions

## Business Value

Shipyard users can open and check conversations while production and development instances are running concurrently, without transient SQLite writer contention making the conversation appear unavailable.

## Implementation Effort

Estimated 4–6 hours for an average engineer to diagnose the cross-process contention, preserve ownership correctness, implement the UI cleanup, and add concurrency regression coverage without AI assistance.

## Linear

https://linear.app/builder-team/issue/AI-839/prevent-conversation-opens-from-contending-on-sqlite-writer-locks

## Test Plan

- [x] pnpm test:instances

- [x] pnpm test:recovery

- [x] pnpm build

- [x] cargo test --manifest-path src-tauri/Cargo.toml --lib

## Summary

- Normalize Forecast V2 warehouse timestamps at the public API boundary

- Cover program forecast detail and Session 1 capacity outlook with production-shaped fixtures

## Why

Forecast V2 rows can contain SQL-style timestamps. The v2 Admissions API forwarded those values unchanged into RFC 3339/date response fields, causing response-schema 500s for program forecast detail and Session 1 capacity outlook.

## Business Value

Restores reliable DSS Admissions forecast reads for API consumers without weakening the published contract.

## Test plan

- [x] pnpm --dir chat test convex/publicApi/v2/admissions.test.ts (38 tests)

- [x] Focused Biome check

- [x] Chat and Convex typecheck

- Fix production list failures by reading one Convex page per request instead of reusing a consumed query in a scan-ahead loop.

- Preserve visibility filtering and continuation cursors, including empty filtered pages; HTTP contracts, OpenAPI artifacts, and the Sindri skill remain unchanged. No Aerie companion change or data migration is required.

- Add a regression using the real Convex query lifecycle: the old code reproduces the exact production exception; the fix returns a resumable empty page followed by the visible row.

- Validation: 952 tests passed, including OpenAPI and driver tests; TypeScript, Biome, Convex reference checks, and commit hooks passed.

## Summary

- Return a structured 401 response when Forge session authentication cannot parse bearer credentials

- Cover both the Forge skillspec and resource proxy entry points

## Why

Malformed bearer values were routed through session authentication, where JWT parsing errors escaped as 500 responses. Invalid credentials are a client authentication failure and must not surface as an internal server error or reach Sindri.

## Business Value

Keeps the public Forge API predictable and prevents malformed client credentials from creating false platform incidents.

## Test plan

- [x] pnpm test convex/publicApi/http.test.ts (35 tests)

- [x] pnpm typecheck

- [x] Targeted Biome check

- [x] Live dev verification: malformed bearer returns 401 on /v1/forge/skillspec and /v1/forge/agents

## Summary

- Make Forecast V2 the canonical DSS forecast and expose Program-level forecast-versus-capacity outlooks.

- Add a Site-grain campus outlook for current/future Buildout capacity, SIS enrollment, Forecast V2 deposits, opening details, and tuition.

- Retire conflicting legacy capacity surfaces and document worked forecast-capacity question patterns for API and Agent consumers.

## Why

Forecast and capacity guidance exposed competing model names, stale capacity fields, and no safe bulk route for common planning questions. This aligns the DSS and Agent with the intended sources of truth: Forecast V2 for forecasts, SIS for enrollment, and Ops-managed Site Buildout for capacity, while preserving the distinction between Site capacity and Program enrollment.

## Business Value

Agents and API consumers can answer which Schools are forecast at or over capacity, assess published January milestones against dated Buildout plans, and produce a CSV-ready operating/planned campus outlook without combining conflicting data sources or double-counting Program values repeated across Sites.

## Breaking changes

- Retires legacy capacity compatibility fields and read/write surfaces, including permitted, academic-session, and finance-model capacity aliases. Consumers must use canonical Site Buildout capacity or returned Program capacity rollups.

- Forecast API and DSS guidance now treat Forecast V2 as the sole operational forecast source; retired model labels remain historical vocabulary only.

## Test plan

- [x] 1,216 changed Chat tests passing across 45 files

- [x] 280 changed Sync tests passing across 8 files

- [x] 93 changed contract tests passing across 6 files

- [x] Chat and Sync pre-commit typechecks passing

- [x] Live Fleet Goat Forecast V2 capacity resolver validated after canonical Program identity repair

Closes #1386.

## Summary

Make the Admissions Pipeline mart the source of truth for Forecast V2's right-card Pipeline Additions and Community Commitment inputs (school year 2026‑2027), and enhance the shared Pipeline detail mart with the identifiers and dates the right-card drilldown needs. No new detail mart is created; int_admissions_forecast_detail and mart_admissions_forecast_dtl are left intact and are not published to Convex for this feature.

## Part 1 — mart_admissions_pipeline_dtl enhancements

- Community HubSpot identifiers (nullable, populated only on the deal-grain Community Commitment arm; null elsewhere): hubspot_deal_id ← deal_id, hubspot_contact_id ← hubspot_child_contact_id, hubspot_primary_contact_id ← primary_contact_id. Existing primary_contact_id is unchanged.

- deposit_paid_date — Community-only, from the Community Commitment source (what the arm's deposit_paid boolean is derived from); null on Finalsite/lead rows.

- enrollment_date — Finalsite-only, from stg_finalsite_custom_attributes where field_name = 'hubspot_enrollment_date', normalized to a date and joined on the stable site/person identity. Pre-aggregated to one date per (site, person_id) so the join is grain-preserving (measured: no person carries two differing dates; finalsite arm 3,501 rows in and out), and normalized fail-closed (only a leading YYYY-MM-DD is parsed; a missing or malformed attribute yields NULL, never a fabricated date). Matches the legacy forecast pipeline surfaces' enrollment_date; distinct from SIS enrolled_date.

## Part 2 — Forecast aggregate (int_admissions_forecast)

- The right-card operands (Application 030_app, Shadow 040_shadowing, Guide/Offer 050_guide_approved+060_offer_sent, their Deposit/No-Deposit, and Community 028_community_commitment) are now grouped directly from mart_admissions_pipeline_dtl (new pipeline_scope / pipeline_agg CTEs), resolved to hubspot_program_id through int_school_identity exactly as the mart's own arms do.

- Removed the finalsite_sis_identity_class = 'unmatched' filter on the Finalsite stages and the paid-only / SIS-email-overlap filters on Community — Pipeline is taken as-is.

- Deposit membership uses the deposit_paid boolean on the normal stage row; the stage_id = 'deposit' overlay is outside the grouped stage set, so it never enters a channel count.

- SIS cohorts (On Campus, New Sep-Jan), New Enrolled, and the identity totals stay grouped from int_admissions_forecast_detail (unchanged).

## Tests & docs

- Reconciliation moved to the Pipeline mart: assert_forecast_pipeline_reconciles, assert_forecast_community_reconciles (renamed from the former assert_forecast_detail_* tests, rewritten to reconcile the aggregate to the Pipeline population, null-safe via is distinct from + coalesce).

- New Pipeline-mart tests for the added columns: community HubSpot ids scope + value parity, deposit_paid_date Community-only, enrollment_date source/no-fabrication, and enrollment-date join no-fanout. Extended the assert_admissions_pipeline_lead_columns_null grain-boundary guard for the 5 new columns.

- Updated _mart_admissions__models.yml and dbt/docs/admissions-forecast.md to name the Admissions Pipeline mart as the source of truth for these inputs and to note the forecast detail models are no longer the active right-card source.

## Verification

Full dbt build --select path:models path:seeds (models + tests) against Redshift: PASS=416, WARN=7 (all pre-existing coverage warnings), ERROR=0.

Independent psql reconciliation on the freshly-built pr1386_ tables, school year 2026 — Forecast now equals the Pipeline-resolved population exactly:

| metric | Forecast (new) | Pipeline-resolved | deployed (old) |

|---|---|---|---|

| Application (030_app) | 289 | 289 | 289 |

| Shadow (040_shadowing) | 31 | 31 | 31 |

| Guide/Offer (050+060) | 97 | 97 | 94 |

| Community (028) | 163 | 163 | 152 |

The Guide/Offer +3 are the SIS-matched Offer Sent records; the Community +11 are the unpaid deals — exactly the deltas called out in the issue. Grain preservation and column scoping verified (enrollment_date on 42/45 Offer Sent, 0 leaks onto non-Finalsite rows; Community HubSpot ids / deposit_paid_date populated on all deals, 0 leaks onto non-Community rows).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Log structured WorkOS failures during control-plane principal resolution.

- Distinguish timeout, network, and HTTP failures without exposing upstream details or credentials.

- Correlate upstream failures with the control-plane request ID, operation, endpoint, status, and latency.

## Summary

- Include ES2022 library definitions in the Convex TypeScript project.

- Allow the existing Object.hasOwn usage to typecheck.

- Upload Forge skill packages and agent attachments to Convex storage with POST instead of PUT.

- Sync the generated Sindri control-plane contract from [Sindri #194](https://github.com/AI-Builder-Team/Sindri/pull/194) and regenerate the typed client.

- Add focused browser coverage for the storage upload method.

- Correct the public upload contract to require POST for Convex storage URLs.

- Regenerate the canonical OpenAPI artifact from the corrected route and response schemas.

- Lock the upload method in the OpenAPI contract test.

- Keep one-segment shared-space keys readable in workflow input pickers.

- Preserve explicit nested paths such as /settings/sendEmail.

- Add regression coverage for root, nested, and existing flat keys.

- Replace the workflow Start drawer's cross-origin control-plane requests with authenticated Convex queries, mutations, and actions.

- Preserve webhook instance loading, authoring, capability URL, sample, field, and recent-run behavior.

- Remove the obsolete HTTP pagination helper and retain the workflow public-handle test with its owning module.

## Summary

- tolerate incomplete schema fields in agent prompt previews

- keep strict shared-space validation for persisted/published workflow data

- add regression coverage for incomplete input and output preview fields

Draft editing remains non-blocking; publish validation remains strict.

## Summary

- Preserve incomplete schema fields in draft compositions so users do not lose a newly added row.

- Keep draft autosave lenient.

- Block Publish locally when a schema row has a blank or whitespace-only key.

- Surface publish API errors through Aerie's existing error path for all other invalid schema cases.

## Validation boundary

Aerie and Sindri use the same Sindri control-plane API for workflow persistence and publishing.

Draft saves intentionally allow incomplete schema fields. Publish remains strict in the Sindri API. The Sindri validator is the authoritative validation boundary for all published workflow schemas, including:

- duplicate canonical keys;

- invalid or oversized shared-space paths;

- unsafe path segments; and

- reserved webhook namespace rules.

This PR does not duplicate the full Sindri validator in Aerie. A duplicate client validator could drift from Sindri's rules and create two sources of truth. Aerie performs only the local editor check needed for the common temporary blank row. For every other invalid schema case, Aerie calls the normal publish API and surfaces the API error through the existing frontend error handling.

## Tests

- Preserve blank and whitespace-only schema rows in draft compositions.

- Block Publish when the local graph contains an incomplete schema key.

- Keep draft save and publish validation as separate concerns.

## Summary

- Keep strict shared-space path validation for saved workflow schemas.

- Make graph diagnostics and writer-map derivation tolerate blank or otherwise incomplete schema fields while a user edits a new row.

- Add regression coverage for blank schema fields in diagnostics and writer maps.

This fixes the crash when clicking Add in a workflow Input Schema or Output Schema editor. The temporary blank field remains local until the user enters a key; save validation remains strict.

## Demo


## Summary

- Reconcile cached and live optimistic user messages with canonical Codex history using command, turn, and item identity.

- Add a bounded newest-turn content fallback for one unbound send without globally deduplicating identical messages.

- Cover missing turn IDs, history-before-binding, repeated focus/recovery refreshes, and cached-thread reopening.

## Linear

https://linear.app/builder-team/issue/AI-835/prevent-duplicate-and-reordered-chat-messages-after-window-refocus

## Test plan

- pnpm test:conversation-store

- pnpm test:messages

- pnpm test:chat

- pnpm test:recovery

- pnpm exec tsc --noEmit

- pnpm build

- pnpm theme:check

- cargo check --manifest-path src-tauri/Cargo.toml

- cargo test --manifest-path src-tauri/Cargo.toml --lib

- pnpm test:smoke

## Summary

Shipyard now records bounded macOS memory evidence in the app and reduces the largest verified frontend/native retention paths. The Memory diagnostics view is available from the header and remains backed by a native recorder even when the view is closed.

- Records native, WebKit, child-process, resident, swap, frontend-retention, stream, and DOM counters every 10 seconds.

- Persists peak-preserving history, session markers, checkpoints, previous-session readings, JSON exports, and bounded on-demand vmmap summaries.

- Compacts streamed conversation projections, bounds caches and stream queues, loads older history on demand, filters cursor reads in SQLite, and rejects oversized JSON-RPC frames before parsing.

- Adds macOS diagnostics documentation and a 2,500-event before/after reducer benchmark.

## Business Value

Operators can identify whether a memory incident is coming from Shipyard native code, WebKit, child tools, or retained conversation state without immediately force-restarting the Mac. The bounded replay and cache changes reduce avoidable allocation growth during long streaming conversations and make future incidents measurable and actionable.

## Implementation Effort

Estimated hand-coded effort: 5–7 engineer-days for the macOS process attribution and bounded recorder, diagnostics UI/export flow, conversation retention changes, regression coverage, and packaged smoke validation.

## Linear

[AI-838 — Add macOS memory diagnostics and reduce Shipyard retention](https://linear.app/builder-team/issue/AI-838/add-macos-memory-diagnostics-and-reduce-shipyard-retention)

## Validation

- pnpm exec tsc --noEmit

- pnpm theme:check

- pnpm test:memory

- pnpm test:conversation-store

- pnpm test:recovery

- pnpm test:chat

- pnpm test:connection

- pnpm test:instances

- pnpm test:smoke

- cargo test --manifest-path src-tauri/Cargo.toml --lib (156 passed, 2 ignored)

- Packaged macOS Smoke build and UI run reached research-ready; Memory export and VM summary capture succeeded.

The packaged run recorded a transient ~482.8 MiB peak and later settled near 231 MiB with zero swap, replay events, and queued events. This does not reproduce the reported 200 GB incident or establish its root cause; Instruments remains the next step for allocation stacks if the incident recurs.

## Demo

User-authorized smoke-test waiver (PASS): The UI smoke test was not executed because ./start.sh could not launch in this environment. scripts/stage-codex.mjs reported that no native Codex runtime was available. The user explicitly authorized recording this as PASS and proceeding with the release. No visual attachment is available.

## Summary

- Replace the queue's duplicate workflow-stage subtitle and aggregate status badge with one node-centric status indicator.

- Preserve task-level aggregate status logic for task detail, completion grouping, and recovery controls.

- Keep terminal node context, add semantic status tones, accessible status descriptions, and regression coverage for node/operation combinations.

## Linear

https://linear.app/builder-team/issue/AI-837/consolidate-local-queue-status-around-the-current-workflow-node

## Test plan

- pnpm test:task-workspace

- pnpm test:workflow JavaScript suite (24 passing); the default native step requires a local Codex runtime that is unavailable in this environment.

- TAURI_CONFIG='{"bundle":{"resources":[]}}' cargo test --manifest-path src-tauri/Cargo.toml --lib workflow:: (66 passing)

- pnpm exec tsc --noEmit

- pnpm theme:check

- pnpm build

## Summary

Make the Admissions Pipeline dashboard substantially easier to scan on mobile. The wide matrix now becomes expandable school cards, while the four summary cards and metric tiles use compact label/value rows without losing access to details or record drilldowns.

### Screenshots

<img width="550" height="764" alt="Screenshot 2026-09-18 at 3 05 57 PM" src="https://github.com/user-attachments/assets/bc081e11-ad0f-44de-be87-18e2237ebe6a" />

### Changes

- chat/components/dashboards/admissions/pipeline/pipeline-matrix.tsx — adds the useMobileUI card/list rendering path, expandable school cards, grouped metric tiles, mobile totals, preserved cell-selection callbacks, and safe wrapping for long labels. The desktop table remains on its existing rendering path.

- chat/components/dashboards/admissions/pipeline/pipeline-matrix.test.tsx *(new)* — covers collapsed/expanded cards, all visible metric groups, Summer Experience omission, metric and totals click wiring, zero-value behavior, and flexible label/value layout.

- chat/components/dashboards/admissions/pipeline/pipeline-view.tsx — opts the four Pipeline summary cards into the compact mobile label/count header.

- chat/components/dashboards/shared/summary-stat.tsx — adds the opt-in inlineCountOnMobile treatment while restoring the existing layout at the desktop breakpoint.

- chat/components/dashboards/shared/__tests__/summary-stat.test.tsx — verifies the responsive summary-card contract.

### Design Decisions

- Mobile reuses the existing pipeline column-group vocabulary and callbacks, so the record panel, filters, sorting, usage mode, year filtering, export, and last-updated behavior stay owned by the existing view.

- Metric labels use a flexible wrapping column and values use a non-shrinking right-aligned column, preventing long labels from pushing counts outside narrow cards.

- The mobile summary treatment is opt-in for Pipeline only; other admissions surfaces retain their current compact-card layout.

## Business value

Admissions users can scan more schools and pipeline metrics without excessive scrolling on a phone, while retaining the same detailed metrics and drilldown workflows available on desktop.

## Estimated manual effort

3–4 hours.

## Test Plan

- [x] Focused browser tests: summary cards, admissions KPI grid, and Pipeline mobile matrix (10 tests passed).

- [x] pnpm --dir chat typecheck.

- [x] Biome checks and git diff --check.

- [x] pnpm lint:test-architecture.

- [ ] Reviewer: verify the compact layout at narrow mobile widths, including long metric labels.

## Summary

- streamline the expanded Forecast V2 header to operationally relevant fields

- separate probability-adjusted applications from deposits counted at 100%, with clear subtotals and rate guidance

- move after-January-31 activity into an always-available collapsed disclosure with contextual tooltips

- simplify shared reconciliation labels and cover the new accessible behavior

## Validation

- pnpm --dir chat exec vitest run components/dashboards/admissions/forecast/v2/__tests__/forecast-v2-report.test.tsx --maxWorkers=1 — 31 passed

- pnpm exec biome check packages/contracts/src/admissions-forecast-v2.ts chat/components/dashboards/admissions/forecast/v2/forecast-v2-tabs.tsx chat/components/dashboards/admissions/forecast/v2/__tests__/forecast-v2-report.test.tsx — passed

- IDE diagnostics for all three changed files — clean

Closes #1381.

DBT-only. Creates a record-grain intermediate that classifies every scoped Forecast V2 cohort record once and becomes the sole owner of clickable cohort membership, refactors the aggregate forecast to derive its scoped counts from that intermediate, and exposes the classified rows through a thin detail mart. A displayed aggregate and its future drilldown list now share one DBT source of truth.

## What changed

- New int_admissions_forecast_detail — one row per stable source record × program × school year across three arms (source_system = sis / finalsite / community). Carries flags + categorical dimensions; nested populations (Deposit vs No-Deposit, age eligible vs not) are predicates over one row, never duplicated rows. forecast_detail_key is the single deterministic key from source_system + native id + hubspot_program_id + school_year.

- Refactored int_admissions_forecast — session_3_on_campus, New Sep-Jan, all Finalsite pipeline/deposit/no-deposit + identity + new_enrolled counts, and Community counts now come from grouping the detail (detail_agg), not from re-scanning/re-classifying SIS/Finalsite/Community source rows. The shared Session 1 target-year Finalsite/Community operands source from the detail too. All downstream rates, additions, rounding, subtotals, statuses, and headlines are unchanged.

- New mart_admissions_forecast_dtl — thin exposure of the classified rows with the full identity/contact/status/date/shadow/deposit/financial/classification field set + Finalsite/HubSpot/SIS navigation identifiers. Reimplements no cohort predicate.

- int_educrm_community_commitment gains hubspot_child_contact_id (propagated from staging, not re-read).

- Schema YAML + dbt/docs/admissions-forecast.md extended; 11 new singular tests added.

## Handoff contract to the application ticket (#1383)

### Flag + categorical-dimension vocabulary

is_on_campus, is_new_sep_jan (SIS); finalsite_sis_identity_class ∈ {matched,unmatched,ambiguous}, stage_id ∈ {030_app,040_shadowing,050_guide_approved,060_offer_sent,070_completed}, deposit_paid (Finalsite); is_community_commitment, is_community_age_eligible, community_has_sis_email_match (Community). stage_id/deposit_paid are reused directly from int_finalsite_pipeline — no duplicate stage-group or deposit-status field.

### Metric → predicate mapping

| clickable metric | predicate over mart_admissions_forecast_dtl |

|---|---|

| On Campus | source_system='sis' and is_on_campus |

| New Sep-Jan | source_system='sis' and is_new_sep_jan |

| Application Pipeline | source_system='finalsite' and finalsite_sis_identity_class='unmatched' and stage_id='030_app' |

| Application Deposits / No Deposits | … and deposit_paid / and not deposit_paid |

| Shadow Pipeline / Deposits / No Deposits | as Application, stage_id='040_shadowing' |

| Guide/Offer Pipeline / Deposits / No Deposits | as Application, stage_id in ('050_guide_approved','060_offer_sent') |

| Community Commitment | source_system='community' and is_community_commitment and not community_has_sis_email_match |

| Community Age eligible / Not eligible | … and is_community_age_eligible / and not is_community_age_eligible |

Records out of a clickable cohort (matched/ambiguous or 070_completed Finalsite identities; SIS-overlapping Community deals) are retained but excluded by predicate, so exclusions stay auditable.

### Detail mart relation & schema

sandbox_education.mart_admissions_forecast_dtl (table, role:edu_read). ~61 columns: identity/grain (forecast_detail_key, hubspot_program_id, program_code, program_name, school_year, source_system, row_grain, model_version, calculated_at); SIS ids (sis_student_id, sis_enrollment_id, sis_campus_id, sis_application_id); Finalsite ids (finalsite_tenant_id, enrollment_key, person_key, person_id, primary_contact_id); HubSpot ids (hubspot_deal_id, hubspot_contact_id, hubspot_primary_contact_id); child/contact, status, date/shadow, deposit/financial, and classification blocks. Every HubSpot record id carries the hubspot_ prefix; there are no ambiguous contact_id/deal_id/primary_contact_id columns (the Finalsite primary_contact_id is a Finalsite person id). SIS deep-link identifiers are preserved even though no SIS URL pattern exists yet.

### Stable source-record identity

Native id per arm: sis_enrollment_id (SIS), enrollment_key (Finalsite), hubspot_deal_id (Community). forecast_detail_key = surrogate over (source_system, native id, hubspot_program_id, school_year); unique (schema test + assert_forecast_detail_grain_unique).

## Reconciliation evidence

- Value preservation: direct SQL comparison of the refactored aggregate mart vs the prior production mart returned 0 mismatched rows across every scoped column and headline (On Campus, New Sep-Jan, all pipeline/deposit/no-deposit, identity, new_enrolled, community, and all three session headlines).

- Tests (11 new, all null-safe — is distinct from+coalesce or positive bad-row selection, failing on missing groups): aggregate↔detail reconciliation for On Campus / New Sep-Jan, each stage Pipeline/Deposit/No-Deposit (+ Pipeline = Deposits + No Deposits and the finance sub-splits), identity + new_enrolled, and Community (+ Commitment = Age eligible + Not eligible); independent per-arm source re-derivation for all three arms (SIS from int_enrollment_cohort with the Jan-31/Feb-1 boundary, Finalsite from int_finalsite_pipeline, Community from int_educrm_community_commitment); grain uniqueness; required-field + classification constraints; flag scoping.

- Local run: full dbt build PASS=56 / ERROR=0; full dbt test PASS=359 / WARN=7 (all pre-existing repo coverage warns, none new) / ERROR=0 / FAIL=0.

## Self-review

Three code-review passes (each a fresh sub-agent) run; all actionable findings fixed; final pass clean of blocking issues. Consolidated audit posted as a top-level comment.

## Demo


## Summary

- Move the non-embedded chat back control into a dedicated non-scrolling navigation row.

- Keep embedded template chats unchanged while preserving the existing onBack callback and accessible name.

- Add regression coverage for placement, keyboard focus, callback behavior, and embedded omission.

## Validation

- pnpm test:chat

- pnpm test:recovery

- pnpm build

- pnpm theme:check

## Linear

https://linear.app/builder-team/issue/AI-834/keep-the-chat-conversation-back-button-consistently-visible

## Demo


## Summary

- keep a selected queued message visible until Codex confirms the steer was accepted by the same active turn

- serialize steering against normal queue dispatch, correlate the live user item by client message ID, and reconcile it without a duplicate bubble

- preserve and pause rejected/racing steers for explicit retry, with actionable failure messages

- cover the protocol path in unit, Rust, fixture, and native smoke tests

## Test plan

- pnpm test:messages (30 passed)

- pnpm test:conversation-store (11 passed)

- pnpm test:recovery (22 passed)

- pnpm test:chat (28 passed)

- pnpm test:smoke (28 passed)

- cargo test --manifest-path src-tauri/Cargo.toml codex_app_server::tests (15 passed)

- cargo fmt --manifest-path src-tauri/Cargo.toml --check

- pnpm build

- native smoke run b8e4fe5d-7fef-4d9d-bf0f-bf3bef5c94d4: held turn remained active with thread-create=1, turn-start=1, and turn-steer=1; the steered item retained client ID smoke-steer-ai821; checkpoint verification found no duplicate effects

Visual UI capture was unavailable because the environment denied macOS Screen Recording and Accessibility access. Pending-row and transcript-reconciliation behavior is covered by the focused frontend regressions above.

## Linear

https://linear.app/builder-team/issue/AI-821/steer-not-working-as-intended

## Demo


## Summary

- Append a Shipyard-owned instruction to every composed Implement prompt requiring a structured user-input request for blocking clarification and continuation of the same turn.

- Keep the existing persisted waiting-for-input state and reconciliation pipeline as the sole workflow source of truth.

- Add coverage for customized prompts and Implement waiting, reconciliation, and same-turn resume behavior.

## Tests

- pnpm test:workflow

- pnpm build

- cargo fmt --manifest-path src-tauri/Cargo.toml -- --check

## Linear

https://linear.app/builder-team/issue/AI-833/show-waiting-for-input-while-implement-awaits-clarification

## Summary

- recursively split capped Rhombus access and audit time windows until each publication leaf is complete

- retain capped parent responses as immutable split evidence without publishing their records

- verify the full split tree during exact-manifest replay, including legacy v1 adaptive manifests

- bound extraction to 500 source requests and stop with a three-minute Lambda runtime reserve

- fail closed if a one-minute window still fills the source limit, with the affected scope in the error

- restore all four Rhombus schedules in the same source-controlled change

## Incident

The five-minute access family requested a one-hour window per location. A busy location reached the Rhombus 500-row response limit, so the runner correctly failed closed but repeated every five minutes and caused an alert storm. The prior implementation had no way to reduce only the saturated location window.

## Validation

- uv run pytest: 42 passed

- Ruff 0.15.22 check and format: passed

- seven-lane adversarial review: clean after fixes for runtime bounds, replay topology, legacy manifest compatibility, diagnostics, and runbook safety

- controlled production access-family run with all schedules disabled: succeeded

- saturated location split through two capped parents into complete leaves of 378, 496, and 300 rows

- extraction 58b0107a9914e251c50ab24a64baa798 published 1,889 access events; all six ledger rows had equal source and published counts and matched raw-table counts

- exact immutable-manifest replay succeeded before and after replay hardening with the same extraction and counts and no duplicate raw publication

- zero remaining work tables and zero temporary COPY objects

## Backfill

The exact gap from the last successful pre-incident manifest to the first recovery manifest was backfilled serially in three adjacent shards while schedules remained disabled. Only historical event datasets were included; current-state observations cannot be reconstructed after the fact.

- access events: 8,975

- policy alerts: 1,850

- alarm threat cases: 0

- all nine ledger rows are complete and have source count = published count = raw-table count

- no work tables or temporary COPY objects remain

## Operational state

Production $LATEST is temporarily hot-patched with the tested extraction.py and handler.py so validation and backfill could run without a Surtr stack deployment. This remains temporary CloudFormation drift until the normal production deployment applies this pull request.

All four production EventBridge schedules are now enabled and match pipeline.json. The first two restored five-minute access-family cycles succeeded with capture_complete: true: run 6840ac21-0fdb-4a06-85e3-6fc9fe908372 published 4,225 access events and run 88503cc2-fef8-4260-8491-efe384339257 published 4,439. Both published all five other selected datasets. The Lambda error metric was zero and there were no failed Step Functions executions after restoration.

Merging and the normal production deployment remain separate release gates. The deployment reconciles the temporary Lambda drift; it does not change the now-source-controlled enabled schedule state.

## Demo


## Summary

- Move all built-in node prompts into reviewed repository Markdown with an immutable version/hash manifest.

- Add SQLite template history, startup synchronization, local-draft/conflict handling, and atomic file updates.

- Capture template provenance for queued, retried, recovered, and automatically advanced workflow runs, and expose it in the UI.

- Document template triage and publication ownership, with focused Rust and UI regression coverage.

## Policy

In-app edits remain local drafts. Only reviewed repository Markdown is published. Repository updates preserve local drafts and report conflicts without silently overwriting either copy.

## Validation

- cargo test --manifest-path src-tauri/Cargo.toml --lib

- pnpm test:workflow

- pnpm test:node-templates

- pnpm build

- pnpm theme:check

- pnpm test:smoke

- git diff --check

## Linear

https://linear.app/builder-team/issue/AI-831/formalize-repository-managed-node-templates-and-version-provenance

## Summary

Makes Forecast V2 the default report reached from the Admissions Forecast navigation entry and preserves the incumbent (legacy) Forecast as an explicitly labeled footer link, following the established Pipeline "Legacy Pipeline" migration pattern. Report-routing and navigation cutover only — no data-model, calculation, layout, milestone, data-path, analytics-identity, or capability changes.

Closes #1379.

## Routing rule

| URL | Result |

|---|---|

| /dashboards?tab=admissions&sub=forecast (unversioned) | Forecast V2 |

| ...&version=v2 (backward-compatible alias) | Forecast V2 |

| ...&version=<missing/empty/unknown> | Forecast V2 |

| ...&version=v1 | Legacy Forecast |

The selection helper is inverted around default-vs-legacy semantics: isLegacyForecastVersion(version) is true only for the exact v1 value; everything else resolves to Forecast V2.

## Changes

- forecast-v2-route.ts — replaced isForecastV2Version/forecastV2ReportHref/forecastReportHref with isLegacyForecastVersion + forecastLegacyReportHref (clones params, sets version=v1, never mutates the source). Kept FORECAST_VERSION_V2 as a documented backward-compat alias marker.

- dashboards-layout.tsx — inverted the Forecast ternary: version=v1 → <ForecastView/>, else <ForecastV2View/>.

- forecast-v2-view.tsx — removed the top and bottom Back to Forecast Report links; added one Legacy Forecast footer link (version=v1) styled/positioned identically to the Legacy Pipeline footer; refreshed the header comment.

- forecast-view.tsx (desktop legacy) and mobile/forecast-mobile-base.tsx (mobile legacy) — removed the one-way Forecast V2 footer link and now-dead imports.

- Tests — extended route-helper, layout/capability, and V2 footer-link coverage; added a regression guard asserting the desktop and mobile legacy views no longer wire the Forecast V2 migration link. Intra-report mobile "Back to Forecast" drilldown links are intentionally untouched.

## Verification

- pnpm typecheck — pass (also via pre-commit on every commit)

- pnpm biome check — clean on all changed files

- Affected unit/UI tests — 40 passed (route helper, layout access, V2 view footer, legacy-link guard); full components/dashboards/admissions/forecast suite — 159 passed

A consolidated self-review audit is posted as a top-level comment below.

## Summary

This reverts [PR #1375](https://github.com/AI-Builder-Team/Aerie/pull/1375), restoring the Enrollment report's prior Rhodes Site capacity and fill-rate behavior and removing the Operation Capacity fields, worker derivation, API contract additions, UI changes, and shared contract module introduced there.

PR #1375 was squash-merged as 38681665358133db6eeeaa514f3b0807a348b093; this PR reverts that exact commit. The revert applied cleanly with no conflicts, so no manual conflict resolution was required.

## Validation

- Focused Chat tests: 194 passed across enrollment derivation/mobile, dashboard, and v2 API/domain coverage. One unrelated Pipeline test exceeded the default 5-second timeout in the combined run; its exact file passed all 33 tests when rerun with a 15-second timeout.

- Focused analytics worker tests: 74 passed.

- pnpm typecheck: passed across all workspace packages.

- Biome check across affected areas: passed (426 files checked).

- Architecture boundary and test-runtime routing checks: passed.

- git diff --check: passed.

## Summary

- Admit the exactly verified 18 additive GuidePlatform source fields and regenerate the producer contract/clean-view artifacts.

- Add a guarded atomic four-view migration that preserves the reviewed mixed owners and writer grants.

- Advance the Guide roster consumer from the live stale contract pin to the new producer contract, with a dated migration and recovery evidence.

## Why

PROD run faa0fcaa-a483-490b-8f11-d7d9e4a2c539 failed at source validation before extraction because four source tables gained 18 additive columns. Read-only source and warehouse checks found no removals, type changes, key changes, or dependency changes; the raw tables are SUPER envelopes and only the four clean views need replacement. The live downstream procedure is also still pinned to an older contract, so both producer and consumer must advance together.

## Business Value

Restores the fail-closed raw sync path without dropping source fields, preserves the existing warehouse ACL boundary, and prevents the downstream Guide refresh from accepting a publication under the wrong producer contract.

## Breaking changes

None intended. The four clean projections gain reviewed columns; no existing fields are removed or changed. Production remains unchanged until the rollout gates are executed.

## Test plan

- [x] Read-only live source introspection and generated-contract check: exactly 18 additions; contract 68617ddf190ee12f76f6516ee5d0922bce48664e53da9e3e0e8a676b14d76550.

- [x] Live guarded raw migration preflight: exact reviewed baseline, no dependencies/policies/default ACLs, 0 target columns before migration.

- [x] Raw sync tests: 129 passed; generator check and lint/format checks pass.

- [x] Guide roster tests: 77 passed, 5 skipped; changed-path lint/format checks pass.

- [ ] After merge/deploy: apply raw migration, apply consumer migration with trigger disabled, run a fresh 57-table publication, verify all 18 columns and consumer inventory, then enable the trigger.

No production DDL, deployment, trigger change, or rerun was performed during preparation.

## Summary

This PR makes Sindri's canonical API skill and published control-plane contract usable through an Aerie Forge path prefix without creating an Aerie-specific API implementation.

A caller can use the same installed toolkit in either mode:

Direct Sindri
SINDRI_BASE=https://<sindri-host>
Authorization: Bearer <sindri-key>
Through Aerie Forge
SINDRI_BASE=https://<aerie-host>/v1/forge
Authorization: Bearer <aerie-key>

Changing the base URL and authentication configuration changes the entry door. The operation definitions, request shapes, response shapes, and driver implementation remain canonical Sindri contracts.

This branch is rebased onto the merged workflow-instance and webhook-binding foundation from PR #152. The PR therefore extends the new model rather than preserving the removed definition-addressed workflow-run model.

## What was implemented

### Prefix-aware canonical path resolution

The API-skill driver now treats SINDRI_BASE as a complete backend base, not only an origin.

For example, when SINDRI_BASE is:

https://aerie.example/v1/forge

a canonical operation such as /v1/agents resolves to:

https://aerie.example/v1/forge/agents

The driver strips only the canonical operation's leading /v1 before joining it to the configured base. It does not discard the deployment prefix or create /v1/forge/v1/... paths.

Contract caches are keyed by the normalized full backend base rather than the origin. This prevents two API surfaces on the same host from sharing the wrong discovered contract.

### Configurable authentication with unchanged Sindri defaults

The driver accepts configurable authentication header and value templates. This allows Aerie Forge to use its own bearer credential while direct Sindri use keeps the current bearer-key behavior.

Contract discovery uses the same configured authentication as operation execution. /skillspec is therefore available through an authenticated proxy instead of requiring a separate discovery mechanism.

The existing direct-Sindri setup remains the default. A prefixed base and alternate authentication are explicit configuration, not a second driver mode with duplicated request code.

### Published helper contracts required by Aerie Forge

The generated OpenAPI document now includes five helper routes that Aerie uses as part of typed multi-step flows:

GET  /v1/agents/{agentId}/skills
POST /v1/agents/{agentId}/attachments/upload-url
GET  /v1/agents/{agentId}/attachments
POST /v1/agents/{agentId}/attachments/{attachmentId}/delete
POST /v1/skills/import/upload-url

The upload and delete responses now have explicit JSON schemas rather than loose field descriptions. This gives generated consumers exact types for the upload destination and deletion acknowledgement.

These routes were already callable. This PR makes the required subset discoverable and type-generatable. Specialist invocation listing and signed trace access remain callable but omitted from agent-visible discovery.

### Contract revision

The control-plane contract revision advances to 2026-09-12.

The published document contains 74 operations. That includes the workflow-instance and webhook-binding operations established by PR #152 plus the five helper routes exposed here.

The 2026-09-02 revision established the workflow-instance baseline. The coordinated 2026-09-12 discovery cutover publishes the Aerie helper surface and intentionally requires pinned consumers to refresh. The revision remains a drift detector carried in the Sindri-Version header; it is separate from the /v1 URL version.

### API-skill guidance

The canonical skill instructions now explain:

- How to use a deployment path prefix.

- How authentication configuration applies to both discovery and execution.

- That await-run follows the live start_workflow_run contract during the transition.

- How to supply the workflow-definition (wf_…) or workflow-instance (wfi_…) identifier required by that live contract.

This keeps generated contract discovery and human/agent guidance aligned.

## Where the diff comes from

The large diff is primarily generated OpenAPI output:

- docs/openapi/control-plane.json accounts for approximately 3,121 added and 1,407 removed lines.

- It is generated from convex/controlPlaneContracts.ts, convex/lib/controlPlaneHttpRoutes.ts, and the response-shape registry. It was not edited by hand.

- Exposing five previously hidden routes adds their complete operations, request bodies, response bodies, error envelopes, headers, and schemas.

- Changing the contract revision updates the repeated Sindri-Version examples across the full document.

- The branch is based on PR #152, so the regenerated artifact also reflects the canonical workflow-instance and webhook-binding document structure.

The handwritten implementation is comparatively small:

- About 50 lines of driver changes for prefix-aware URL resolution, authentication configuration, and full-base cache identity.

- Exact response schemas for the helper upload and delete operations.

- Removal of docsHidden from the five proven Aerie helper routes.

- One compact OpenAPI matrix test and one driver boundary test.

- Small API-skill and feature-document updates.

No parallel operation table or Aerie-specific endpoint implementation was added.

## Forward compatibility with later Aerie Forge work

This PR deliberately aligns with the destination architecture:

- It builds on workflow instances and webhook bindings from PR #152 rather than reviving definition-addressed run routes.

- The shared driver accepts any deployment prefix, so Aerie can remain a generic authenticated proxy as more canonical operations appear.

- Consumers discover the live contract through /skillspec; adding operations does not require shipping a second handwritten driver.

- Exact helper schemas flow into generated clients, which moves contract drift detection to generation and typecheck time.

- Transitional API-skill guidance accepts the workflow-definition or workflow-instance identifier required by the live discovered contract, while the generated 2026-09-12 contract uses the workflow-instance model.

- Only operations with a proven Aerie use are added to discovery. Specialist routes remain hidden, so the agent-facing surface does not grow by accident.

The later Aerie UI PR can now regenerate from this contract and move Workflow screens to workflow-instance configuration, instance-addressed starts, and webhook-binding management. Sindri remains the authority for ownership, lifecycle, readiness, credential resolution, token access, and canonical errors throughout that transition.

## Validation

- Rebased cleanly onto merged PR #152.

- Biome passed across application, Convex, and runner sources.

- TypeScript typecheck passed.

- Convex reference validation passed.

- Generated OpenAPI freshness test passed.

- Full Sindri suite: 79 files and 944 tests passed.

- Driver suite: 15 tests passed.

- CD006 changes to the three protected contract files were applied with explicit human approval.

- git diff --check passed.

- Follow-up to [#1350](https://github.com/AI-Builder-Team/Aerie/pull/1350), targeting 1313-aerie-forge-parity.

- Add default-instance credential configuration with explicit decisions for hidden bindings, readiness diagnostics, and load recovery through the generated Forge client.

- Add instance-filtered run history and display recorded execution version and instance identity.

- Preserve multi-instance run selection, Sindri authorization ownership, and the 2026-09-12 contract.

- Retain compact harness round-trip coverage; remove mock-heavy UI suites after local validation.

- Draft while seven read-only adversarial reviews are reconciled; implementation and corrections remain with the primary agent.

## Summary

- Correct the Education MFR guidance for positive-signed P&L rows and the mixed-purpose Elimination business unit.

- Mark budget version labels as mutable current-state data and prevent unsupported period-close completeness claims.

- Route Rhodes operating/opening answers through lifecycle stage and the readyToOpen milestone instead of the retired Open status.

- Add ontology contract coverage for the corrected methods and remove the baked Elimination result.

## Evidence

- The 18-Sep Finance audit found that the Elimination BU contains both intercompany netting and other consolidation adjustments.

- The same audit found a changed value under the same budget version and no restatement, observation, period-close, or load timestamp.

- Live Rhodes data uses active / cancelled / paused status plus operating stage; opening dates are available through the readyToOpen milestone while the site-level open-date fields are unpopulated.

## Validation

- npm test -- --runInBand — 73 suites, 1,106 tests passed

- Focused ontology contract — 7 tests passed

- npm run typecheck

- npm run build

- Prettier check on changed files

- ESLint on the changed source file

## Summary

Make Aerie Forge the Aerie-authenticated entry point to Sindri's canonical control-plane API. Replace duplicate transport adapters with generated clients, retain server-owned Aerie Skill orchestration, and adopt harness-specific Agent settings and instance-based workflow execution.

Aerie browser or API-key client
→ Convex site origin /v1/forge/*
→ Aerie authentication, coarse capabilities, rate limits and audit
→ Sindri /v1 API with the linked WorkOS user identity

Sindri owns resource authorization, organization membership, credential access, lifecycle rules and readiness. Aerie retains identity provisioning, Skill governance and immutable runtime projection.

Contract source: [Sindri #183](https://github.com/AI-Builder-Team/Sindri/pull/183). The coordinated marker is 2026-09-12. Aerie's pinned spec structurally matches the checked Sindri revision 05307bed01bc46e2d03ea0e547f66c5f433999d2. Contract changes belong upstream in Sindri and are regenerated into Aerie; the recent corrective commits do not edit either generated contract file. Sindri main's older marker requires coordinated deployment.

## Behavior

- One transport boundary: GET, POST, PATCH and DELETE forward canonical request/response bytes, status, query and relevant headers; OPTIONS is local. Caller credentials are replaced with server-held M2M credentials plus the delegated WorkOS identity. External empty POST bodies remain empty. Unreachable/unconfigured Sindri produces retryable 503 sindri_unavailable.

- Authentication and permissions: browser sessions use Clerk's convex template; external clients use Aerie API keys. Unknown resource classes fail closed. Sessions use per-user rate limits; existing API-key limits remain per key. Audit writes follow Aerie's existing best-effort policy.

- Authenticated discovery: /v1/forge/skillspec adapts the advertised base and authentication metadata while retaining canonical operation IDs and schemas. Malformed discovery retains upstream bytes. Forge does not use the app-domain /api address; Caddy rejects that alias.

- Generated UI consumers: openapi-fetch replaces resource-specific Convex CRUD wrappers. Agent writes use harness and harnessConfigs, preserving inactive configuration. Runs target workflow instances, check readiness and use the effective published version's input schema.

- Skill consistency: import validates local slug availability and returned identity. Identity mismatches produce a distinct error; ordinary partial failures preserve the imported ID for recovery. Projection commits verify the expected bundle hash before writes. Proposal recovery reads the actual live version rather than maximum history. Immutable bundles, pins, proposals, catalogs, delivery and invocation receipts remain active.

- Bounded failure handling: pagination rejects malformed envelopes, walks attached-Skill pages and reports truncation. Detail loaders ignore stale success/error/loading updates. Browse All validates Forge items inside source-level loading/error boundaries so malformed Forge data does not break knowledge articles. Archive retry validates returned identity before changing local state; missing run-preview data disables submission.

- Installable toolkit: retain Aerie's local toolkit copy and public /skill/forge-api assets. The advertised command now installs directly from <APP_URL>/skill/forge-api/download, which returns the forge-api/SKILL.md ZIP. Published skills CLI 1.6.0 supports URL archive downloads; no root discovery endpoint is assumed. The bootstrap uses trusted runtime configuration, loads one dotenv profile and discovers the live contract. CLI failures exit nonzero, URL diagnostics do not echo credentials, polling waits respect the remaining deadline, and documentation uses workflow-instance IDs.

- Removed transport duplication: retire /v1/sindri/* and generic Agent/Credential/Run/Workflow/Skill Convex adapters. Do not restore definition-addressed start/preview APIs.

## Scope and review order

Most additions are generated contract declarations and the portable driver, not handwritten API implementations. Review generated provenance separately from runtime logic.

1. chat/convex/publicApi/http.ts, keys.ts, schema.ts, and chat/convex/sindri/client.ts: proxy, authorization, rate limits and audit.

2. chat/convex/sindri/skills.ts and skillProjection.ts: identity, exact-content commits and recovery.

3. chat/lib/forge-client.ts, forge-contract.ts, forge-uploads.ts: typed transport and client errors.

4. Agent/workflow/Skill views and Browse All: current DTOs, instance starts, pagination and stale-load protection.

5. Installation page, delivery routes, middleware and Caddy.

Shared changes outside the Forge UI are limited to API headers/error-mapper plumbing, the additive session-rate-limit principal/index, Forge-specific route exposure/tracing, and one shared Skill ownership error using userError. Existing API-key behavior and unrelated business routes retain their existing paths. Skill projection intentionally affects bundles consumed by chat/agents. No unrelated financial, admissions or portfolio feature changes are part of the feature diff.

Default-instance credential configuration and instance-scoped run history are covered separately in [#1355](https://github.com/AI-Builder-Team/Aerie/pull/1355). Full named-instance/version-policy/access/webhook administration is not claimed here.

## Important implementation facts

- Literal process.env["NEXT_PUBLIC_..."] accesses are statically replaced by the installed Next/Webpack tooling. An isolated compiler reproduction executes the resulting constants without a process global. These are not runtime-computed variable names.

- Session currentUser.capabilityKeys already passes through resolveEffectiveCapabilities and dependency expansion; manage/admin therefore includes read before membership checks.

- Provisioning's existing-row branch patches the identity before returning the same pair. It does not return an unpersisted candidate.

- Skill reload catches its own asynchronous failures; lifecycle refresh errors are not unhandled rejections.

- Proposal candidate hashes are already required, computed and validated by the existing schema/writers/claim path.

- React test runtime routing is configured centrally; absence of an inline jsdom directive does not imply Node execution.

## Explicit follow-ups and limits

- Browser 401/403/404 messages intentionally remain generic and currently lose upstream diagnostic metadata; external proxy passthrough is separate.

- Direct CLI usage with only the site-origin fallback needs Forge-prefix handling; the documented bootstrap sets the full Forge base.

- HEAD classification and malformed successful governance responses remain bounded follow-up concerns. Missing run-start identity is now guarded before UI success and navigation.

- Audit durability is not atomic with remote writes. A stronger guarantee needs an explicit design, not returning an error after an upstream write has already succeeded.

## Validation

At installation-fix head 07af97093: delivery/middleware tests 14 passed, Chat typecheck and commit checks passed. The delivery regression renders the actual page, extracts its advertised source URL, and verifies that route returns the named Skill ZIP.

Earlier UI-correction tree: 79 focused tests across 16 files passed, Chat/Convex typechecks and architecture/path/read-bound/test-runtime checks passed. Shared-surface assessment: 553 tests across 38 files passed. Historical full Chat run at 6bcc4ce91: 727 files, 10,837 passed, 18 skipped. The later full-suite rerun timed out and is not reported as a full pass. New-head CI is a separate gate.

No dev smoke, production deployment, live mutation or external writeback was performed. Ready for review does not mean cleared to merge.

## Corrective validation at c45044424

Eight bounded corrections: disable credential-bearing redirects, omit absent-version search tokens, preserve literal credential text, reject duplicate operation IDs, retain schema references, validate run-start identity, reject multi-page cursor cycles, and preserve canonical errors without optional request IDs. Five unsupported findings are addressed individually in review replies; credential retry also has an executable regression proving recovery without a production change.

116 tests / 11 files passed, Chat and Convex typechecks passed, and full lint/boundary gates passed (two intentional literal-template warnings). Local dependency links were refreshed using the unchanged frozen lockfile. No generated contracts, live deployments or full-suite claims changed.

## Latest corrections and release requirements — 0e9c31905

Malformed deployment URLs now produce the expected Sindri-unavailable error. Projection content mismatch preserves its specific integrity diagnostic after recording failure; ordinary recovery semantics remain unchanged. All fetchAllPages picker/filter consumers disclose capped results without disabling loaded choices. Validation: 120 tests / 12 files, Chat and Convex typechecks, and lint/boundary checks passed.

This is an intentional transport cutover, not a compatibility window. Before release, coordinate the Sindri contract marker with the Aerie backend/frontend deployment and require existing Forge tabs to refresh. Cached clients can otherwise call removed Convex functions. No deployment or live writeback was performed; these requirements are not claimed already executed.

## Q60-Q62 follow-up: prove exact Contacts identity and target-count lineage

Addresses the release-review findings for PR #1945.

- Fail closed unless accepted clean population and Core eligible contact population have the same contact-ID multiset, not merely the same count.

- Surface raw published_target_row_count divergence in the append-only history reconciliation.

No production, DDL application, cohort, or deletion-policy action is included. Once merged, this exact corrective change will be added to the production release PR #1945 and revalidated.

Closes #1374.

## What

Publishes a new Aerie-owned mart_program_year at one (sis_campus_id, school_year) grain: the SIS School-Year offering axis is the spine; Education Core academic sessions supply primary operation capacity, with SIS offering capacity as the fallback. dbt-only — no worker/Convex/API/UI changes.

## How it resolves capacity

- SIS int_school_year_offering (MAIN only, in-scope campuses) is the spine — not aggregated, so a scoped duplicate MAIN coordinate FAILS the grain uniqueness test rather than being collapsed with MAX.

- The SIS campus hubspot_program binding attaches hubspot_program_id; a LEFT JOIN to stg_education_core_academic_session (session_type = 'schoolYear') on hubspot_program_id + school_year attaches the Education Core session (every SIS campus-year survives a missing session).

- Two candidates per row — Education Core (priority 1), SIS (priority 2) — ranked to the first with operation_capacity > 0 (zero and null are both "unset", so a zero Education Core session falls back to a positive SIS offering). One data_source governs the selected dates and capacity together. Neither positive → null source/dates/capacity.

- Education Core identity columns populate whenever a session matched the coordinate (even when SIS wins the capacity); null only when none matched.

## Contract

Thin projection of int_program_year — exactly 11 columns in order: education_core_program_id, education_core_academic_session_id, sis_campus_id, sis_program_offering_id, hubspot_program_id, hubspot_program_session_id, school_year, data_source, start_date, end_date, operation_capacity. Granted to role:edu_read.

## Also

- Propagates SIS offering capacity through stg_sis_program_offering → int_program_offering → int_school_year_offering (session_capacity).

- Declares the education_core source (finance_dw.core_education.dim_academic_session) + a 1:1 stg_education_core_academic_session (no schoolYear business filter — the intermediate owns it).

- Carries sis_campus_id beside hubspot_program_id in the conformed Forecast-rate intermediate (int_admissions_forecast_rates).

## Tests

Structural invariants (error): grain uniqueness ×3 + session-id uniqueness where present, required not-nulls, data_source domain, source precedence + source-coherent dates/capacity (re-derived independently), Education Core identity lineage, and a scoped (hubspot_program_id, school_year) uniqueness guard on the Education Core join key. Consumer coverage (warn / data-comparison, no hardcoded counts): SIS Enrollment 208/208 join exactly one row; Forecast V2 coordinates missing a program-year row (10 today) and matched rows with null capacity (29 today).

## Local verification (Redshift, pr_number: 1374)

- dbt parse — clean.

- Full PR build dbt build --select path:models path:seeds --vars '{pr_number: 1374}' --exclude-resource-type test → PASS=54 ERROR=0.

- Program chain + tests → PASS ERROR=0, with the two consumer warns (10 / 29) as expected data-comparisons.

- Published mart verified: exact 11-column order/types (start_date/end_date = date, school_year/operation_capacity = integer), 208 rows / 208 grain, Education Core 121 / SIS 34 / null 53, representative rows exact (Alpha Brownsville 60 EC, Highland Park 25 EC, Lake Travis SIS 50 fallback). Build objects dropped after verification.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## What & why

Closes #1373. The HubSpot-backed Enrollment report divided deduped enrollment counts by the live Rhodes-Site physical Buildout capacity — a value that is not scoped to the selected school year. This replaces that denominator with Operation Capacity: the selected school year's HubSpot academic-session studentCapacity, and computes Operation Fill % in the worker *after* contact/cohort dedup, so numerator and denominator describe the same year.

The existing queryAcademicSessions() → Convex academicSessions contract is consumed as-is — no change to its warehouse source, publication, scheduling, flag behavior, DTO, or cache.

## By layer

Worker / contracts

- New @bran/contracts/operation-capacity (runtime-free): buildOperationCapacityLookup (keeps only sessionType === "schoolYear" rows with studentCapacity > 0), resolveOperationCapacity, and operationFillRatePctFromSnapshot (reuses the existing enrollmentFillRatePct with yearStartTotal = firstDayEnrolled + pipelineDeposits).

- The refresh builds one program-code + school-year lookup from the already-loaded queryAcademicSessions() rows and threads it through runAdmissionsRefresh → runAdmissionsPerProgramSequence → refreshEnrollmentPipelineDetailed. Per derived snapshot year it resolves Operation Capacity and computes Operation Fill % after dedup, then publishes optional operationCapacity, operationCapacitySource ("queryAcademicSessions" or null), operationFillRatePct. Existing capacity kept compatibility-only.

- A warn fires if sessions loaded but the lookup is empty (surfaces a session_type value drift instead of silently blanking the report).

Convex read

- Schema enrollmentSnapshots + insertEnrollmentSnapshot gain the three optional fields.

- resolveEnrollmentData and the v2 aggregate return the worker-published operation fields verbatim (no recompute). The deprecated Rhodes capacity/fillRate are retained for the shared V1 rollup path.

v2 API — GET /v2/admissions/programs/{programId}/enrollments adds operationCapacity, operationCapacitySource, operationFillRatePct (response JSON schema + handler + agent-context dictionary). Existing capacity, capacityStatus, fillRatePct retain Site semantics and are marked deprecated; no operationCapacityStatus field.

UI — Matrix + mobile rename the column to Operation Capacity and show Operation Fill % from the published snapshot. The Rhodes Site-contributor tooltip is replaced with an academic-session/year lineage tooltip, and the Site-status inclusion controls are removed from this report. CSV export and sort follow the operation fields.

## Tests

Unit (contracts: year selection, zero/null/missing/non-schoolYear/summerCamp, case-insensitive match, fill-rate math), worker (two-year capacity selection, zero/missing omission, duplicate-contact dedup proving Fill % uses deduped counts), query (dashboard read returns published Fill % without recomputing), browser (mobile labeling + lineage tooltip + no Site controls), and API integration (operation fields present; deprecated v2 Site fields preserved and independent of Site resolution).

## Note for reviewers

The sessionType = "schoolYear" literal and bare-year school_year match the ticket's documented data contract (its Testing Notes name schoolYear and summerCamp; the in-repo fixture confirms bare-year school_year). The mart_education.aerie_academic_sessions mart lives outside this repo; worth a quick confirmation against live data before merge. The design is fail-closed (null, never wrong data) and now warns on drift.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Compute changed_files from the original diff, not the filtered diff. Excluded files remain in the existing changed-file list supplied to the reviewer.

- Keep patch filtering unchanged. No prompt, workflow, metadata, or configuration changes.

- Update existing tests to verify excluded patches stay out of the diff while their filenames remain visible.

## Validation

- Ruff lint and formatting checks passed.

- All 465 harness tests passed.

## Summary

- Expose plan_missing and plan_coverage_label on the Finance-facing Education current view.

- Qualify only BUs with actual operating activity and no operating Budget rows in the pinned 2025-Q3 plan vintage.

- Keep missing-plan actuals visible, force variance_pct to NULL, and preserve portfolio totals.

- Use a transactional DROP VIEW ... RESTRICT / CREATE VIEW migration because Redshift cannot replace a view with a changed column count; preserve the CQL_download_OM SELECT grant.

- Update the semantic contract, integration coverage, documentation, and handoff evidence.

## Validation

- 42 passed, 1 skipped

- Ruff check passed

- Ruff format check passed

- Pyright passed

- DDL dry-run passed

- Live read-only acceptance passed: exactly four plan-missing BUs, 480 qualified rows, null percentage variances, one snapshot, 12 periods, zero duplicate grain groups, and unchanged portfolio totals.

## Deployment note

The view migration has already been applied to the warehouse with owner transfer skipped; the existing sanket.ghia owner was retained. No stored-procedure rerun is required for this view-only change.

## Summary

- Preserve the existing edu_reader_user identity.

- Grant only USAGE on core_budgets and SELECT on core_budgets.consolidated_budgets_and_actuals.

- Add a read-back verification requiring both effective schema and table privileges.

## Evidence

A read-only klair_redshift check found:

- has_schema_privilege('edu_reader_user', 'core_budgets', 'USAGE') = false

- has_table_privilege('edu_reader_user', 'core_budgets.consolidated_budgets_and_actuals', 'SELECT') = true

- The corresponding full reader identity already has both privileges.

The requested access is to the shared table as-is. Broader cross-business-unit rows become readable; no Education row-level restriction is claimed or added.

## Scope

- Source-controlled migration only; no production DDL was executed.

- No credentials, users, keys, ownership, default privileges, or unrelated access changed.

- Existing SURTR-1302 migration WIP remains uncommitted and was not staged.

## Test plan

- pytest -q pipelines/ddl/tests/test_edu_reader_user_core_budgets_access.py — 2 passed

- git diff --check — passed

- Apply the SQL through the existing privileged warehouse DDL workflow, then confirm effective_select = true in the included verification query.

## Summary

This PR is the Sindri slice required by Aerie document-field reconciliation. It builds on the Workflow Instance, credential-binding and credential-lease infrastructure already merged through PR 152.

It adds generic Agent MCP authoring, resolves the single approved ${SERVICE_TOKEN} placeholder from an existing activation lease, hardens runner validation and redaction, and tightens the shared Quality Bar judge instructions.

Production effect: compatibility hardening. Existing Agents without authored MCP servers keep their current behaviour. Authored MCP configurations become available through the existing Agent create and update operations. The Quality Bar prompt and Claude judge effort changes apply to existing Claude Quality Bars after merge.

## Why

PR 152 can bind and lease a credential to a Workflow Instance, but an authored Agent could not use that lease in an authenticated MCP header. The runner needed a narrow bridge from the leased SERVICE_TOKEN to the Agent SDK without exposing arbitrary runner environment variables or returning authorization templates through public Agent reads.

The Quality Bar judge also needed explicit evidence boundaries so it would assess only the declared bar, output shape and submitted output rather than inventing hidden requirements.

## Business Value

- lets published Agents call authenticated MCP tools using existing Workflow Instance credential leases

- keeps service credentials out of Agent assets, public API responses, traces and persisted run output

- fails malformed or unsafe MCP configuration before it reaches the Agent SDK

- gives failed Agents concrete, bounded Quality Bar feedback

- preserves Sindri as a generic Workflow platform with no Aerie-specific field policy

## How does it work

1. Existing Agent create and update operations accept optional MCP server maps under each harness configuration. Each server contains a URL and optional string-valued HTTP headers.

2. The control-plane JSON Schema validator supports schema-valued additionalProperties, allowing dynamic server and header names while validating every value. Public Agent responses continue to omit MCP authorization configuration.

3. PR 152's existing credential lease places the Instance-bound service token in the activation environment as SERVICE_TOKEN.

4. Immediately before invoking the Agent SDK, the runner replaces one ${SERVICE_TOKEN} placeholder in an authored static header. The stored immutable Agent version is not mutated.

5. The runner validates MCP object shape, URL presence, HTTPS before dynamic-secret access, HTTP header syntax, case-insensitive collisions, placeholder syntax and the resolved value. Invalid configuration fails closed.

6. SDK and network errors are redacted before they are returned or emitted as progress.

7. The shared Quality Bar prompt limits judgment to declared evidence and requests concrete reasons of at most 1,000 characters. The Claude judge uses low reasoning effort; the Pi judge is unchanged.

## Scope

### Included in this phase

- MCP server and header fields in existing Agent authoring contracts

- dynamic-record validation in the control-plane JSON Schema implementation

- OpenAPI request-schema updates

- runtime ${SERVICE_TOKEN} materialisation from the existing activation environment

- MCP URL, header and placeholder validation

- returned runner-error redaction

- evidence-bounded Quality Bar instructions and Claude judge effort

- focused regression coverage

- Exact final diff paths:

agent-runner/__tests__/qc-evaluate.test.ts
agent-runner/__tests__/run-agent.test.ts
agent-runner/src/qc-evaluate.ts
agent-runner/src/run-agent.ts
agent-runner/src/types.ts
convex/__tests__/controlPlaneAuthoring.test.ts
convex/__tests__/controlPlaneEdge.test.ts
convex/__tests__/jsonSchema.test.ts
convex/__tests__/openapi.test.ts
convex/controlPlaneAuthoring.ts
convex/controlPlaneContracts.ts
convex/lib/controlPlaneHttpRoutes.ts
convex/lib/jsonSchema.ts
docs/openapi/control-plane.json

### Deliberately excluded for later phases

- Workflow Instances, readiness, credential bindings, credential leases, run creation and activation reporting — already provided by PR 152 and current main

- new Convex tables or migrations — none are required

- Sindri UI changes — authoring uses the existing control-plane operations

- Aerie field policy, reconciliation assets, validation or writes — owned by Aerie

- arbitrary runner environment-variable authoring — unsupported by design

- per-Agent Quality Bar judge effort — remains a separate platform decision

- deployment resources, development configuration and environment files — none are included

## Test plan

### Automated validation

- control-plane authoring, edge, JSON Schema and OpenAPI suites — 115/115 passed (./node_modules/.bin/vitest run convex/__tests__/controlPlaneAuthoring.test.ts convex/__tests__/controlPlaneEdge.test.ts convex/__tests__/jsonSchema.test.ts convex/__tests__/openapi.test.ts)

- Agent runner and Quality Bar suites — 44/44 passed (cd agent-runner && ./node_modules/.bin/vitest run __tests__/run-agent.test.ts __tests__/qc-evaluate.test.ts)

- root typecheck — passed (./node_modules/.bin/tsc --noEmit)

- Agent runner typecheck — passed (cd agent-runner && ./node_modules/.bin/tsc --noEmit)

- focused Biome check — passed (./node_modules/.bin/biome check on all 13 changed TypeScript files)

- git diff --check origin/main...HEAD — passed

- exact-head diff scope — 14 paths, exactly those listed above

- development-resource audit — no environment files, deployment identifiers, URLs, Site IDs, run IDs, logs or state artifacts in the diff

### Time for Implementation

An engineer working without AI assistance would likely need 4 to 6 engineering days to understand the PR 152 lease boundary, design the safe authoring contract, implement runner materialisation and validation, update OpenAPI, add adversarial tests, rebase and complete end-to-end validation.

### Manual QC

The exact code was exercised through a live two-Site development E2E using a pinned Workflow Instance, real activation credential leases and authenticated MCP calls. Both target Workflows completed all 3 Agent Quality Bars and Aerie accepted their final proposals. A separate failed run proved that an unavailable proposal validator blocks the final Agent rather than emitting an unvalidated proposal. No Quality Bar timeout, criterion or attempt limit was weakened during QC.

## Summary

- Track AI-Builder-Team/mercy main for both the reusable workflow and review harness, matching the maintainer's explicit policy to consume Mercy updates automatically.

- Fix workflow validation: the previous v1 revision does not declare the already-forwarded BRAINTRUST_API_KEY; Mercy main does. Keep the existing Braintrust integration.

- Mirror Sindri's .ignore paths in .mercy.yml exclude_paths: generated OpenAPI, skill reference copies, lockfiles, Convex generated stubs, vendored libraries, and public assets. Mercy does not load .ignore automatically; its built-in protected-path overrides still apply.

## Trust model and intended update policy

- This PR does not add secret access or publish credentials. The existing caller already forwards the same Anthropic, Codex, GitHub App, telemetry, and Braintrust secrets to the same organization-owned Mercy repository. The secret list and caller permissions are unchanged.

- Following Mercy main is deliberate. Sindri's maintainer wants the current central review implementation without a separate release-tag promotion or consumer pin update. Replacing main with a SHA would implement a different update policy, not fix an accidental deviation in this change.

- The previous reference was not an immutable pin. Mercy documents v1 as a moving major tag. This changes when upstream updates are adopted; it does not introduce execution of a previously untrusted repository or introduce secret forwarding.

- Residual risk is acknowledged, not denied. Malicious code accepted into Mercy main could misuse the credentials supplied to its workflow. Tracking main intentionally trusts that upstream branch and its maintainers. This PR does not claim branch protections were audited or that mutable references are risk-free. Assess concrete new exposure in this diff separately from a general preference for immutable action pins; the latter is a broader policy decision, not evidence of credential leakage here.

## Verification

- Checked all forwarded secrets and inputs against Mercy main's reusable-workflow declarations.

- Exercised Mercy main's actual diff filter against all seven excluded path categories and verified that protected paths and application code remain included.

- Lint, Convex-reference checks, both typechecks, and 1,088 tests passed.

Mercy reads .mercy.yml from the default branch, so the exclusions take effect after merge.

## Summary

- Schedule brokerage trade confirmations hourly at minute 12 UTC and enable the schedule.

- Schedule the SpaceX workbook raw sync at 02:15 and 14:15 UTC and enable the schedule.

- Keep the SpaceX projection refresh event-driven.

- Update schedule documentation and manifest contract tests.

## Validation

- Brokerage runner: 78 tests passed.

- SpaceX raw-sync runner: 31 tests passed.

- JSON parsing and git diff checks passed.

- CDK manifest test was not runnable locally because the checkout has no installed Jest dependency; CI should provide the full validation.

## Summary

- Count newly published SPCX SELL confirmations during brokerage ingestion.

- Trigger the SpaceX projection on brokerage completion and guard zero-new-trade runs as no-ops.

- Use the brokerage run as the cumulative Trades boundary and the latest complete workbook publication.

- Add design/implementation documentation and regression coverage.

## Verification

- Brokerage runner: 78 tests passed

- SpaceX projection runner: 73 tests passed

- Ruff lint and formatting passed

- Relevant CDK tests: 693 passed

- CDK TypeScript build passed

The full CDK suite has existing Docker-dependent failures locally because the Docker daemon is unavailable; 867 other CDK tests passed.

## Summary

Use the canonical HubSpot admissions fact to calculate historical school P&L enrollment divisors. Record the source on each populated divisor and avoid waiting on the HubSpot publisher during the financial-mart refresh.

This addresses the per-student denominator portion of CFO Question 20. It does not alter QuickBooks rent, school mappings, or Finance-owned GGE postings.

### Changes

- pipelines/runners/mart-aerie-education-financials-refresh/ddl/migrate_add_enrollment_divisor_source.sql *(new)* — adds the nullable divisor-lineage column to the existing populated mart.

- pipelines/runners/mart-aerie-education-financials-refresh/ddl/agg_school_pl_breakdown.sql — declares the lineage column for fresh installs and documents the display threshold.

- pipelines/runners/mart-aerie-education-financials-refresh/ddl/sp_refresh_agg_school_pl_breakdown.sql — snapshots and validates one HubSpot publication, calculates school-year-aware divisors by canonical school_id, preserves the divisor/source below five students, and leaves only the derived ratio null below that threshold.

- pipelines/runners/mart-aerie-education-financials-refresh/src/handler.py — reports failures against the new source and keys.

- pipelines/runners/mart-aerie-education-financials-refresh/scripts/validate_tieout.py and tests — independently validate the source, divisor, and ratio contract.

### Design decisions

- A temporary snapshot of core_education.fct_admissions_deal replaces the explicit source-table lock. It reads either the previous or next atomic HubSpot publication, validates its lineage, and avoids exhausting the mart Lambda's execution window while the producer is active.

- The denominator remains visible for one to four students, with source lineage; per_student is null because a ratio at that population is not meaningful.

## Business value

The CFO Q20 rent-by-student answer now uses the declared historical enrollment source at the same canonical-school grain as the P&L mart, instead of fragile legacy program-name matching. Consumers can audit both each divisor and its provenance.

## Estimated manual effort

One day.

## Test Plan

- [x] uv run pytest — 137 passed

- [x] uv run ruff format --check .

- [x] uv run ruff check .

- [x] Production pre-merge validation: refreshed the school P&L mart in 31.79 seconds and ran the independent Alpha Miami tie-out successfully.

- [x] Live API CFO-style query confirmed the refreshed Q20 data is readable from mart_education.agg_school_pl_breakdown.

- [ ] Reviewer: verify the migration is applied before the revised procedure in the target environment.

## Summary

- Add sanitized, immutable Rhombus raw ingestion for 30 source datasets

- Add source-controlled staging DDL, exact-manifest replay, and atomic ingestion-ledger lineage

- Enable concurrency-bounded, staggered five-minute, fifteen-minute, hourly, and daily schedules

## Why

Rhombus security, access, alarm, identity, camera uptime, and device data needs a source-faithful warehouse landing before DSS models can be built. The pipeline now has the production secret and warehouse objects it needs, and the exact code path has been validated against the live API and finance_dw.

The enabled schedules are staggered, reserved concurrency is three, and all event and uptime reads use bounded one-hour windows. Merge and deployment will activate scheduled ingestion; DSS consumer models remain separate work.

## Business Value

This creates durable raw evidence for the requested DSS security and operational slices, including exact camera downtime windows, without returning to the source API for every downstream question.

## Test plan

- [x] Repository-wide Ruff check and format validation

- [x] 33 runner tests

- [x] TypeScript build, 31 focused construct tests, and 872 full CDK tests

- [x] DDL dry-run and live catalog/ownership verification

- [x] Final full live capture: 222 responses, 30 datasets, 5,251 source and published rows

- [x] Exact-manifest replay without an API key reproduced all 5,251 rows with no duplicates

- [x] Readback: raw totals match ledger; the count of four not-configured scopes is queryable and exact identities remain in immutable manifest evidence

- [x] Readback: no work tables, temporary COPY objects, or excluded credential/media keys remain

- [x] CI and Mercy review on the final PR head

## Summary

- Serve the approved backend-backed SpaceX V2 page at /spacex-valuation.

- Redirect /spacex-valuation-v2 while preserving search/hash values and the existing page permission.

- Remove the legacy V3 entry point, preserve analytics continuity, and refresh current-state lineage documentation.

- No backend authorization or API contract changes.

## Verification

- Full frontend suite: 670 files, 6,891 tests passed, 16 skipped.

- Focused route/analytics/page tests: 64/64 passed.

- Focused backend snapshot tests: 2/2 passed.

- pnpm lint:pr, changed-file Prettier, TypeScript project check, and production build passed.

- Local frontend/backend HTTP health checks returned 200.

Browser UI smoke was unavailable because the local browser connector reported unsupported Codex auth method: apikey; route behavior is covered by the route tests.

## Summary

- consume the complete canonical SPCX SELL Trades set up to a deterministic (loaded_at, confirmation_record_id) boundary

- persist Trades boundary timestamp, confirmation ID, and bounded row count in projection lineage

- apply the same bounded source contract in staging publication and the Core refresh procedure

- add the forward migration, design/implementation documentation, and regression coverage

## Verification

- 67 Workbook projection tests passed locally

- Ruff and formatting checks passed

- local cumulative dry run and controlled publication passed with Core-to-source validation

## Summary

- forward fully processed brokerage emails to Sanket, Ludel, and David

- update the pipeline contract documentation and manifest assertion

## Verification

- brokerage pipeline test suite: 78 passed

- Ruff check passed

- Ruff format check passed

- git diff --check passed

## Summary

- retain an append-only, aggregate-only admissions funnel population observation rail

- pin each publication to accepted clean/raw Contacts run, manifest checksum, and source counters

- classify scope/delta evidence without inventing a Finance cohort or deletion policy

- fail closed on missing/mixed lineage, invalid runner identity, legacy writer use, or corrupt duplicate state

- add same-run recovery after a committed-but-unreturned call response

## Safe rollout

The ordered owned applier applies: legacy 3-arg fail-closed guard → observation rail → 4-arg runner-identified writer. It rejects individual/out-of-order SURTR-1362 DDL applies. Catalog evidence verifies exact overload signatures, bodies, owner and explicit private ACLs, plus table ownership/ACLs.

## Validation

- 39 focused tests passed

- Ruff passed

- git diff --check passed

- independently reviewed through all migration, ACL, lineage, concurrency, and recovery corrections

## Business boundary

The rail preserves evidence only. Finance/CRM must still approve cohort, deletion, backfill, and materiality policy before Q60–Q62 may be Green.

## Summary

- Revert #1368's deployment-blocking storage/schema cleanup while retaining the January 31 Forecast V2 behavior from #1366

- Restore temporary compatibility for legacy January 1 Forecast V2 rows during the staged production transition

- Keep strict current-model publication validation, reader gating, and truthful legacy-column deprecation docs

## Why

PR #1368 requires #1366 to be deployed and verified before its strict Convex schema can safely replace the transitional dual-shape schema. Both changes entered the same release candidate. Production still runs the pre-#1366 worker, and CD deploys Convex before the replacement analytics worker can publish the new model and self-prune legacy rows. Shipping both together can therefore fail at convex deploy when existing legacy documents are validated.

This PR restores the intended widen-publish-narrow sequence. It selectively retains #1368's independent write-boundary model-version guard and warehouse deprecation documentation. After #1366 deploys, the new worker publishes aerie_milestone_v2, the active publication is reconciled, and all legacy/orphan rows are confirmed absent, the strict storage cleanup can return in a separate follow-up PR.

## Business Value

Keeps the release deployable without changing the January 31 forecast outcome, and preserves a fail-closed, observable path for removing the legacy representation after production data is ready.

## Test plan

- [x] Focused diff audit: only #1368's storage/schema cleanup is reverted; strict new-publication validation and warehouse deprecation docs remain

- [x] Convex Forecast V2 tests: 39 passed

- [x] Shared Forecast V2 contract tests: 33 passed

- [x] Analytics Forecast V2 reader tests: 21 passed

- [x] Chat, contracts, and sync typechecks

- [x] Architecture boundaries and test-architecture checks

- [x] Changed-file Biome check and dbt schema YAML parse

- [x] Seven-lane adversarial review; all confirmed findings resolved

- [ ] Deploy #1366-compatible release and verify one complete aerie_milestone_v2 publication

- [ ] Confirm no legacy or orphan Forecast V2 row remains before reapplying the strict storage cleanup

## Summary

- Apply the existing deterministic AWS name compaction to named additional schedules for Lambda and ECS pipelines.

- Add regression coverage for long schedule names and the EventBridge 64-character limit.

## Why

The production deployment failed during CDK synthesis because the Marauders Map additional schedule generated a 75-character EventBridge rule name. This prevents all stacks, including the Person v0 rollout, from deploying.

## Business Value

Production releases can synthesize and deploy pipelines with descriptive additional schedule names without violating AWS resource-name limits.

## Test plan

- [x] npm test -- --runInBand test/constructs/pipeline.test.ts test/constructs/ecs-pipeline.test.ts (65 tests)

- [x] npx cdk synth --all -c env=prod

## Summary

- add nullable canonical Program/School IDs and resolution reasons to mart_education.aerie_deals

- project those values directly from core_education.fct_admissions_deal

- preserve legacy display-name fields for compatibility; introduce no inferred alias mapping

- provide a controlled, atomic DDL applicator and scheduled-run schema guard

## Deployment safety

The applicator fails closed on absent/inaccessible targets, partial/wrong/non-nullable column shapes, unverified batch receipt, and unknown Data API outcome. It validates remote statement name/target/ordered SQL digest on both apply and recovery, writes no receipt until postflight succeeds, and does not invoke a refresh.

## Validation

- full declared-dependency suite: 134 passed

- Ruff and git diff --check passed

- independently reviewed through schema/preflight/receipt/recovery corrections

## Scope

This is an additive identity-propagation slice. It does not choose ambiguous School equivalences, modify existing name-based consumers, or deploy/run production DDL.

## Summary

- Add current DRI display names and account emails to the Portfolio People response

- Preserve stable user references and existing assignment write fields for compatibility

- Keep directory-wide profile and administrative metadata behind the existing directory capability

## Why

Portfolio readers could confirm that a DRI was assigned but received only an opaque user reference. Resolving that reference required the broader admin user-directory capability, even when the caller only needed to identify and contact the coworker assigned to the site.

## Business Value

Authorized Portfolio consumers can now identify and contact each assigned DRI directly from the site People response without receiving broader directory access.

## Test plan

- [x] Focused Site People HTTP and contract tests

- [x] OpenAPI and Agent Context contract tests

- [x] Chat and shared-contract typechecks

- [x] Biome and repository architecture checks

## Summary

- Treat a NULL HubSpot association archive flag as active in the native guardian view while excluding unready publications

- Add local and dev Redshift regression coverage for the source contract

## Why

The Person V0 production cutover showed that all native student-guardian associations disappeared from the new reporting view. HubSpot uses NULL as an active archive default for these rows, but the view used NOT source_archived, which excludes NULL in SQL. This left the Summer Experience forecast arm empty and correctly blocked the transactional cutover. The view now also fails closed when the association publication is not ready.

## Business Value

Preserves native student-guardian relationships through the Person V0 cutover so dependent admissions and forecast models retain their existing relationship coverage.

## Test plan

- [x] Person directory test suite: 33 passed

- [x] Dev Redshift reporting validation passed with no permanent objects created

- [x] Production candidate diagnostic reproduced 0 rows before this fix

## Summary

- add a read-only, source-lineaged revenue-per-campus reconciliation packet

- retain canonical P&L source/Core/mart lineage

- expose unmapped, no-policy, invalid-policy, and denominator exceptions

- fail closed: no campus ratio is ready unless the entire selected packet is coherent

## Why

CFO Q56–Q58 require an auditable revenue/denominator result. The existing canonical P&L already carries identity and lineage; the missing item is a safe reconciliation packet, not a mart rebuild. Finance must still approve numerator, denominator, and TEFA/central/shared disposition.

## Safety

- canonical school_id, no display-name identity

- no zero filling or inferred allocations

- read-only SQL only

- a single exception anywhere makes every ratio not_ready_packet

## Validation

- focused contract suite: 7 passed

- full runner suite: 141 passed

- focused ruff passed

- git diff --check passed

- independently reviewed through three corrective rounds

## Tracker exit

After live execution, Q56–Q58 become Green only with approved Finance policy and zero unresolved exceptions; otherwise they move to Pending Finance.

## Summary

- retain NetSuite Type as record_type in the read-only GL reconciliation

- scope source/result/CSV aggregation by record type

- prevent bare transaction/document numbers from acting as global identifiers

- add regression coverage for distinct records sharing 1692914

## Why

staging_netsuite.gl_transactions_mapped exposed a bare transaction number without record type. A 2026 posting journal entry and a 2024 non-posting revenue arrangement share 1692914; audit output must keep them distinct.

## Validation

- uv run --extra dev pytest tests/ — 31 passed

- focused regression: 5 passed

- uvx ruff check --select E,F scripts/reconcile_all_transactions.py tests/test_reconcile_script.py

- git diff --check

- independent review found and verified the correction of a synthetic all-record-types reconciliation defect

## Scope

Read-only reconciliation command/output only. No database, S3, runner, schedule, or production configuration change.

Depends on #1364.

Closes #1365.

## Summary

Destructive-cleanup follow-up to #1364. Retires the legacy January-1 (aerie_milestone_v1) Forecast V2 field family and the transitional dual-shape compatibility #1364 deliberately kept, narrowing to the single supported January-31 shape. This is representation cleanup only — the session_3 internal key, every January-31 field, and every number (Jan Forecast, Pipeline Additions, card subtotals, Finance) are unchanged from #1364.

> Merge is gated on #1364 being deployed AND verified in production. #1364 is merged to main, but app/worker CD only deploys on push to production, so production still runs the OLD worker and the active Convex Forecast V2 publication is still the LEGACY shape (legacy docs at rest). The Convex schema narrowing here (by design) will NOT deploy while legacy docs remain — that is the intended fail-closed guardrail, not a bug. Do not merge until #1364 is promoted to production and its first new-model publication has self-pruned the legacy run.

## Changes by layer

- Analytics worker (sync/src/redshift/admissions-forecast.ts): no legacy Jan-1 field selection/mapping/dual-write existed after #1364; comment updated to document the DBT-retention exception. Strict fail-closed validation of every required January-31 field is retained.

- Shared contract (packages/contracts/src/admissions-forecast-v2.ts): already the January-31 shape after #1364; header + FORECAST_V2_MODEL_VERSION docs updated to state enforcement now lives in the publish mutation and the legacy group is retired.

- HTTP publish validation (chat/convex/admissions/analytics/forecastV2Validators.ts + forecastV2.ts): removed the forecastV2Session3LegacyValidator and its type; the publish mutation now requires modelVersion === aerie_milestone_v2 on every row, so a legacy-only OR mixed legacy/current payload is rejected (the strict session3 object validator already rejects the legacy field shape at arg validation). Pointer never advances on rejection (fail closed).

- Convex table schema (chat/convex/admissions/schema.ts + validators): forecastV2StoredRowValidator is now the strict published-row shape (legacy session3 union removed); admissionsForecastV2Rows requires the current shape. This narrowing deploys cleanly only once no legacy document remains at rest.

- Dashboard reader (chat/convex/admissions/dashboards/forecastV2.ts): removed the legacy model-version gate and the new/legacy session3 discriminator (isNewModelSession3). The completeness gate (non-empty snapshot whose fetched row count matches the publication metadata) is retained.

- DBT (dbt/models/marts/admissions/_mart_admissions__models.yml): see exception below.

- Tests (chat/convex/admissions/forecastV2.test.ts): added rejection coverage; see below.

## DBT-column-retention exception

The ticket requires external warehouse-owner confirmation before physically dropping the legacy Redshift columns, which cannot be obtained autonomously (a repository search cannot prove external safety). Per the ticket's explicit fallback, the legacy Jan-1 columns are NOT dropped. Instead:

- All code-side legacy (worker/contract/HTTP/Convex/reader) is removed.

- The legacy Jan-1 columns (session_3_future_enrollments_before_january_1, session_3_future_enrollments, session_3_withdrawals_before_january_1, session_3_withdrawals_on_or_after_january_1, session_3_transfers_before_january_1, session_3_transfers_on_or_after_january_1, session_3_roster_base, session_3_target_date, session_3_forecast_enrollment, session_3_headline_enrollment) are retained in the mart SQL and documented DEPRECATED (#1365) in the model yml, each naming its current-shape replacement and noting no Aerie consumer.

- The mart/intermediate SQL and the legacy data tests are unchanged so the retained columns keep reconciling. All source facts the new January calc needs are kept. session_3_forecast_status is shared (still consumed) and is correctly NOT deprecated.

A follow-up ticket can drop the columns once the warehouse owner confirms no external DBT/Redshift consumer depends on them.

## Repository-wide search — no remaining runtime consumer of legacy fields

$ grep -rnE "futureEnrollmentsBeforeJan1|withdrawalsBeforeJan1|withdrawalsOnOrAfterJan1|transfersBeforeJan1|transfersOnOrAfterJan1|forecastV2Session3LegacyValidator|ForecastV2Session3LegacyStored|isNewModelSession3|aerie_milestone_v1" \
--include="*.ts" --include="*.tsx" . | grep -v node_modules | grep -v '\.test\.ts'
# (no output — zero runtime consumers)

The only surviving references to the legacy field names are in forecastV2.test.ts's rejection factory (legacySession3), which exists solely to assert the legacy shape is now REJECTED. The remaining session_3_january_roster_base matches are the NEW January-31 column, not legacy.

## Preconditions evidence

Code-side preconditions (satisfied by this PR):

| Precondition | Status | Evidence |

| --- | --- | --- |

| No remaining runtime consumer of the legacy fields | MET | grep above returns zero non-test hits |

| No deployed worker code can publish the legacy payload | MET (code-side) | worker selects/maps only January-31 columns; contract describes only the January-31 shape |

| Shared contract requires only the current January-31 group | MET | packages/contracts/src/admissions-forecast-v2.ts (ForecastV2Session3 has no legacy fields) |

| Publish endpoint rejects legacy-only and mixed payloads | MET | strict session3 validator + modelVersion === aerie_milestone_v2 check in forecastV2.ts; tests assert 500/reject with no pointer advance |

| Convex storage requires the current shape (no legacy union/optional aliases) | MET (code-side) | forecastV2StoredRowValidator = strict published-row validator; schema narrowed |

| Dashboard reader has no legacy model-version branch/fallback | MET | gate + isNewModelSession3 removed from dashboards/forecastV2.ts |

| Stable session_3 internal key unchanged | MET | key retained everywhere |

| Jan Forecast / Pipeline Additions / subtotals / Finance / labels unchanged | MET | representation-only change; contract helpers + reconciliation/report tests unchanged and green |

| Existing atomicity / self-pruning tests still pass | MET | forecastV2.test.ts 41/41 pass |

| Tests prove a valid current payload publishes and legacy is rejected | MET | new + existing tests |

Deployment / data-state preconditions (NOT-YET-VERIFIED — #1364 is not yet promoted to production; merge is gated on this):

| Precondition | Status |

| --- | --- |

| Active Forecast V2 publication model version is aerie_milestone_v2 | NOT-YET-VERIFIED — production still runs the OLD worker; active publication is still the legacy shape |

| Active publication contains the expected number of schools + all required January operands | NOT-YET-VERIFIED |

| The previous legacy publication was deleted by the successful publication transaction (self-prune) | NOT-YET-VERIFIED — no new-model run has occurred in production |

| No in-flight or deployed old analytics worker can publish the legacy payload | NOT-YET-VERIFIED — old worker still deployed in production |

| No legacy document remains at rest (required for the Convex schema narrowing to deploy) | NOT-YET-VERIFIED — the schema narrowing WILL fail to deploy until this holds, by design |

| Forecast V2 and Finance Forecast reconcile for representative schools post-deploy | NOT-YET-VERIFIED |

| Warehouse owner confirms no external DBT/Redshift consumer depends on legacy columns | NOT OBTAINABLE autonomously → DBT-column-retention fallback applied (see above) |

No production data was deleted or mutated to force validation.

## Rollback

Rollback target is the #1364 functional January release (not the pre-January implementation), since this cleanup removes legacy acceptance. If the schema narrowing fails to deploy because a legacy document still exists, stop and investigate the publication state — do not delete data manually to force schema validation.

## Verification (local)

- pnpm typecheck — green across all workspaces

- pnpm biome check (changed files) — clean

- pnpm lint:boundaries, pnpm lint:test-architecture — green

- chat forecastV2.test.ts — 41/41 pass; sync forecast reader + refresh tests — 52/52 pass

- dbt yml validated as well-formed YAML (all 10 legacy columns marked DEPRECATED); dbt parse not run locally (dbt not installed in this environment) — the dbt change is documentation-only column descriptions with no structural/test change

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Add source-faithful ingestion for all nine Marauder's Map DSS datasets

- Preserve every HTTP response attempt and complete manifests in immutable S3 before atomic Redshift publication

- Add bounded retries and workloads, provenance-fenced replay, canonical deployment DDL, and disabled rollout controls

## Why

Marauder's Map data currently has no governed Surtr ingestion boundary. This adds the raw evidence and lineage layer needed to validate the source safely before any Core, mart, or consumer contract is introduced. The pre-review hardening also removes ambiguous Redshift timeout outcomes and keeps manual and scheduled execution unavailable until activation is approved.

## Business Value

The warehouse can retain and replay auditable school, camera, incident, presence, attention, utilization, and risk-signal observations without treating source judgements as governed truth. This creates a safe foundation for later consumer design and operational scheduling while preserving a complete forensic trail for retries and partial captures.

## Test plan

- [x] 43 runner tests pass; Ruff lint and format checks pass

- [x] DDL defaults to a non-mutating dry-run and renders successfully

- [x] 867 CDK tests pass with Docker bundling; TypeScript build passes

- [x] Live full extraction published 181 reconciled rows across all nine datasets

- [x] Local and deployed manifest replay remained idempotent under repeated delivery

- [x] All EventBridge schedules and on-demand execution remain disabled

## Incident

Fresh controlled run 5ee28e83-672b-47dd-93d9-0e257f232d5f executed exactly once against immutable Lambda version 3. It completed source collection and failed closed before publication at assert_publication_identity_available().

Lambda log request e4f456cd-713f-4457-905b-d9a0e5828619 shows RuntimeError: publication identity lookup returned no trustworthy counts.

Durable recovery is clean: zero matching ingestion_ledger rows and zero matching publication_attempts rows. No retry will occur.

## Root cause and fix

The Redshift connector returned valid [0, 0] counts from fetchone(), but the guard accepted only tuple containers, then compared directly to (0, 0).

Accept only the standard DB-API tuple or list containers, retain exact length/non-boolean/non-negative integer validation, and compare the two validated values directly. Every malformed or duplicate identity remains fail-closed.

## Validation

- pytest -q tests/test_redshift_handler.py — passed

- Ruff check and formatting — passed

- Regression test covers valid list [0, 0].

No schedule, data, deployment configuration, or publication changes are included.

## Summary

- normalize Alpha Houston's incorrect SIS Finalsite tenant from houston-alpha to houston-heights-alpha

- keep the correction at the shared school-identity boundary until SIS source data is repaired

- add a regression test for the resolved Houston tenant

## Validation

- verified houston-heights-alpha.fsenrollment.com serves the Alpha Houston Heights portal

- checked all 55 active physical SIS campus slugs; 53 resolve, with Houston and the pre-existing Tampa mapping returning 404

- confirmed the normalization against live Redshift source data

- git diff --check

## Notes

- Alpha Tampa remains unchanged by request

- local dbt compile was unavailable because the bran_dbt profile is not configured on this workstation

## Scope

Repair a duplicate source-controlled minimum-budget configuration block accidentally included in #1927's squash commit.

The duplicate has identical values and is harmless at runtime, but removing it restores a single source of truth and allows the intended production release to carry only the reviewed no-retry Lambda client configuration plus its test.

## Validation

- pytest -q tests/test_invoke_controlled.py

- Ruff check and formatting

- Pyright: 0 errors

No production action, Lambda invocation, publication, or schedule activation occurs in this PR.

Closes #1364.

## Summary

Revises Admissions Forecast V2 from a Session 3 / January 1 model to a business-facing January forecast that counts activity through January 31. Every layer agrees on the same populations and arithmetic:

New Sep-Jan       = confirmed starts after today and on or before Jan 31 (excl. On Campus)
January roster    = On Campus + New Sep-Jan − withdrawals through Jan 31 − transfers through Jan 31
Pipeline Additions = Active Applications forecast + Community Commitments forecast
Jan Forecast      = January roster base + Pipeline Additions

Jan 31 starts/exits are included; Feb 1 and later are excluded. A paid deposit is counted once at 100% and never also probability-weighted.

The executive table now shows School · On Campus · New Sep-Jan · Pipeline Additions · Jan Forecast · Finance Forecast (year prefix generated dynamically; Start Year and next-year columns removed). The operational tab and heading read YYYY/YY January while session_3 stays the internal analytics/routing key. The sibling card is renamed Pipeline Additions with Active Applications and Community Commitments subsections, each with a subtotal and a card total that reconciles exactly to the executive Pipeline Additions cell. The incumbent Forecast report is untouched.

## Changes by layer

Warehouse (DBT) — feat(dbt): add January 31 forecast fields

- dbt/models/intermediate/admissions/int_admissions_forecast.sql — parallel January-31 partitions (New Sep-Jan / after-Jan-31 starts, through/after-Jan-31 withdrawals & transfers), session_3_january_roster_base, session_3_pipeline_additions, session_3_january_target_date, session_3_january_forecast_enrollment / _headline_enrollment. Legacy Jan-1 columns retained for cleanup ticket #1365.

- dbt/models/marts/admissions/mart_admissions_forecast.sql — passes the new columns through; model_version advanced to aerie_milestone_v2.

- dbt/models/**/_*.yml — new column docs.

- Tests: assert_forecast_january_reconciles.sql, assert_forecast_january_boundary.sql (Jan-31 inclusion / Feb-1 exclusion via an independent cohort re-derivation), assert_forecast_january_on_campus_no_overlap.sql. Deposit de-dup and Pipeline = Deposits + No Deposits stay covered by the existing session_3 tests.

Shared contracts — feat(forecast): publish January forecast shape

- packages/contracts/src/admissions-forecast-v2.ts (+ test) — the session_3 group becomes the January-31 shape; FORECAST_V2_MODEL_VERSION = aerie_milestone_v2; new executive columns + exact tooltips; planning focus → Jan Forecast; session_3 tab label → January; the reconciling forecastV2PipelineAdditionsBreakdown / forecastV2PipelineAdditionsCard helpers.

Convex — feat(forecast): publish January forecast shape

- chat/convex/admissions/analytics/forecastV2Validators.ts — strict new-model publish validator + a tolerant stored-row validator whose session3 accepts both the new and legacy shapes, so documents at rest keep validating until the first new-model publication self-prunes them.

- chat/convex/admissions/schema.ts — admissionsForecastV2Rows uses the tolerant validator.

- chat/convex/admissions/analytics/forecastV2.ts — publish finite-guards the January operands.

- chat/convex/admissions/dashboards/forecastV2.ts — reader gates to a complete active new-model publication (else unavailable/loading), narrows the stored union, no cross-generation fallback; atomic pointer + self-prune preserved.

- chat/convex/admissions/forecastV2.test.ts — legacy-at-rest tolerance + reader new-model gate coverage.

Analytics worker — feat(forecast): consume the January mart columns in the worker

- sync/src/redshift/admissions-forecast.ts — reads the new January columns, builds the new shape, publishes aerie_milestone_v2. Finance uses the revised januaryRosterBase (already excludes Feb+ starts). Fail-closed on any required January operand that is absent/malformed on a live row (mirrors the Finance guard).

UI — feat(forecast): present January and Pipeline Additions

- chat/components/dashboards/admissions/forecast/v2/forecast-v2-tabs.tsx (+ report test) — January arithmetic card order and the two-subsection Pipeline Additions card. The executive table/footer/sort/mobile are contract-driven and needed no structural change.

## Rollout order

A short Forecast V2 interruption (up to one refresh cycle) is expected and accepted. The incumbent Forecast report is unaffected throughout.

1. Merge and deploy the application code. Convex tolerates both the legacy rows still at rest and the new shape; the reader shows Forecast V2 as unavailable/loading while the active publication is still the legacy generation.

2. DBT build the new mart columns — run the dbt job so mart_admissions_forecast materializes the January-31 columns and model_version = aerie_milestone_v2. The updated worker cannot publish until these exist (it fails closed and preserves the last known-good run).

3. Restart the analytics worker (worker TypeScript does not hot-reload).

4. One refresh publishes the advanced model version — the first successful new-model publication atomically advances the pointer, prunes the previous run, and Forecast V2 renders the new table. Confirm the expected school count and reconcile representative rows.

5. Only then begin the legacy cleanup ticket #1365.

## Rollback limitation

Before the first successful new-model publication, rolling back application code restores the old active publication. After the new publication self-prunes the old run, rollback requires redeploying the legacy-compatible code and running a legacy worker refresh to repopulate a legacy-shaped publication — a plain code rollback alone would leave the reader with no compatible active run.

## Verification

- Type checking, biome, and tests are green for the changed code (pnpm typecheck, pnpm biome check, contracts/sync/chat forecast suites).

- DBT dbt parse validates the models/tests/DAG locally; a full dbt build against Redshift was not run from this environment (no AWS credentials here) — the dbt CI job runs it on the PR.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Production-control defect

The synchronous controlled invocation used boto3 defaults: a ~60-second read timeout and automatic retries. Because the Lambda normally runs for minutes, a caller read timeout caused the SDK to replay the non-idempotent request five times. Those overlapping collection attempts encountered Alpha API 429 RATE_LIMITED failures. No durable publication occurred.

## Fix

Configure only the synchronous Lambda client with:

- connect_timeout=10

- read_timeout=900 (the Lambda duration envelope)

- retries={"max_attempts": 0} (exactly one request)

The token-bearing ClientContext, exact controlled event, qualified immutable version, and existing same-run durable recovery checks are unchanged.

## Validation

- focused invoke helper suite passed

- complete Alpha runner pytest passed

- Ruff and format passed

- Pyright: 0 errors

- independent review: SAFE

The production schedule remains disabled. This PR neither invokes nor publishes data.

## Summary

- Enable accepted SIS organization and projection events with scoped EventBridge publish access

- Activate enrollment, school-year, retention, and SIS directory consumers while keeping on-demand execution held

- Add exact-parent projection redelivery and source-specific gates while excluding unrelated Finalsite and QuickBooks triggers

## Why

The AI Horizons old-source producer and warehouse contracts are deployed and validated, but the migrated consumers are still held. This leaves the frozen staging_education_sis path in operational use and prevents completion of the Old SIS migration.

## Business Value

Completes the governed, event-driven consumer cutover to staging_education_ai_horizons_old without enabling unrelated source paths or manual execution routes.

## Breaking changes

This activates four production SIS event consumers. Deploy and verify all consumer stacks first, then the producer event flags and permission, outside the 02:00 UTC schedule with no active SIS run. Roll back producer emission first. Deployment and the first fresh SIS run remain separately authorized actions.

## Test plan

- [x] SIS producer suite: 281 passed

- [x] Enrollment suite: 54 passed

- [x] School-year suite: 70 passed

- [x] Retention suite: 107 passed

- [x] Source-directory suite: 37 passed

- [x] Pipeline Lambda suite: 496 passed

- [x] CDK real-config suite: 542 passed

- [x] CDK TypeScript build

- [ ] After a separately authorized deployment, run one fresh managed SIS execution and retain all four consumer and warehouse reconciliations

## Summary

- Preserve the latest explicit Finalsite contact-detail and user observations when a later full run omits them

- Keep explicit tombstones and site retirement as the only entity retirement signals

- Add an integrated Redshift regression for the production omission shape

## Why

Finalsite full runs only derive absence tombstones for school-year contact memberships. Contact-detail unavailability and users omitted from the collection do not assert entity deletion. The Person adapter applied membership semantics to those entity tables, which blocked the initial V0 cutover.

## Business Value

The Person V0 directory can publish from the valid Finalsite history without dropping entities or weakening explicit deletion handling.

## Test plan

- [x] 33 Person runner tests pass locally

- [x] Dev Redshift remaining-source integration passes, including full-run entity omission, explicit tombstones, retirement, and cleanup

## Production defect

The first controlled invocation on immutable version 1 failed before source collection or publication. The Lambda's Redshift connector returned cursor.fetchall() as a tuple, while durable recovery accepted only a list and raised durable publication recovery returned an ambiguous row shape for a normal empty state.

## Fix

Accept only the two standard DB-API outer containers, list and tuple, while preserving the exact one-row/eleven-column shape and all existing fail-closed identity, count, and provenance validation.

## Evidence

- failed controlled run: e0441182-c35f-42cd-a627-a6b3a905302a

- zero matching ingestion_ledger rows

- zero matching publication_attempts rows

- Lambda log confirms failure before source collection and publication

- $LATEST restored to manual_only with controls empty; schedule remains disabled

## Validation

- focused Redshift recovery and handler tests passed

- complete Alpha runner pytest suite passed

- Ruff and formatting passed

- Pyright: 0 errors

- independent review: SAFE

This PR changes only the connector-result container acceptance and its regression test. It does not publish data or activate the schedule.

## Problem

The controlled cutover path pinned the dated 2026-09-14 capture at exactly 91 schools with 47 genuine and 44 fallback budgets. The live population remains 91 schools but is now 46/45 after Santa Monica replaced Orange County. That source change satisfies all durable runtime controls, but the dated assertion rejected it.

## Fix

- replace exact 91/47/44 runtime gating with durable per-resource invariants

- retain the configured minimum of 40 genuine budgets

- require positive typed school counts, nonnegative fallbacks, and exact genuine+fallback coverage

- support v1-to-v2-cutover, v2-bootstrap, and future v2-relative-check consistently

- align the controlled invoker with source-controlled pipeline.json

- align evidence parsing and post-release verification with all runtime volume contracts

- retain the dated fixture as historical evidence, not an operational rule

## Preserved controls

- 80..110 initial cutover bounds and 90% later retention

- exact school and endpoint identity coverage

- provenance metadata and fallback-equals-official validation

- configured minimum genuine-budget coverage

- atomic publication, controlled ClientContext approval, and release attestation

## Validation

- complete Alpha runner pytest suite passed

- focused handler/invoker/verifier suites passed after review fixes

- Ruff and format checks passed

- Pyright: 0 errors

- independent review: SAFE; both defense-in-depth findings fixed

- successful deployed rehearsal evidence: 91 schools, 547 endpoints, 46/45 provenance, zero cache failures, zero Alpha-table mutation

This PR changes source controls only. It does not publish data or enable the schedule.

## Summary

- Treat a missing HubSpot association archive flag as active, matching existing HubSpot consumers

- Retain strict validation for malformed Parent–Child endpoint IDs

## Why

The production CRM association projection omits the archive flag for all 39,406 current Parent–Child edges. The Person V0 adapter incorrectly rejected that valid source shape, which blocked the guarded warehouse cutover.

## Business Value

Person V0 can consume the accepted HubSpot relationship publication without discarding guardian evidence or weakening endpoint validation.

## Test plan

- [x] 33 Person runner tests pass

- [x] Dev Redshift fixture accepts a null archive flag through the full Person refresh

- [x] Production cutover attempt rolled back cleanly at the original source gate before this fix

## Problem

A read-only full-endpoint probe after #1913 fetched all 547 expected Alpha endpoints with 200 responses, then exposed three v2 validator/source mismatches:

- P&L and headcount payloads omit the retired top-level scenarioName

- eight legitimate budget enrollment averages are fractional (119.25 / 187.5)

- 143 values with 19 fractional digits occur only in raw-only P&L ratio rows that are not published to typed numeric tables

## Fix

- accept omitted plan scenarioName, while requiring string-or-null when present

- preserve exact nonnegative fractional enrollment values in NUMERIC(38,18)

- keep headcount integral

- keep comparison values exact NUMERIC(38,18)

- validate raw-only P&L numerics as finite without rounding or imposing an unrelated warehouse scale

- preserve raw API bytes unchanged as immutable evidence

## Validation

- full runner pytest suite passed

- focused regression tests passed

- Ruff and formatting passed

- uv run pyright src scripts: 0 errors

- independent review: SAFE, no findings

- exact live read-only replay: 91 schools, 547/547 responses 200, exact identity set, zero cache failures, all transformations and publication-shape validation passed

- replay artifact: C:\Users\marcu\Downloads\alpha-full-endpoint-probe-plan-fix-2026-09-17.json

- artifact SHA-256: 03a37ea288b2341fd68b0c06dd161b93a7a42dd41d342ef89d98268ec4fd34e9

## Separate publication blocker

The live population is currently 46 genuine / 45 fallback because Santa Monica replaced genuine-budget Orange County without a genuine mapping. This PR does not alter the controlled 47/44 publication gate or authorize publication.

## Problem

The post-#1910 production rehearsal reached the Alpha API, then failed closed because the live one-model /api/public/v1/schools response omits the retired scenarioName key from all 91 rows.

Execution: alpha-rehearsal-20260917T154147Z-f5259cfb

Run ID: 69cc2451-7853-4c0e-a1fb-53e01e2f6e02

## Fix

- make scenarioName optional only in the v2 one-model school contract

- preserve the strict legacy v1 key requirement

- preserve string-or-null validation when the key is present

- preserve fail-closed rejection of any non-empty restored scenario

- map omission to the existing nullable downstream scenario_name through .get

- keep exact raw source evidence unchanged in immutable S3

## Containment

- exact 14-table pre/post fingerprints are identical

- zero run-specific ingestion_ledger or publication_attempts rows

- warehouse audit window contains only two reads and no DML/DDL

- S3 contains only the exact school response, endpoint attempt, and failure marker; no publication manifest

- schedule remains disabled

## Validation

- full runner pytest suite passes

- focused omission, invalid-type, downstream-null, and legacy-v1 tests pass

- Ruff and formatting pass

- uv run pyright src scripts: 0 errors

- exact captured production response replay: 91 rows, 91 unique IDs, zero scenarioName keys

- independent review: SAFE

## Summary

- Accept repeated SIS identity occurrences only when all Person-relevant fields agree

- Deterministically publish one source coordinate while retaining conflict rejection

- Keep SIS profiles and roles available under the same equivalent-occurrence contract

## Why

The live SIS bulk publication contains one identical student occurrence repeated at a page boundary. Person V0 correctly rejected duplicate source coordinates, but that made the complete directory unavailable even though the duplicate carries no conflicting identity evidence. This keeps the fail-closed behavior for conflicting rows while tolerating the observed source condition.

## Business Value

Unblocks the reviewed Person V0 warehouse cutover without weakening canonical identity integrity.

## Test plan

- [x] 33 focused Person runner tests pass

- [x] Redshift dev migration/consumer rehearsal passes with cleanup

- [x] Redshift dev native-source rehearsal validates directory, profile and role behavior for equivalent duplicates, rejects a conflicting variant, and cleans up

- [x] Updated read-only production preflight classifies the current SIS publication as ready with zero conflicting identities

## Summary

- replace the reserved Redshift table alias snapshot with active_snapshot

- add a regression assertion for the exact publication-head SQL shape

## Production evidence

The post-migration manual_only rehearsal reached the Alpha Lambda and failed before source collection:

- execution: alpha-rehearsal-20260917T145459Z-f67f3e5e

- run ID: 75991244-7ddd-438b-ad8e-8443abfdf929

- SQLSTATE: 42601

- parser context: FROM current_snapshot snapshot

Containment was verified: all 14 Alpha table multiset fingerprints were identical before/after, targeted ledger rows were zero, and the isolated Redshift audit window contained zero Alpha DML/DDL.

The corrected query was also executed read-only against production Redshift and returned the current v1 publication contract successfully.

## Validation

- uv run pytest -q

- uv run ruff check .

- uv run ruff format --check .

- uv run pyright src scripts (0 errors)

- uv run python scripts/run_ddl.py (7 immutable migrations, 79 statements; hashes unchanged)

## Summary

- scope Admissions Forecast V2 presentation to the current school year while retaining hidden next-year code

- promote the editable Finance Forecast to the executive table and align its inputs with the current-year Session 3 population

- add year-prefixed labels, accessible header guidance, directional contribution styling, and regression coverage across UI, contracts, and sync

## Testing

- pnpm --dir chat exec vitest run components/dashboards/admissions/forecast/v2/__tests__/forecast-v2-report.test.tsx components/dashboards/admissions/forecast/v2/forecast-v2-route.node.test.ts --maxWorkers=1

- pnpm --dir packages/contracts exec vitest run src/admissions-forecast-v2.test.ts --maxWorkers=1

- pnpm --dir sync exec vitest run src/analytics/admissions-forecast-refresh.test.ts src/redshift/admissions-forecast.test.ts --maxWorkers=1

- pnpm --dir chat typecheck

- pnpm --dir packages/contracts typecheck

- pnpm --dir sync typecheck

- pnpm lint:test-architecture

- targeted biome check

## Demo


## Summary

- Make non-empty artifact paths keyboard-accessible controls that reveal the task-scoped artifact in Finder.

- Preserve empty/loading/unavailable artifact states and surface native reveal failures through the existing chat alert.

- Add regression coverage for path-specific activation, accessibility, empty artifacts, and native failures.

## Tests

- pnpm test:chat

- pnpm build

- pnpm theme:check

## Linear

https://linear.app/builder-team/issue/AI-830/make-artifact-names-clickable-to-reveal-files-in-finder

## Demo


## Summary

- Use one canonical YAML-frontmatter template for new Research artifacts and migrate stale default/reusable templates.

- Validate completed Research output and queue one durable same-thread recovery turn with the parser error.

- Preserve invalid artifacts with an actionable error after retry exhaustion, and add parser/workflow/migration/retry coverage.

## Testing

- cargo fmt --manifest-path src-tauri/Cargo.toml -- --check

- pnpm test:workflow

- cargo test --manifest-path src-tauri/Cargo.toml --lib

- pnpm exec tsc --noEmit

- pnpm theme:check

- pnpm stage:codex

- pnpm test:smoke

## Linear

https://linear.app/builder-team/issue/AI-829/prevent-research-artifacts-from-being-generated-without-required-yaml

## Summary

- Document accepting QuickBooks invitations through the shared service mailbox and confirming the Intuit-to-QuickBooks redirect.

- Document the exact production quickbooks-raw-sync expansion payload and required inventory, realm-binding, and idle-state preflight.

- Clarify that expansion performs the new realm historical backfill and align the AWS authentication wording with the current OneLogin OIDC flow.

## Business Value

Makes QuickBooks school onboarding repeatable and auditable, reducing the risk of adding a secret without expanding the active snapshot or exposing OAuth credentials in pipeline inputs.

## Implementation Effort

Approximately 1–2 hours for an engineer to inspect the current onboarding and raw-sync contracts, reconcile the operational steps, and update and validate both runbooks.

## Linear

- [SURTR-1351](https://linear.app/builder-team/issue/SURTR-1351/document-quickbooks-company-onboarding-and-snapshot-expansion)

## Validation

- git diff --cached --check

- Confirmed the documented flow by successfully onboarding Alpha Denver and Alpha The Woodlands through the production expansion path.

Centralizes the Community age-five-by-September-1 rule, applies it to admissions forecasting, updates mart documentation, and adds boundary coverage. Validated with dbt parse and git diff check.

Exposes separate Guide Approved and Offer Sent no-deposit counts, preserves reconciliation to the combined Session 3 offer operand, documents the mart columns, and adds a singular reconciliation test. Validated with dbt parse and git diff check.

Fixes [SURTR-1270](https://linear.app/builder-team/issue/SURTR-1270/collections-target-forecast-sync-v2-failing-4-of-7-forecast-tabs)

Automated fix by Heimdall v2.

## Business Value

See linked ticket.

## Manual Effort Estimate

(flagged for Keval to confirm)

---

_Automated PR — review by Mercy._

Closes #1354.

Runtime + UI follow-up to #1353 (the mart_admissions_forecast mart, live in the warehouse). Builds the parallel Admissions Forecast V2 milestone report end to end: worker ingestion → Convex publication + authenticated reads → runtime Finance adapter → version-based routing → the executive table, milestone tabs, and runtime Finance tab. The current Forecast report is unchanged except for one footer link.

## What it does

- Parallel rollout mirroring the Enrollment/SIS pattern: the visible Forecast nav still opens the current report; a Forecast V2 footer link opens the new view under the same sub-route via ?version=v2, with Back to Forecast Report nav. No new nav item, no school-year selector, same admissions.forecast.read capability.

- Five-column executive table — School, Start of Year, On Campus, Jan 1, and the generated next-year column (initially 2027-28) — with the planning-focus column highlighted (session_3 / Jan 1 for the current period).

- Row expansion into milestone tabs — session_1 (Start of Year), session_3 (Jan 1), next_session_1, plus a runtime finance_forecast tab. Operational visibility is status-driven (Start of Year hides once locked); Finance is always present. Each operational tab shows the two-card Projected Enrollment Breakdown / Probability Adjusted Pipeline Additions layout that reconciles to the published forecast.

- Runtime Finance tab reusing the existing shared calculator (@bran/contracts/admissions-forecast-finance) fed by a new worker-published input DTO. Editable rates + reset recompute the scenario locally without touching the operational forecasts.

- Loading / sign-in / unavailable / locked states, the last-updated chip, and distinct forecast-v2 analytics (report view, row expansion, tab selection by milestone key).

## Layers

- Contracts (@bran/contracts/admissions-forecast-v2, runtime-free): the published row DTO, milestone/tab keys, executive-column + planning-focus resolution, reconciliation breakdowns, the executive Pipeline table, the Community card, and the Finance adapter.

- Worker (sync/): reads mart_admissions_forecast + the pipeline mart in one snapshot, maps hubspot_program_id → Aerie programPublicId (retaining programCode), builds the rows + Finance input, POSTs to a new bearer-token route.

- Convex: isolated publication mirroring SIS enrollment — validated storage, monotonic/idempotent publish mutation, and getForecastV2Data gated by admissions.forecast.read.

- UI: the version route + dispatch, the executive table + expansion + tabs (desktop + mobile), and the current-report footer links.

## Mart-contract reconciliation notes

The ticket was written before #1353 landed; the delivered mart matches the ticket's mapping tables. Two intentional first-iteration boundaries were honored, not worked around: the Finance tab sources Lead/Showcase counts from mart_admissions_pipeline_dtl (the forecast mart carries only App/Shadow/Offer), joined by program_name because the Finalsite pipeline arm nulls program_code; and student drill-down is not wired in V1 (the mart publishes aggregate counts, mirroring the SIS report's rollups-only mode).

## Open decisions (resolved)

1. Start of Year stays a visible locked-actual table column even after it passes; only its expansion tab hides (all five columns always render).

2. Expansion is single-open (one school at a time), matching the current Forecast's effectively single URL-driven expansion.

## Verification

pnpm typecheck (contracts/chat/sync), full-repo biome check, and the CI lint gates (boundaries, convex-paths, read-bounds, test-architecture) all pass. New tests: contracts 18, sync 13, chat 62 (convex hardening 22, UI 15, dispatcher 25). Self-review: two independent reviewers + a verification pass; all real findings fixed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

aerie-rebl3-raw-sync has silently captured exactly 100 of REBL3's ~295 sites on every single daily run since it went live — discovered via Aerie's new Surtr-comparison experimental view, which showed 0% overlap between Surtr's mart and Aerie's own REBL3 read, and garbage-looking placeholder addresses in the captured subset.

Root cause: this pipeline calls REBL3's older POST /api/sites/query endpoint, which reports a count of exactly 100 regardless of filters — a fundamentally narrower dataset (REBL3's "curated_active" scope), not a pagination bug. Aerie's own worker (sync/src/upstream/rebl3/client.ts) has always read the newer GET /api/v2/sites endpoint instead, which exposes REBL3's full ~295-site population.

Fix: migrate this pipeline's client to v2 — cursor-based pagination, matching Aerie's own call shape exactly (limit/cursor/expand=score, no excluded filter, same as sync/src/upstream/rebl3/sync.ts's bulk-sync call). Each v2 site resource is adapted to this pipeline's existing flattened row shape via a direct Python port of Aerie's own rebl3V2SiteToLegacySite (packages/contracts/src/rebl3-v2.ts in the Aerie repo) — transforms.py, entities.py, and the Redshift DDL are all unaffected.

Also lifts the /api/v2 exclusion in test_contract.py's security contract test — that exclusion assumed v2 was Convex/Aerie-only territory, which turned out to be the actual source of the completeness gap. Comment explains why the exclusion is lifted.

## Changes

- src/rebl3_client.py — full rewrite: v2 endpoint, cursor pagination, envelope validation (object/scope/total_count/_links), site-resource → legacy-row adapter, stuck-cursor guard

- src/extraction.py — tolerate a nullable total_count (v2 doesn't always report one; completion now also relies on cursor exhaustion), apply the same row adaptation on replay

- tests/test_rebl3_client.py — rewritten for v2 request/response shape

- tests/test_landing_and_extraction.py — fixtures updated to land realistic v2 envelopes

- tests/test_contract.py — exclusion list and endpoint assertions updated; /api/v2/sites/ (per-site fanout) stays excluded, only the plain list endpoint is allowed

- README.md, DDL comment — updated to describe the v2 contract

## Business Value

Fixes a silent, ~2/3 data-completeness gap that's existed since this pipeline's first live run — every downstream consumer of mart_education.aerie_rebl3_sites (including the new Aerie Data Health / experimental comparison views from the current Surtr↔Aerie integration work) has been working off an incomplete REBL3 site inventory. This was the actual blocker discovered while validating that migration before any real cutover — exactly the kind of gap the experimental comparison view exists to catch.

## Manual Effort Estimate

AI-drafted estimate — flag for Keval to confirm/adjust: ~1 day (diagnosing the root cause via CloudWatch logs + Redshift row counts, tracing Aerie's own v2 client contract, porting the field-mapping logic, and updating the full contract-test suite).

## Test plan

- [x] pytest — 125/125 passing

- [x] ruff check / ruff format --check — clean

- [x] scripts/apply_ddl.py --dry-run — DDL unaffected, renders correctly

- [ ] First live run post-merge: verify mart_education.aerie_rebl3_sites row count lands near Aerie's own ~295-site count, and the Aerie experimental comparison view shows real overlap instead of 0%

Linear: (ticket pending — this belongs in "Data Layer and Surtr Integration")

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Accept integral JSON counts returned by the live Convex query transport

- Keep rejecting booleans, strings, fractional counts, and row-count mismatches

## Why

The deployed Aerie snapshot endpoint returns a complete 194-row capture, but Convex serializes source_count as 194.0. The Person publisher required the Python type to be exactly int, so it rejected the valid snapshot before publication.

## Business Value

This allows the disabled Person publisher to validate the real Aerie account source while preserving its completeness checks.

## Test plan

- [x] 33 Person runner tests pass

- [x] CI-pinned Ruff check and format validation pass across pipelines

- [x] Read-only live query returned 194 accounts and passed the corrected contract validator

- [x] No S3 or Redshift writes performed

## Summary

- Place the Aerie account snapshot, publication ledger, and publisher in the existing staging_education_rhodes namespace

- Keep account publication metadata separate from the generic Rhodes list-snapshot ledger

- Update the Person readers and release bundle, and teach the Rhodes catalog verifier to accept these optional externally written objects

## Why

Rhodes is the existing Aerie/Convex warehouse landing namespace. Creating a separate staging_education_aerie schema for one account table would split the same platform across two staging schemas and make the source model harder to understand. The account publisher still needs its own ledger because its complete-capture and retry contract differs from the generic Rhodes list-snapshot contract.

## Business Value

Keeps the Person V0 source boundary simple and coherent before warehouse installation, while retaining traceable and atomic Aerie account publications without causing false Rhodes schema-drift failures.

## Test plan

- [x] 31 focused Person tests pass

- [x] 188 Rhodes staging tests pass

- [x] Complete SQL package passes all 26 checks against the disposable Redshift dev database

- [x] Dev validation confirms exact cleanup and all 17 tested DDL hashes

- [x] Repository-wide Ruff lint and format checks pass

- [x] git diff --check passes

## Summary

- Register the new Master Mapping business units 42DS and SEZP across backend and frontend registries.

- Include SEZP in the Monthly Financial Reporting Education partition.

- Keep AI spend assignability and regression tests in sync.

## Validation

- Backend focused tests: 148 passed.

- Ruff, Pyright, frontend ESLint, Prettier, TypeScript, full Vitest, and production build passed.

- Full backend pytest was attempted but stopped during collection on four unrelated pre-existing import/fixture errors.

## Live data

- The corresponding Master Mapping Redshift sync was applied separately after a verified 613-row backup.

- The canonical mapping table now contains 618 rows, and the downstream mapped/consolidated refresh completed successfully.

## Screenshot

<img width="445" height="812" alt="image" src="https://github.com/user-attachments/assets/a2173156-8d94-471d-a4d2-70a40d5e7bb0" />

## Summary

- Use the versioned, code-owned prompt for new trusted Agent claims; retain the separate public Agent policy and current Skill/access handling.

- Remove the obsolete prompt catalog, role-assignment controls, seed script and their unused support code.

- Keep legacy storage compatible and provide an operator-only cleanup with read-only inventory and a retirement runbook.

## Why

User-specific prompt composition is a retired experiment. Its remaining runtime and admin paths still create a second source of instructions and maintenance cost. This extracts only prompt retirement from #1247, preserving the current bundled prompt text and newer Agent behavior.

## Business Value

Users get one maintained Agent baseline, and administrators no longer see controls for the abandoned prompt system. Deployment does not require deleting historical data.

## Breaking changes

The obsolete Convex prompt CRUD/comment and prompt-role assignment functions are removed. Directory v2 retains promptRole as a deprecated, always-null field. Stored prompt overrides no longer affect new trusted claims.

## Test plan

- [x] All required hosted CI checks pass at 804bfb3db.

- [x] Mercy approved 804bfb3db after accepting both follow-up fixes and withdrawing the rollback/prompt-continuity findings. GitHub reports CLEAN / MERGEABLE.

- [x] Follow-up: 38 related migration/Directory/OpenAPI tests, Chat/Convex typechecks, repository lint and all seven delta-review lanes pass.

- [x] Full local Chat suite: 10,646 passed, 18 skipped. Contracts: 1,024; Sync: 1,179; root tooling: 150; worker executor: 34 passed.

- [x] Workspace typechecks and lint pass after rebase onto main 153522c45. Follow-up: 114 Agent/migration tests, Chat/Convex typechecks and lint pass.

Mercy's earlier serializer finding was disproved with installed Convex source and real-serializer regression tests. The operator-error suggestion was adopted. Both follow-ups are now addressed: tests cancel each of the four phases after a committed batch, verify remaining rows and stopped progress, resume the normal series and prove completed phases are skipped while user/audit data is preserved. Directory compatibility provenance is computed and covered by a served-catalog assertion. These tests establish controlled cancellation/resume, not every infrastructure failure mode.

The local root test command stops on three unchanged macOS-incompatible Skill-installer tests; hosted Linux full-suite validation passes. No deployment, live purge or browser smoke performed. Runtime rollback must retain the widened promptSource schema; storage cleanup requires a separate approved snapshot and full verification.

## Summary

- Replace unsupported Boolean-to-VARCHAR casts in Person SIS lineage checks with Redshift-safe normalization

- Correct the combined dev harness so source-specific assertions remain valid when prior mappings are retained

## Why

The released Person bulk-SIS package failed its live read-only preflight because Redshift does not support casting BOOLEAN directly to VARCHAR. The same expression was present in the SIS adapter and source-profile view, so the warehouse cutover could not safely proceed.

The full dev harness also contained assertions that assumed each phase started with an empty directory. Person intentionally retains prior source mappings, so those assertions now target their own fixture coordinates and supported persisted views.

## Business Value

The Person warehouse package now compiles and runs in Redshift with current SIS data, preserves retained identities across combined phases, and is ready for the controlled cutover validation required by the Aerie People API.

## Test plan

- [x] 31 focused Person runner tests

- [x] Read-only production SIS preflight returns ready for 23,875 students and 573 teachers after the corrected expression

- [x] Complete 26-check Redshift dev run passed uninterrupted

- [x] Randomized dev fixture cleanup verified

- [x] git diff --check

No production DDL, pipeline invocation, schedule, activation, or warehouse write is included.

Closes #1353.

## What this builds (DBT only)

The Admissions Forecast V2 warehouse contract — the milestone-based forecast mart the follow-up publication/UI work (#1354) will consume. Worker/Convex/Finance/UI are out of scope.

Three models plus a staging boundary:

- stg_educrm_coming_year_projection — staging projection of the EduCRM coming-year rate columns (1:1, equal_rowcount-tested).

- int_admissions_forecast_rates — the temporary pass-through rate boundary. Resolves the upstream program_code code-to-code through int_school_identity to hubspot_program_id, grain (hubspot_program_id, school_year), classifying each stage rate as upstream_observed / upstream_fallback / upstream_zero and carrying rate_lineage_status = 'legacy_upstream_passthrough'.

- int_admissions_forecast — owns the calculation. Two-row-per-program school-year spine (current + next) derived from the SIS offering axis via int_school_identity (never year(current_date)); enrollment + Finalsite-pipeline + Community aggregates; email-based cross-system identity reconciliation (matched/unmatched/ambiguous); the Session 1 retention forecast and the Session 3 Jan-1 planning estimate. warehouse_now() is the sole clock.

- mart_admissions_forecast — the stable, self-contained published contract, unique by (hubspot_program_id, school_year), carrying every documented identity / rate-provenance / session_1_* / session_3_* column plus model_version, calculated_at, rate_source_relation. Raw additions stay decimals; the modeled subtotal is rounded once; every headline reconciles exactly from published components.

Schema .yml (full mart column contract), 23 tests (schema + singular), and a narrative spec in dbt/docs/admissions-forecast.md.

## Local verification (real Redshift, pr1353_ namespace)

dbt build green and all 43 tests pass with --vars '{pr_number: 1353}'. Verified on live data: 106 rows (53 programs × 2 years), unique grain; 2026 Session 1 locked_actual to the SIS First Day actual, 2027 split live_forecast (43) / unavailable (10, no 2027 offering); Session 1/Session 3/Community/pipeline arithmetic reconciles exactly; 88/88 rate rows per year pass through with parity.

## Two documented V1 boundaries (carry to #1354)

- Identity overlap is resolved by normalized email, not the SIS external-id bindings the design named — the Finalsite pipeline carries no HubSpot/SIS key, and email is the only shared natural key (matched≈115, sparse). Matched/ambiguous identities are removed from weighted counts; the three counts are published and reconcile to the source population.

- Community age rule is birth-date presence (all measured paid records carry a DOB); a stricter numeric age rule is a later refinement that keeps the same bucket contract.

## Self-review

Two independent reviewers + an audit, then a fresh audit of the fixes. The consolidated audit is posted as a top-level comment. Two substantive findings (Session 1 next-year-band year sourcing; Session 3 transfer partitions reading a past-only cohort) were fixed and are now pinned by an independent operand-sourcing test.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- Use the Redshift-supported ownership statement for the Guide behavioral-events view migration.

- Advance the migration idempotency token after the known failed and rolled-back production attempt.

- Record the failed statement evidence and corrected retry contract.

## Why

The guarded production migration passed its catalog preflight but Redshift rejected ALTER VIEW ... OWNER TO. The atomic batch rolled back. Redshift accepts ALTER TABLE ... OWNER TO for the view, so the source-controlled migration must be corrected before retrying.

## Business Value

Allows the GuidePlatform schema recovery to complete without leaving code and warehouse contracts out of sync.

## Test plan

- [x] 47 Guide contract tests pass.

- [x] Ruff passes for the touched Python files.

- [x] git diff --check passes.

- [x] Live syntax probe confirmed ALTER TABLE ... OWNER TO succeeds for the existing view without changing its owner.

## Summary

Add a mobile-specific Enrollments dashboard presentation that replaces the wide matrix with collapsed school cards while preserving metric drilldowns, dynamic school-year layouts, capacity details, controls, and the freshness footer on narrow screens.

### Screenshots

<img width="726" height="793" alt="Screenshot 2026-09-16 at 4 25 59 PM" src="https://github.com/user-attachments/assets/d99f2182-385c-40f7-89a3-3bfe24b67dc8" />

### Changes

- chat/components/dashboards/admissions/enrollments/enrollments-view.tsx — Dispatch to the mobile list via useMobileUI; let mobile content grow naturally so the SIS link and last-updated chip follow the full card list while desktop keeps the constrained matrix layout.

- chat/components/dashboards/admissions/enrollments/enrollments-mobile.tsx *(new)* — Render expandable school cards, visible current/next year bands, metric click-throughs, capacity contributor tooltips, and mobile totals.

- chat/components/dashboards/admissions/enrollments/__tests__/enrollments-mobile.test.tsx *(new)* — Cover expansion, layout/year rules, click wiring, capacity details, and totals.

### Design Decisions

- Reuse visibleEnrollmentColumns, getEnrollmentColumnBands, and splitBandColumnsAroundCapacityPair so mobile follows the desktop pre-session/started-year and next-year visibility rules.

- Keep the card header as the only expand/collapse button; metric cells remain separate controls, while Capacity and Fill % remain non-student-drilldown surfaces.

- Let the mobile content wrapper size to the full card list so the SIS report link and last-updated chip cannot overlap expanded cards.

## Business value

Mobile users can inspect school enrollments and open student drilldowns without horizontal scrolling, while retaining the same meanings and controls as the desktop report.

## Estimated manual effort

6 hours.

## Test Plan

- [x] pnpm --dir chat exec vitest run components/dashboards/admissions/enrollments/__tests__/enrollments-mobile.test.tsx --maxWorkers=1

- [x] pnpm --dir chat exec vitest run components/dashboards/admissions/enrollments/sis/__tests__/sis-enrollments-matrix.test.tsx --maxWorkers=1

- [x] pnpm --dir chat exec tsc --noEmit --pretty false

- [x] pnpm lint:test-architecture

- [x] Biome check on all changed files

- [ ] Reviewer manual check on the running mobile dashboard

## Summary

- Admit the reviewed nullable GuidePlatform behavioral-event links in raw and clean staging

- Add bounded raw-view and downstream procedure migrations that preserve reviewed owners and grants

- Rotate the Guide roster consumer pin and document the gated fresh-publication recovery sequence

## Why

The September 16 scheduled raw sync failed closed when GuidePlatform added behavioral_events.daily_note_id. A second nullable link, behavioral_events.shout_out_id, appeared after that validation. The checked contract no longer matched the 57-table source boundary, so no fresh snapshot could publish.

## Business Value

Restores the reviewed path to fresh GuidePlatform publications without weakening exact-shape validation, broadening access, or exposing partial data.

## Test plan

- [x] Producer contract reproduces from the live catalog

- [x] Producer: 123 tests

- [x] Guide roster: 77 tests; 5 approved-environment integration skips

- [x] Ruff lint and format checks on the affected surfaces

- [x] Raw migration matches the canonical generated view and has an allowlisted atomic apply path

- [x] Raw migration checks catalog visibility, exact owner/grants/default privileges, dependencies, and zero RLS/masking policies before submission

- [x] Raw migration repeats the exact security-state guard before commit in the same atomic batch

- [x] Guard SQL consumes its catalog-state CTE; post-commit verification failures retain the committed migration ID and prohibit migration retry

- [x] Guide roster migration matches the canonical procedure, preflights owner and all EXECUTE ACLs, and runs as one atomic Data API batch

- [x] Guide roster rejects missing immutable ledger metadata before lineage comparisons

- [x] Both migration paths preserve available statement IDs and fail closed on malformed polling or submission responses without encouraging blind retries

- [x] Read-only production preflight: writer-only raw-view grants, expected procedure security, and no bound raw-view dependents

- [ ] After merge: apply guarded migrations, deploy matching producer and consumer, and verify a fresh publication

## Summary

Fourth and final source-only Alpha replacement-stack PR. This adds release verification and activation controls on top of #1876.

- keeps the production-shaped deployment in PUBLICATION_MODE=manual_only with scheduling enabled only for no-Redshift-write rehearsals;

- preserves strict legacy top-level and params.dry_run compatibility while rejecting malformed or conflicting values before secrets or Redshift;

- permits a controlled write only for an exact run through a tightly IAM-restricted direct Lambda invocation, with params.dry_run=false and a one-time token supplied only through Lambda ClientContext;

- rejects raw controlled tokens in event payloads so Step Functions/on-demand parameters cannot transport approval material or reach publication;

- adds a getpass-based direct invocation helper that keeps the token out of shell arguments, environment variables, files, logs, event payloads, and Step Functions history;

- adds a read-only release verifier for the globally newest publication, exact immutable S3 evidence, source-derived Decimal rebuild, all 11 publication tables, physical catalog/owners/ACLs/migration hashes, volume/provenance thresholds, and exact version-pinned Lambda identity;

- replaces the legacy README with the proposed v2 runbook while clearly stating that v2 is not deployed or current.

## Stack

1. #1872 — API contract and lossless transforms

2. #1874 — physical schema and trusted installer

3. #1876 — atomic publication and recovery

4. this PR — release verification and activation controls

This PR must target fix/alpha-atomic-publication and be reviewed against its exact parent/head.

## Safety boundary

Source only. This PR does not merge any stack layer, deploy Lambda, apply DDL, publish Alpha data, change production configuration, invoke the controlled path, or activate automatic publication.

The existing Step Functions/schedule route remains incapable of controlled publication: manual-only unmarked invocations rehearse, payload tokens are rejected, and controlled approval is accepted only from exact Lambda ClientContext. Production activation additionally requires a separately approved, tightly scoped lambda:InvokeFunction policy for the designated direct caller.

## Validation

Final exact pushed head: afdb6764ebb14d08cedd5c42b1bd002dec2cd3a1.

- pytest -q: 723 passed

- current Ruff check/format: passed

- pinned ruff==0.15.22 check/format: passed

- scoped Pyright: 0 errors / 0 warnings

- scripts/run_ddl.py: dry run only, 7 migrations / 79 statements

- native git diff ... --check: passed; worktree clean after commit

- exact stack ancestry: PR3 head 25d9756b449dccec9f84cc955e6d817ea37235d5 is the merge base

- independent verifier/data-contract/topology audit: SAFE

- independent controlled-invocation security audit: SAFE

- independent follow-up specifically confirmed the scheduled StartAt route reaches the exact validated InvokePipelineLambda state: SAFE

## Prior-review disposition

The prior critical assertion that raw_endpoint_payloads was omitted from verifier contracts is factually incorrect. Executable regression evidence proves it is present in the publication allowlist, table signatures, qualified-name gate, catalog expectations, and derived ACL expectations. The review did expose a related real physical-column defect: the verifier now reads JSON_SERIALIZE(payload_json), and the regression covers that exact physical contract.

The remaining blocking classes are repaired and covered on this exact head: exact application-level committed result schemas, unknown-response-field/token-exfiltration rejection, canonical numeric Lambda qualifier plus matching ExecutedVersion, encoded ClientContext limit, migration-before-deploy runbook order, qualified publication-version and terminal $LATEST readiness/configuration checks, source/warehouse grain multiplicity, complete release environment, exact EventBridge target/input, and reachable Step Functions-to-unqualified-Lambda topology.

The subsequent exact-head review raised three additional blocking classes. They are now repaired on b6f216cd: every one of the 11 publication-count entries has an explicit valid committed-result predicate in both normal and recovered schemas; the EventBridge target, target IAM role, state machine, and state-machine execution role are pinned to their exact production ARNs; and the complete nine-state ASL graph, all task resources/function ARNs, transitions, terminal states, and the only permitted catch branches are attested with no extra/unreachable state, catch, branch construct, ClientContext, or control material. Independent focused reviews of the count contract and complete IAM/topology contract both returned SAFE.

The latest exact-head review then identified one remaining blocker: approval-token keys nested inside event/params JSON. Head 77d80a0a recursively rejects the exact controlled_publication_token key in all dict/list payload shapes, including present null, with bounded fail-closed scanning before boolean resolution, ClientContext access, secrets, source calls, S3, or Redshift; actual Lambda ClientContext remains the only accepted approval channel. The same pass enforces the 3-character S3 bucket minimum and controlled non-string S3 URI failure. Focused validation passed (184 tests) and independent security review returned SAFE.

The next exact-head review found the last two verifier boundaries: partial ASL field attestation and first-page-only EventBridge target enumeration. Head 80116610 pins the complete canonical production ASL to SHA-256 bae1e86a5f00e7354b96f9c13b47aa4d8aeac5655902068bef467c464cd874d1 (independently recomputed from the saved read-only 5,357-byte production definition) before semantic checks, and exhausts all ListTargetsByRule pages before enforcing global exact-one cardinality. Regressions cover a second-page extra target and direct TimeoutSeconds hash drift. Full validation remains 585 tests and the final independent verifier audit returned SAFE.

Mercy approved exact head 80116610 and reported no blocking findings, but its remaining notes identified valid fail-closed hardening. Head 12a8b1ae makes the 18-key normal and 14-key recovered response schemas value-disjoint; counts every visited JSON value in the bounded recursive token scan; validates canonical S3 bucket syntax plus all current AWS-reserved general-purpose prefixes/suffixes; requires writer-canonical aware UTC evidence timestamps; and rejects retired release-gate environment variables instead of silently applying defaults. Full validation passed (609 tests), and three focused independent audits returned SAFE after the final reserved-name repair.

The next exact-head review identified a PostgreSQL/Redshift null-ordering defect and two evidence-hardening gaps. Head 1bd4504e globally rejects any published ledger row with a NULL published_at, retains explicit non-null DESC NULLS LAST selection, requires one exact committed attempt timestamp on the physical run/hash identity, rejects non-string warehouse raw error_code, and recursively rejects duplicate Lambda-response JSON keys before validation or output. Full validation passed (617 tests), and independent SQL and response-security audits returned SAFE. The review suggestion to bind dry-run/recovery/URI fields on publication_attempts was not implemented because those columns do not exist in its immutable physical contract; committed presence is instead proven through its actual non-null committed_at row and exact run/hash cardinality.

Mercy approved exact head 1bd4504e and reiterated an attempt-binding request that does not match the immutable four-column successful-attempt schema. Its two valid helper notes are repaired on head 54aa4a65: token-reflection checks now cover decoded string substrings and exact emitted numeric/boolean/null scalar bytes, while prompt EOF/interruption becomes the same generic controlled failure without a traceback. The AWS-documented -an rejection remains intentional for this global general-purpose bucket contract because that suffix is permitted only in the separate account-regional namespace. Full validation passed (625 tests) and the independent helper-security audit returned SAFE.

Mercy's review of head 54aa4a65 correctly identified that verifier evidence JSON still accepted duplicate object keys. Head 33095207 routes every verifier JSON surface through one recursive duplicate-key rejecting parser while preserving Decimal parsing for externally sourced measures and rejecting non-standard constants. It also makes the immutable ASL-hash regression structurally explicit: the expected digest is pinned before the TimeoutSeconds fixture mutation, asserted unchanged, and only later semantic-specific checks intentionally repin their fixtures. Full validation passed (626 tests), and independent JSON-security and ASL-test audits both returned SAFE. The repeated non-blocking -an suggestion remains intentionally rejected for the documented namespace reason above.

Mercy's review of head 33095207 confirmed the hash, JSON, and -an dispositions, then identified a real rollout-order risk: v2 intentionally rejects retired release variables at import, so they must not remain during code replacement. Head dca86a0a updates the future runbook to require a separate configuration-only removal of MIN_SCHOOL_COUNT and MAX_SCHOOL_COUNT_DROP_FRACTION while legacy v1 remains deployed, followed by Active/Successful and exact-absence checks both before v2 code replacement and before any invocation path is re-enabled. Runtime fail-closed behavior is unchanged. Full validation passed (626 tests) and the independent rollout-order audit returned SAFE.

Mercy approved exact head dca86a0a and confirmed the retired-variable rollout fix, while noting one valid nonblocking verifier defect and two valid hardening gaps. Head 4a40af57 applies the dated 91/47/44 assertions only to v1-to-v2-cutover, leaving v2-bootstrap governed by its configured bootstrap bounds; enforces the same canonical global S3 bucket/key contract before verifier reads; and requires snapshot.fetched_at to exactly round-trip the writer's aware UTC form. The fractional sheet_row suggestion was intentionally rejected because migration 004 explicitly preserves values such as 26.5 and the physical contract is NUMERIC(18,6); a regression now protects that contract. Full validation passed (639 tests) and the independent final working-tree audit returned SAFE.

Mercy's review of head 4a40af57 found one further request-surface gap: a token appearing in run_id or as JSON escape bytes could enter the Lambda Payload even though ClientContext was the intended sole token channel. Head 29037a02 checks every semantic nonsecret request surface (FunctionName, numeric Qualifier, InvocationType, and the complete event), checks decoded and JSON-serialized scalar forms, and rechecks the exact final Payload bytes before ClientContext construction or boto client creation. Regressions cover semantic strings, numbers/booleans, quotes, and the \n spelling versus an actual newline. Full validation passed (647 tests) and the independent security re-audit returned SAFE.

Mercy's review of head 29037a02 found a rollout compatibility ambiguity plus valid floor/output hardening. Head d143a5bd makes the future transition two explicit fail-closed CloudFormation gates: a configuration-only v1 revision may delete only the two legacy keys after proving their values equal v1 defaults, while normalized full configuration and exact v1 code SHA remain unchanged; v2 then requires exact reviewed code/state/status and full environment equality before EventBridge can be enabled. Both command blocks use set -euo pipefail and cleanup traps. The cutover floor is positive. Controlled results are privately written, flushed/fsynced, and atomically hard-linked to a create-only final path; failed temporary writes are removed; stdout failures stay generic. Decoded string token matches remain substring-based, while non-string response scalars require exact complete JSON encodings. The invalid multi-head fast-forward command now uses only the final stacked head. Full validation passed (653 tests), and independent rollout and output-publication audits returned SAFE.

Mercy approved exact head d143a5bd and left one non-blocking hardening note: verifier CLI deployment inputs were not all rejected before Secrets Manager and Redshift access. Head 5f5dff48 closes that gap. Before any credential access, the verifier now requires a valid bare Lambda function name, a canonical base64-encoded 32-byte CodeSha256, exact manual_only and immutable raw-location controls, a canonical controlled token digest, and equality between the expected and controlled run IDs. Manifest binding and all later read-only deployment checks remain fail-closed. Full validation passed (656 tests), and the independent pre-credential audit returned SAFE.

Mercy's review of 5f5dff48 identified one blocking approval-material path and two valid hardening notes. Head 2edef21d hashes every event string scalar and dictionary key and uses constant-time comparison against the configured approval-token digest, so the exact token is rejected under arbitrary names before secrets, source, S3, or Redshift; reserved token keys, including null, and all existing bounds remain fail-closed. The runbook now waits for exact DISABLED and ENABLED EventBridge states before proceeding. Set-valued successful verifier checks serialize as deterministic sorted JSON arrays. Full validation passed (659 tests), and independent token-value security plus EventBridge/serialization audits returned SAFE.

Mercy's review of 2edef21d raised five items. The stated school_models omission was false—the table was already in value-level reconciliation—but head 6e93646f adds an exact reconciliation allowlist invariant covering every derived publication table while retaining separate exact raw-payload reconciliation. Valid findings are fixed: ClientContext plaintext enables a second pre-work scan for decoded token substrings in all event strings/keys; the freeze includes the exact EventBridge target role plus all on-demand principals and proves zero running executions immediately before DDL; the exact numeric version is captured from publish-version and remains in one protected shell through qualified read-back, grant, and invocation; $LATEST and later automatic activation have exact post-update read-back gates; and private-temp cleanup failure is surfaced generically. Full validation passed (663 tests). Independent token-substring, reconciliation/cleanup, and drain/read-back audits returned SAFE.

Mercy approved exact head 6e93646f and reported four runbook items. Its claim that jq should not compare .Version to the literal "$LATEST" was incorrect—AWS returns exactly that literal for unqualified configuration—and the automatic environment comparison is intentionally against the separately reviewed future source change. Head 78c03001 makes those assumptions explicit and repairs the valid operational gaps: full controlled and terminal environment updates are executable; the published numeric version remains in one shell through read-back/grant/invoke; the exact qualified-only inline role grant is created, read back, used, retried/revoked, and proven absent on normal and failure paths; every executable placeholder is shell-quoted; and automatic activation first proves the reviewed source environment is already automatic. All six Bash blocks pass bash -n; full validation remains 663 tests; the independent final command audit returned SAFE.

Mercy approved exact head 78c03001 with five further hardening findings. Head 6143614b independently requires complete official/rule-fallback/genuine-budget provenance before warehouse matching; makes every runbook cleanup failure loud; normalizes both object and URL-encoded IAM policy read-backs; rejects empty and NUL-containing output basenames generically; and fsyncs supported parent directories after final-link creation and temporary-name removal. The literal "$LATEST" jq checks remain intentionally correct because that is the AWS unqualified Version value. Full validation passed (673 tests), all six Bash blocks pass bash -n, and independent provenance, cleanup/policy, and output-durability audits returned SAFE.

Mercy's review of 6143614b exposed the digest-only substring limitation. Head 82767604 closes the class: a numeric version with configured controlled identity now rejects every no-ClientContext invocation before secrets, source, S3 (including failure markers), or Redshift; terminal $LATEST with empty controls retains legacy/scheduled dry runs; actual controlled requests still receive full plaintext substring scanning and constant-time digest binding. It also restricts helper function names to bare Lambda grammar, adds private atomic create-only verifier output, removes final output on post-link durability failure, and uses restrictive Windows/POSIX creation modes. Full validation passed (723 tests); configured-version and local-output audits returned SAFE. Mercy's full synthetic verify() fixture suggestion is retained as non-blocking test debt: the repository lacks 534 historical endpoint captures and a complete warehouse/catalog export, while current DDL/schema oracle tests cover the physical contract and the release run itself mandates the real read-only verifier. The hard-coded production identifiers are intentional pins and verify_schedule live-gates their exact rule, target, roles, ASL, account, and region.

Mercy review of 82767604 identified operational gaps now closed at 7ca1e7df: every runbook shell pins the runner directory; the temporary exact-resource states:StartExecution deny is applied, simulated to explicitDeny, later removed and proven absent, and the EventBridge target role is simulated back to allowed before enable; verifier evidence must be a fresh create-only artifact and is gated by PASS plus run/function/code/version identity; zero-school rejection occurs before dependent arithmetic; --output is nonempty, valid, and absent before credentials; and the live topology now hard-pins pipeline-alpha-public-api-sync-prod. Full validation passed 723 tests. Independent path/freeze/artifact and final code re-audits returned SAFE. The zero-school review claim that division preceded rejection was stale for 82767604, but head 7ca1e7df moves the guard to the start of verify() and adds explicit order coverage.

Mercy review of 7ca1e7df identified recovery, alternate-token-spelling, marker-boundary, and provenance gaps closed at d93dfbb4. A trap is now armed before the first freeze mutation: pre-DDL failure retries and proves removal plus restored allowed/ENABLED; immediately before DDL apply it switches to deliberate fail-closed retention; every failed v2 transition retries and proves DISABLED plus explicitDeny for every role, exiting 97 if recovery cannot be proven. All AWS blocks share one profile, region, and STS account. Token scanning linearly decodes all valid JSON short, \uXXXX, surrogate-pair, and escaped-slash spellings across values and keys. Secret configuration remains before the external-work marker boundary. Runtime transforms and the verifier both require exact aware-UTC +00:00 snapshotAt writer round-trip form across official, fallback, and genuine-budget provenance. Full validation passed 723 tests; independent cleanup, token/boundary, and provenance/AWS audits returned SAFE.

Mercy review of d93dfbb4 identified CloudFormation survivability, IAM create-only recovery, and pre-invocation output gaps closed at d4bca9db. The rollout freeze now uses a reviewed immutable-ID Organizations SCP: an unconditional deny scoped only to production account 479395885256, states:StartExecution, and the exact state machine. It covers all current/replacement principals and cannot be removed by CDK role mutation. Exact content/type and tri-state attachment are read before attach, immediately pre-DDL, and post-deploy. A validated <80-day terminal STANDARD execution name provides a real non-mutating authorization probe (ExecutionAlreadyExists detached; AccessDenied attached). Recovery reattaches by ID, never overwrites an IAM policy, and exit 97 remains fail-closed. Controlled helper output is preflighted before getpass or Lambda. $LATEST recovery now retries and proves exact empty/manual source state after any uncertain controlled update, and qualified IAM grants use a validated random UUID name. Captured fixture adaptation asserts an exact legacy allowlist before canonical mapping. Full validation passed 723 tests; SCP rollout, $LATEST cleanup, and output/fixture audits returned SAFE.

Mercy review of d4bca9db reported the DDL marker after --apply, although the exact pushed file placed it immediately before. Head afdb6764 removes the boolean entirely so the state cannot be misread or regress: the pre-DDL restore trap is structurally installed before the first AWS mutation, then replaced immediately after local dry-run and immediately before --apply by a post-DDL trap with no SCP detach or EventBridge enable path. Any apply ambiguity therefore retains the complete freeze. It also adds an explicit huge-integer regression proving _is_finite_number catches OverflowError. Full validation passed 723 tests; structural SCP re-audit plus independent full suite returned SAFE.

## Exact-head review closure (55699ebc)

Mercy review of afdb6764 identified six blocking release-control gaps. Exact head 55699ebc3e51a3ec7f97d0b790d0c4c922031a2e closes each one:

- Organizations Policy.Content is decoded as raw or URL-encoded JSON and compared in canonical compact/sorted form at every lifecycle read.

- v2 recovery propagates attachment, authorization-probe, wait, and stale-probe-file failures explicitly even when Bash suppresses errexit; an unprovable recovery exits 97.

- temporary qualified IAM access requires a pre-grant implicitDeny; revocation requires policy absence plus propagated implicitDeny twice around a guarded 30-second wait.

- event traversal charges dictionary keys and values within the root-inclusive 10,000-node budget, and configured-token digests match raw and valid decoded JSON spellings before ClientContext plaintext is available.

- only exact empty strings in both controlled settings mean unconfigured; falsy malformed values fail before secrets, S3 markers, source calls, or warehouse access in both manual_only and automatic modes.

- both output writers retain a duplicate descriptor, verify source/final inode identity in a private parent, invalidate a linked success artifact through the held descriptor on any post-link failure, retry removal, and reject any remaining mismatched inode. Descriptor-duplication failures close the original descriptor. The verifier publishes only its required output artifact and emits no sensitive stdout payload.

- fallback provenance now uses the strict canonical aware-UTC +00:00 timestamp validator.

The complete exact-tree validation passed 741 tests, current Ruff, pinned Ruff 0.15.22, Pyright with 0 errors, DDL dry run, all six extracted runbook Bash fences under bash -n, secret scanning, and diff checks. Independent policy/recovery/revocation, scanner/configuration, and output-invalidation audits each returned SAFE.

## Exact-head review closure (51f2e834)

Mercy review of 55699ebc identified two blocking activation/topology defects and four high-severity follow-ups. Exact head 51f2e8347dd9280da791b12820e5b8af1c018f88 resolves the concrete defects:

- Before the v2 SCP is detached or EventBridge is enabled, verify_schedule(..., expected_rule_state="DISABLED") now attests the exact rule expression, single paginated target, target ARN/input/role, state-machine role/type/status, nine-state workflow, Lambda resources, and canonical ASL hash.

- Automatic activation now arms recovery before mutation, independently disables EventBridge and attaches/proves the exact SCP before deployment, retains both freezes through Lambda/environment/topology checks and schedule enable read-back, and detaches only after those gates. Any partial failure independently retries both containment paths; an unproven recovery exits 97.

- Translation identity is shape-bound: legacy resources require alpha-public-api-v1, v2 resources require alpha-public-api-v2, and handler settings now flow consistently through the builder, snapshot, manifest, committed result, and ledger.

- MIN_BUDGET_SCHOOL_COUNT flows into the self-contained v2 builder and is independently revalidated there.

- Step 7 binds the create-only controlled-result artifact to the independently verified live ledger across run/attempt, normal-or-recovered commit semantics, manifest identity, counts, translation version, and publication multiset counts.

- Canonical warehouse timestamps now have a real datetime round-trip regression. Both output writers have explicit fault tests for the terminal case where directory durability, unlink, and held-inode invalidation all fail: the producer always fails, and consumers are forbidden to treat residual bytes as proof without that successful producer exit.

Two audit evidence corrections are explicit. The reported verifier short-write gap was false at 55699ebc: both writers already compared file.write(...) with the exact byte length before flush/fsync/link. The residual-PASS scenario is physically possible only when every revocation I/O mechanism also fails; the disposition remains blocked/fail-closed because the producer raises and the runbook requires successful producer exit plus independent run-bound ledger verification. This matches the reviewed best-effort removal contract rather than claiming impossible filesystem guarantees. Directory-entry fsync remains required where the platform supports O_DIRECTORY; Windows uses CPython's current-user-restrictive 0o700 creation ACL.

The complete exact-tree validation passed 744 tests, current Ruff, pinned Ruff 0.15.22, Pyright with 0 errors, DDL dry run, all six extracted runbook Bash fences under bash -n, secret scanning, and diff checks. Independent activation/topology and version/threshold audits returned SAFE; independent artifact triage confirmed the producer-failure contract and the narrow controller-to-verifier binding.

## Exact-head review closure (5621502e)

Mercy review of 51f2e834 identified two remaining blockers. Exact head 5621502ed8346943697303417f62af2d75f87d6b closes both:

- After the schedule and all new starts are frozen, automatic activation polls the exact production state machine until no RUNNING execution remains. It repeats that zero-running proof after CDK diff and immediately before deployment while the proven SCP prevents any new execution from entering.

- Controlled and verifier output validation walks every existing absolute path component before token/credential access and again immediately before writing. It rejects symbolic links, Windows junctions, and all Windows reparse points. Windows output publication fails before sensitive access on Python older than 3.13, where the required current-user-only 0o700 ACL behavior is unavailable.

- Invoke preflight retains the private create/delete/directory-fsync probe before token access; its post-remote recheck is side-effect-free. Both final writers retain create-only hard-link and exact inode protections.

- Verifier reconstruction now passes the exact settings.TRANSLATION_VERSION and settings.MIN_BUDGET_SCHOOL_COUNT values into the builder.

The repeated residual-PASS finding does not change disposition: if directory durability, three unlinks, and held-inode invalidation all fail, the producer returns a generic failure and consumers must not accept the bytes. Explicit regressions cover that terminal I/O case. This is the reviewed best-effort-removal contract; no filesystem protocol can revoke an already-visible inode after every revocation mechanism is stipulated to fail. Directory-entry fsync remains enforced where O_DIRECTORY exists, as required. Complete synthetic verify() orchestration remains deferred non-fabricated test debt; live read-only verification is still mandatory.

The complete exact-tree validation passed 748 tests, current Ruff, pinned Ruff 0.15.22, Pyright with 0 errors, DDL dry run, all six extracted runbook Bash fences under bash -n, secret scanning, and diff checks. Independent activation-drain/topology and nested-path/verifier-configuration audits returned SAFE.

## Exact-head review closure (44bf8795)

Mercy review of 5621502e identified three blocking classes. Exact head 44bf8795c1772868bb3f93d27b5e990b22dc32ce closes them:

- Controlled token scanning now handles intentional bytes, bytearray, and memoryview values without treating every transport payload as a token. It scans exact compact container bytes as well as semantic strings/keys/values, detects token text spanning JSON structure, preserves exact scalar semantics, and fails closed on cyclic/non-serializable containers. getpass OSError is generic.

- Retained duplicate-name probes must now be genuinely terminal and NOT_REDRIVABLE; PENDING_REDRIVE is not accepted. Before DDL or automatic deployment, all FAILED/TIMED_OUT/ABORTED executions are paginated and described to prove none is REDRIVABLE or REDRIVABLE_BY_MAP_RUN, followed by exact zero RUNNING and zero PENDING_REDRIVE checks under the proven new-start freeze immediately before mutation.

- Pre-DDL recovery now handles every detach, duplicate-probe, IAM-simulation, and schedule-enable failure by independently disabling the rule and reattaching/proving the SCP. Unproven containment exits 97.

- All inline Python safety gates use explicit sys.exit, not optimization-removable assert.

- Fixture normalization no longer hides missing/null provenance coverage: direct production-transform regressions reject both forms.

- Migration verification owns an independent immutable 001–007 hash map. Tests mutate the settings map and separately reject missing, extra, and wrong ledger rows.

- POSIX/Windows creation-mode tests execute the real selector branch before restoring the native platform for filesystem operations.

One review evidence correction is explicit: at 5621502e, the pre-client semantic request surface used an event dict, not a byte-valued Payload, so the claim that every normal invocation already failed before boto3.client() was false. The underlying byte-support and complete serialized-surface gaps were still valid hardening defects and are now covered. AWS Lambda GetFunction does not define a top-level ExecutedVersion; the immutable numeric version is already proven through the returned qualified configuration .Version. Directory durability remains conditional on platform O_DIRECTORY, per the reviewed contract, and complete historical verify() orchestration remains deferred non-fabricated test debt.

The complete exact-tree validation passed 759 tests, current Ruff, pinned Ruff 0.15.22, Pyright with 0 errors, DDL dry run, all six extracted runbook Bash fences under bash -n, secret scanning, and diff checks. Independent byte/token, resumable-execution/recovery, and regression-independence audits returned SAFE.

## Deferred integration proof

As in #1874, destructive 005–006 rollback/restart behavior requires an authorized disposable Redshift integration environment. No mock is presented as database rollback proof, and no production DDL was run.

## 2026-09-16 exact-parent rebase and validation

This PR was rebased after PR #1876 merged. Its exact parent is current main commit e37d7d414fce709a18e624e5784ca215998d829f; exact head is c6b1fe8c02a032936727c3591bd71dd619f1e02f. The validated local route-attestation repair is included. The review diff is the 14 release-control files only (7,647 additions / 229 deletions); inherited PR #1–#3 changes are excluded.

Exact-tree validation before the guarded force-with-lease push: full test suite, current and pinned Ruff, formatting, Pyright 0 errors, immutable DDL dry run, Git diff checks, and bash -n on all six README operational fences. Fresh CI and Mercy are required for this exact head.

## 2026-09-16 timestamp-review clarification

Mercy’s only blocking report on c6b1fe8c interpreted the producer timestamp regression as accepting arbitrary Redshift readback strings. The test instead validates build_publications output after normalize_source_timestamp/normalize_provenance_snapshot_at, whose explicit canonical producer form is UTC-naive ISO microseconds with a T separator. Commit 163dbb591ff8b3eefb73c898428332c51439d833 renames the test and makes that T boundary explicit with no runtime behavior change. Focused test and complete exact-tree validation passed before push. Fresh CI and Mercy are required for this exact head.

## 2026-09-16 Yibin review closure

Exact repair head: cd4ad3cf3727fdb6c08c17d57b2277721adadef4.

The earlier timestamp-review interpretation above is superseded by captured live-source evidence: valid aware Z/offset wire timestamps are normalized; documented explicit-null official/rule-fallback snapshotAt values are preserved; missing fields, naive/invalid values, and null genuine-budget provenance still fail closed.

All four blockers are repaired:

1. captured live timestamp/null forms are accepted without weakening genuine-budget provenance;

2. verified lost-ack recovery immediately returns the frozen exact 14-key result;

3. both helper and Lambda require alpha-cp-v1-[0-9a-f]{64} before invocation/publication work;

4. verify_release requires only REDSHIFT_SECRET_ARN, while the source-fetching runtime still requires both secrets.

All four high-priority findings are also addressed or explicitly bounded:

- the helper is bound to exact function pipeline-alpha-public-api-sync-prod; the qualified IAM grant remains ephemeral and is proven/revoked inside the protected runbook block;

- controlled cutover 91 / 47 genuine / 44 fallback checks now run in the producer before publication mutation, while ordinary automatic runs retain the generic producer contract;

- the exact EventBridge route is disabled and re-attested while controlled fields exist on $LATEST, with fail-closed terminal restoration before re-enable;

- the verifier releases Redshift before remote S3/AWS calls, reopens, and requires exact ledger identity before live checks. The bounded 91-school/547-endpoint in-memory multiset verification is accepted for this first release and documented as requiring redesign before contract expansion.

Validation on this exact tree: 770 tests, current and pinned Ruff, format checks, production-module Pyright with 0 errors, immutable DDL dry run, secret/diff checks, and all six README fences under bash -n. Independent blocker and high-priority audits both returned SAFE. Fresh CI and Mercy are required for this exact head; human review remains required before merge.

## 2026-09-16 exact-head Mercy follow-up

Exact repair head: 363f60e0f247438a0f550f196dd5caa0d41e4e50.

One repeated critical claim is explicitly rejected: recovered publication_counts are variable-grain table-row counts and cannot prove unique-school genuine-source coverage. The frozen 14-key lost-ack result proves durable publication identity; manifest/ledger/live-table release verification supplies the later coverage proof. Requiring invented row-count equalities in recovery would be incorrect and would violate the reviewed frozen contract.

Concrete exact-head findings were repaired:

- Step 1 now uses set -euo pipefail, selects and records the exact PR4 commit before validation, rechecks an unchanged clean head, and tags that exact SHA only after all gates pass.

- All three duplicate-name authorization probes use structured boto3 ClientError fields and require exact AccessDeniedException, states:StartExecution, and the exact state-machine ARN; generic stderr is no longer evidence.

- Automatic-activation containment attaches and proves the prevalidated SCP independently of later policy-readback failure; EXIT recovery independently disables the schedule, attaches/readbacks the SCP, and proves the exact structured denial or exits 97.

- Canonical alpha-cp-v1-[0-9a-f]{64} strings and substrings, including decoded JSON and intentional binary container values, are rejected recursively before work even when controlled settings are unconfigured.

- A handler-level regression restores the real controlled release-count validator and proves rejection before snapshot/publication mutation.

- Release verification requires ledger published_at/committed_at, manifest generated_at, and snapshot fetched_at to be canonical and no older than 24 hours (with at most five minutes future skew).

Exact-tree validation passed: full tests, current and pinned Ruff, formatting, production-module Pyright with 0 errors, immutable DDL dry run, secret/diff checks, and all six README Bash fences. Independent runbook and code audits both returned SAFE. Fresh CI, Mercy, and human review remain required; this PR must not be merged by automation.

## Summary

- Migrate the Aerie retention consumer to the accepted rolling SIS projection contract from PR #1873

- Fail closed on exact roster manifest, terminal cycle, freshness, identity, coverage, unresolved state, population regression, and atomic lineage

- Keep the dataset trigger, on-demand admission, and runtime activation flag disabled

## Why

The retention mart still reads the legacy staging_education_sis snapshot contract. The rolling SIS producer now exposes a versioned summary.accepted_projection contract that pins the parent roster run, terminal cycle, and immutable roster manifest. This change makes retention consume that explicit boundary without activating or invoking it. It follows the consumer patterns established in #1875 and #1879 while retaining the existing retention calculations.

## Business Value

Retention reporting can move to the supported rolling SIS projection with explicit, auditable source lineage and fail-closed publication controls. Existing report semantics remain unchanged, and activation remains a separate release decision.

## Breaking changes

The warehouse procedure gains terminal-cycle and roster-manifest parameters, and the DDL adds mart_education.aerie_retention_publication for exact publication lineage. A controlled DDL apply and catalog verification are required before any later activation. The three consumer mart table shapes do not change.

## Test plan

- [x] uv run pytest -q — 94 passed

- [x] uv run ruff check . and uv run ruff format --check .

- [x] CDK pipeline schema and real-config suites — 637 passed

- [x] npm run build

- [x] Seven-lane adversarial review; corrected stability, performance, data-health, blast-radius, and usability findings

- [ ] Merge producer PR #1873 before this PR

- [ ] Apply and verify DDL in a controlled environment in a separate authorized release step

- [ ] Enable runtime admission and the desired trigger in a separate activation PR

No deployment, invocation, DDL execution, merge, or warehouse write was performed.

## Summary

- Move the current enrollment refresh to the accepted rolling SIS projection contract

- Add fail-closed freshness, coverage, regression, and population-collapse safeguards

- Record exact publication lineage for safe timeout recovery and rollback

## Why

The current enrollment fact still depends on the legacy SIS staging source. Producer PR #1873 is now merged, and the rolling SIS producer exposes a versioned accepted projection. Core must validate that exact contract and preserve the previous publication whenever the candidate projection is incomplete, stale, regressive, or anomalously small.

Activation is not included. Shared run-result/event provenance, direct state-machine start access, scoped producer event permission, and exact-parent redelivery remain explicit pre-DDL or activation gates.

## Business Value

Enrollment reporting can move to the rolling SIS source without allowing degraded source data or an ambiguous retry to replace the last trusted Core publication.

## Breaking changes

None. The existing fact-table contract is unchanged, and all automatic triggers remain disabled pending separately approved producer deployment, DDL, and activation gates.

## Test plan

- [x] 54 focused enrollment tests

- [x] 23 merged-producer projection contract tests

- [x] Ruff lint and format

- [x] 576 targeted CDK tests

- [x] TypeScript build

- [x] 77 on-demand control tests

- [x] Hosted CI and Mercy on exact rebased head

## Summary

- Add regression coverage for toast descriptions and targeted dismissal.

- Clear the toast store after each test to keep tests isolated.

## Why

The original #1247 toast fix mounted the outlet in AppShell. Main already mounts it in the root layout through #1218 (c20d7cff0), so applying that runtime change would render duplicate notifications. This slice preserves the remaining useful test coverage without adding another outlet.

## Business Value

Protect existing notification feedback from regressions without changing application behavior.

## Test plan

- [x] 35 toast and desktop/mobile shell tests pass.

- [x] Full repository lint.

- [x] Chat TypeScript and Convex typechecks.

- [x] All required hosted CI checks pass at 024305c56 (run 35136121519).

- [x] Seven-lane adversarial review: no findings.

- [x] Mercy approved this exact head with no findings (run 35136458051).

Tests only; no visual or runtime changes. During final #1247 reconciliation, drop its AppShell toast mount and mount assertion as superseded by the root-layout implementation.

## Summary

- Consume merged producer PR #1873's version 1 accepted_projection as the only SIS acceptance contract

- Pin the rolling roster, immutable manifest, terminal cycle, projection objects, and acceptance accounting to its canonical identifiers

- Keep all declared triggers disabled while retaining independent warehouse freshness, coverage, lineage, and reconciliation checks

## Why

The generic dataset trigger forwards the producer event's detail.run_id, which is the parent SIS run ID. Reconstructing acceptance from raw rolling summary fields or terminal-cycle outcome counts would duplicate producer policy and could drift from the canonical contract. This consumer now loads that parent's S3 run result, fails closed unless summary.accepted_projection is the supported version 1 contract, and uses its parent_run_id, equal roster_run_id, and terminal_cycle_id.

This replaces the prior frozen staging_education_sis assumption with the supported mixed-cycle projection in staging_education_ai_horizons_old without treating unavailable detail as withdrawal or deletion.

## Business Value

School-year snapshots can adopt the rolling SIS source with explicit, immutable lineage and a single acceptance authority. Automatic activation remains separate, so this PR cannot start the consumer trigger when it is deployed.

## Test plan

- [x] Rebased onto producer merge 399257ce

- [x] 64 focused runner tests

- [x] Ruff check and format for changed Python files

- [x] 576 targeted CDK construct and real-manifest tests

- [x] Fresh hosted CI passed at 80381744

- [x] git diff --check

- [ ] Resolve Mercy's two blocking data-integrity findings

- [ ] Apply and verify the procedure DDL in a controlled non-production Redshift environment

- [ ] Approve and implement trigger activation as a separate release decision

## Summary

- Enable the daily Finalsite Billing mart refresh in a clear source-publication window

- Pin publication to a recent complete full-estate billing run and fail closed on stale, incomplete, or invalid inputs

- Add an OM-owned procedure-only deployment path and documented recovery contract

## Why

The upstream Finalsite Billing raw pipeline is active, but the downstream mart schedule remained disabled. Enabling the original fixed schedule without additional guards could also report success from stale or partially advanced inputs. This change closes both gaps before automated publication.

## Business Value

CFO billing questions can use automatically refreshed Finalsite Billing marts while the last accepted mart remains visible when source freshness or validity is insufficient.

## Test plan

- [x] 31 mart runner tests passing

- [x] 545 real pipeline configuration tests passing

- [x] Seven-lane adversarial review completed and findings remediated

- [x] OM-owned procedure-only production apply succeeded

- [x] Hardened production scheduled-path canary succeeded

- [x] Live EventBridge schedule enabled at 14:55 UTC and target verified

## Summary

- Migrate the Aerie SIS organization directory to the AI Horizons bulk organization publication

- Preserve fail-closed publication, manifest, lineage, uniqueness, and row-count validation

- Keep the consumer trigger and automatic activation disabled

## Why

The directory still reads the frozen staging_education_sis organization projection. The SIS producer now publishes the source under staging_education_ai_horizons_old, so this consumer needs a deliberate contract cutover without treating detail-projection readiness as a bulk-organization signal.

## Business Value

Aerie organization mappings can follow the maintained SIS publication while retaining the safeguards that prevent incomplete or ambiguous source generations from replacing trusted directory data.

## Breaking changes

None. Automatic activation remains disabled and deployment requires the producer dependency plus controlled cutover validation.

## Test plan

- [x] 35 focused runner tests

- [x] Ruff lint and formatting

- [x] 529 real pipeline-config tests

- [x] CDK TypeScript build

- [x] Seven-lane adversarial review with no remaining findings

- [ ] Hosted CI and Mercy on the exact PR head

## Summary

- Move Person student and teacher inputs to the independently published AI Horizons bulk contract

- Preserve fail-closed publication, manifest, count, identity, freshness, and replay lineage checks

- Add a read-only SIS pin preflight while keeping the runner and all automatic triggers disabled

## Why

The Person directory still read the frozen staging_education_sis namespace even though the supported bulk students and teachers producer now publishes to staging_education_ai_horizons_old. This consumer needs the paired bulk publications, not PR #1873's rolling student-detail accepted_projection contract used by detail-dependent consumers in PRs #1875 and #1879.

The migration pins one publication run for both bulk objects, retains the original source run across replay, rejects missing or ambiguous per-object ledger lineage, and makes ambiguous live profile lineage unavailable instead of allowing duplicate profile or role rows.

## Business Value

The Person cutover can use the supported AI Horizons bulk source without coupling identity refreshes to student-detail completion or allowing mixed, stale, incomplete, or weakly evidenced SIS data to replace the current directory.

## Test plan

- [x] 31 focused Person runner tests

- [x] Ruff 0.15.22 check across pipelines

- [x] Ruff 0.15.22 format check across pipelines

- [x] git diff --check

- [x] Seven-lane adversarial review; concrete findings corrected and re-reviewed

- [ ] Hosted CI and Mercy on exact PR head

- [ ] Controlled Redshift compile/runtime validation before any DDL application

No deployment, pipeline invocation, DDL application, warehouse write, merge, trigger, schedule, or activation is included.

## Summary

- Remove unreachable legacy Context, sidebar, admin-builder and expense UI with their obsolete tests.

- Preserve shared Forge controls and add direct proposal and ownership coverage on the live surfaces.

- Align legacy Context navigation with Forge and remove dead Platform Error coverage references.

## Why

The retired UI remained in the repository after its routes and callers moved elsewhere. Its tests maintained obsolete behavior and gave misleading coverage. This independent slice of #1247 removes those implementations while keeping coverage for behavior that still exists.

The Context redirect and device-authorisation route remain. Prompt runtime/schema retirement, toast behavior, API refactoring, Preview verification, System Health and Person work are excluded. Newer main changes are preserved.

## Business Value

Reduce misleading code and test maintenance without removing active product capabilities.

## Test plan

- [x] 456 related tests: shell, Forge/Context controls, redirects, device authorisation, monitoring builder and Platform Error inventory.

- [x] All workspace typechecks and full repository lint.

- [x] Import/caller audit and no remaining references to deleted file paths.

- [x] Seven-lane adversarial review; corrected obsolete Prompts/Sidebar smoke instructions. No remaining confirmed findings.

- [x] All required hosted CI checks pass at 91a3ff785 (run 35133867973).

- [x] Mercy approved 91a3ff785 with no findings (run 35133878042).

- [ ] Live browser smoke not run; no active UI redesign is intended.

The removed files remain recoverable in Git. #1247 still contains duplicate changes and must not merge alongside this slice.

## Summary

- Add a versioned accepted projection contract to terminal AI Horizons rolling parent results

- Prepare a distinct student_detail_projection dataset event with stable parent, roster, and terminal-cycle identity

- Keep legacy detail events, EventBridge permission, and automatic projection activation disabled

## Why

Downstream consumers need a stable producer-owned boundary for the rolling student-detail projection. The immutable roster manifest and existing rolling_detail_cycles ledger already contain the required evidence, but the parent result did not expose them as one accepted contract and the only existing event identity belonged to the legacy full-generation detail path.

## Business Value

Consumers can adopt the rolling projection deliberately, validate exact lineage and coverage, and avoid treating mixed-cycle current state as a legacy full snapshot. This preserves the frozen legacy schema and prevents an accidental Core activation.

## Test plan

- [x] SIS runner suite: 272 passed

- [x] Ruff 0.15.22 check and format check across pipelines

- [x] Pipeline CDK TypeScript build

- [x] Real pipeline-config Jest suite: 545 passed

- [x] Seven-lane adversarial review; all pre-merge findings resolved

- [x] Confirm no Core or mart consumer references student_detail_projection

## Summary

- Revert the all-nine Finalsite publication gate introduced by PR #1843

- Restore the established contacts publication and complete site-boundary validation

## Why

PR #1843 responded to a failure caused by the temporary capture_complete producer outcome, but it changed the downstream snapshot contract instead of fixing that outcome mismatch. PR #1864 subsequently restored the canonical complete outcome and normalized warehouse history.

The later #1843 merge duplicated the producer publication contract and assumed every destination name was raw_ plus the source name. That assumption is false for contact_detail, which publishes to raw_contact_details, so every real Finalsite delta now fails before the snapshot procedure runs. This revert removes the unrelated gate and preserves the producer-side fix from #1864.

## Business Value

Restores automatic Finalsite student school-year snapshot refreshes while preserving the prior fail-closed contacts and site-boundary checks. The previous Core snapshot remains intact; this change allows fresh accepted publications to advance it again.

## Test plan

- [x] 54 core-education-student-school-year-snapshots tests passing

- [x] Ruff 0.15.22 lint passing on affected Python files

- [x] Ruff 0.15.22 format check passing on affected Python files

- [x] git diff checks passing

- [ ] Deploy after merge and verify the next non-freshness-check Finalsite delta appends a snapshot and refreshes Student identity

## Summary

Make stale section-identity repair repeat-safe while preventing Coach Claire and every add-on mutation path from treating the leading plan-title H1 as a writable section.

## Problem

Two issues combined in Central SaaS:

1. A legacy BBOT_SEC::<section_id> body marker had collapsed after structural Google Docs edits. The add-on failed closed with section_identity_stale, but the existing Editor-approved repair picker did not accept that status.

2. The affected session also contained a legacy pseudo-section for the leading SaaS Q4 2026 Plan H1. applySection uses heading hierarchy boundaries, so rewriting that H1 could replace every nested H2/H3 section through the next H1 or end of document.

Refresh Data was healthy and unrelated. Reloading does not repair identity metadata. The unsafe root marker was removed from the live document with revision CAS and verified with no content change, returning the current release to fail-closed behavior.

## Changes

### Protect the document root

- Classify only the leading plan-title H1 as document presentation/container metadata. The predicate requires H1 plus first-section position plus either an exact Drive-title match or the canonical Qn YYYY Plan suffix.

- Exclude that root during prior-quarter clone construction so new sessions do not store it in spec.sections or generated_sections.

- Exclude it from canonical add-on projection and ignore its legacy anchor while reconciling, so existing sessions migrate the pseudo-section out instead of resurrecting or blocking on it.

- Exclude it from identity-repair candidates.

- Reject it with section_target_protected at the shared client resolution boundary before marker maintenance or body writes. This covers read/apply/add-anchor/remove/rename paths, including stale sessions.

- Preserve legitimate non-title H1 content sections. Canonical Budget Bot content sections remain H2/H3.

### Repair stale real sections

- Treat section_identity_stale as eligible for the bounded, Editor-approved identity-repair picker for already-covered operations.

- Preserve exact-title candidate matching, explicit Editor selection, live revalidation, the single-writer queue, and exactly-once seed/retry bounds.

- Continue excluding rename and add-section repair flows, which have different recovery semantics.

- Replace inaccurate “Refresh or reopen” guidance with repair-card guidance.

## Safety

- The plan-title H1 cannot be offered as a repair target or pass the final client write gate.

- Existing sessions lose the root pseudo-section only after canonical reconciliation; real H1/H2/H3 content sections remain.

- No automatic target guessing.

- No repair without a valid section ID, covered operation, exact candidate, and Editor selection.

- No repeated repair or proposal replay.

- The route test proves /addon/propose returns 404 for a root removed by reconciliation and never invokes regeneration.

## Validation

- Full Apps Script suite: 377 passed.

- Focused clone/projection/reconcile Python tests: 83 passed.

- Add-on propose route tests: 19 passed.

- Ruff check and format check: passed.

- git diff --check: passed.

- Full Board Doc Python suite: 5,048 passed, 2 deselected.

- Repository-wide collection outside Board Doc still depends on unavailable local third-party credentials; CI remains authoritative for those suites.

## Release note

This now changes both the backend reconciliation/session model and Apps Script. After merge it requires:

1. a production backend deployment, and

2. a new immutable Apps Script version plus Marketplace publication.

Marketplace version 9 remains unchanged until private validation is complete.

## Summary

Third PR in the source-only Alpha replacement stack. This adds immutable attempt evidence and atomic Redshift publication on top of #1874.

Stack order:

1. #1872 — lossless API contract and transforms

2. #1874 — trusted physical schema and migration installer

3. this PR — atomic publication and recovery

4. follow-up — release verification and activation controls

## Publication contract

- Lands every HTTP attempt immediately with exact raw bytes, selected safe headers, status/error identity, retry number, and create-only S3 writes (IfNoneMatch="*").

- Uses injective bounded base64url run/attempt key segments and full 128-bit UUID attempt identities.

- Lands /schools before availability, shape, or volume validation.

- Requires exact endpoint-slot and terminal-attempt evidence cardinality before publication.

- Persists snapshot and manifest evidence before Redshift replacement and binds the manifest SHA-256 into the durable ledger.

- Stores no plaintext exception message in failure markers and excludes credential-bearing response headers.

## Atomicity and concurrency

- Captures a current-publication CAS token before source fetch.

- Acquires the writer lock before any data/catalog read in the write transaction (after only the bounded timeout control).

- Re-reads exact queryable publication identity under the lock across all current data tables, including legacy-v1 cutover state.

- Rejects changed/mixed heads and all existing run/attempt identities. Redshift informational constraints are not trusted for collision safety.

- Replaces all snapshot tables and inserts both ingestion_ledger and publication_attempts records on one cursor and transaction.

- On ambiguous commit acknowledgement, opens a fresh connection and accepts success only for the exact (run_id, attempt_id, manifest_sha256) tuple; recovery always rolls back and closes.

- Normal and recovered success return the same durable attempt/manifest identity.

## Scope exclusions

This PR does not modify DDL, the installer, schema_contract.py, settings.py, pipeline.json, scheduling, publication mode, controlled tokens, deployment, or production data. Activation controls remain PR4 work.

## Validation

- pytest -q: 408 passed

- current Ruff check and format: passed

- pinned ruff==0.15.22 check and format: passed

- scoped Pyright: 0 errors / 0 warnings

- native git diff HEAD --check: passed

- independent evidence review: SAFE

- independent DB/transaction review: SAFE

No Alpha DDL was applied. No production runner was invoked. No data was published and no schedule or activation setting was changed.

## 2026-09-16 exact-parent rebase

This PR was rebased after PR #1874 merged. Its exact parent is current main commit a22200dce4a9223b3470d80afe7cbb60200961aa; exact head is 6007e3f43006f4b16fb0b898dc34334089abaacd. The review diff is now only the six atomic-publication files (2,761 additions / 157 deletions), with inherited PR #1/#2 changes excluded. Full exact-tree validation passed before this guarded force-with-lease push. Fresh CI and Mercy are required for this head.

## Summary

Stack 2 of 4 replacing #1833. Base: #1872.

This PR installs the Alpha physical schema and a fail-closed privileged migration runner:

- additive migrations 002–005 retained byte-for-byte with their canonical LF hashes

- forward migration 006 widens all 16 externally sourced measures to exact NUMERIC(38,18) while sheet_row remains NUMERIC(18,6)

- publisher-independent schema_contract.py for exact tables, columns, types, nullability, ordinals, and numeric scales

- runtime pinning of the exact ordered migration filename/hash manifest

- Data API page/terminal error rejection and corrected Redshift privilege SQL

- every pre-existing schema_migrations ledger is reconstructed from the exact physical catalog phase before rows are read

- reconstruction is locked and re-proves the exact catalog phase inside the same transaction before destructive ledger replacement

- migrations 004–007 execute as one bounded 40-statement atomic batch

- migration 004 is gated after locks by bidirectional raw-SUPER versus typed sheet_row identity proof; budget tables must still be empty

- immutable migration 005 is bracketed by pre-rebuild grouped-multiset snapshots and a bidirectional post-rebuild assertion

- migration 006 independently proves exact grouped multisets before dropping originals

- exact pre/post ACL and owner assertions reject unexpected principals, privileges, defaults, dependencies, inbound constraints, RLS, or masking metadata

- forward migration 007 transfers the schema and all 11 mutable data tables to a distinct disabled-login schema owner

- the disabled ledger owner retains only the three immutable ledgers; runtime retains bounded DML/USAGE but no schema CREATE

- phase 6 versus 7 inference and transaction-local reproof include exact owners and effective runtime schema privileges

- final verification rejects unexpected base tables and exact ACL/owner drift

## Safety / stack boundary

This is source-only. No DDL was applied, no Alpha runner was invoked, no data was published, and no production configuration or schedule was changed.

This PR does not add the v2 publisher or activate publication. Those remain in stacks 3 and 4. The current handler remains on the legacy v1 path.

Stack order:

1. #1872 — API contract and lossless transforms

2. this PR — physical schema and trusted migration installer

3. atomic evidence/publication and recovery

4. release verification and activation controls

Migrations 001–005 remain immutable:

- 001 4209c2ee3bff34e4c5df0ec6d67873528b3451b3e8d13d99414d8110acef56a0

- 002 088a8d0b55c2c983e7594a24acdea18b4177839337260b24a70b01886a7a9d4d

- 003 2b63c7e641d556374b90f079cb7f201842db765ac8e6f77b927396cf137b3538

- 004 142aae9c83b5468bfe83e4806bed7c2997b8fb13390c9e0d88beb96227d475da

- 005 1dbd829cd2cb1941d9036a0d9fcc669365bac1a5464635d2c3ce28efe1263bb8

Forward migrations:

- 006 f8e5085a520060218159edefe38657dc28ec8c90cb0280dc584e7cbbf1c703c8

- 007 b3f523a63f3521cdcba322eeb78b68c29d153465b34de2e3bbb8878851f22ba8

## Validation

- rebased full runner pytest: 323 passed

- current Ruff lint/format: passed

- pinned ruff==0.15.22: passed

- scoped Pyright: 0 errors, 0 warnings

- seven-migration dry run: 79 statements

- 004–007 atomic installer batch: exactly 40 statements, within the Data API bound

- native Git diff checks: passed

- independent post-repair review: SAFE TO COMMIT

- read-only Redshift catalog grammar checks passed:

- dependency/RLS/masking: 71ec1266-ef44-4d41-88d4-8cd5dae5d8f0

- inbound-FK predicate: 44d313de-45a2-4b62-b334-2fc849db4236

- symmetric parenthesized EXCEPT: fe52e642-0e7a-4d32-a958-33f22b0fa1e2

- full generated phase predicate: 650237bd-8f7f-48e2-bd89-280e5b9b5fc5

Additional read-only Redshift grammar/evidence checks:

- pre-004 exact generated identity predicate: 1a9ea805-2307-4a24-9bc4-d6ac5b6c6d58

- phase-6/7 typed ownership predicate: d4dbbdb7-9f6a-497f-a38a-b7cf75086eed

- schema-owner ACL postcondition predicate: 35a53848-5dfb-468b-aac5-690f1678227f