fix: allow conserved multi-match reconciliation approvals

[seonghobae]

Buyer outcome

Harden authoritative bank reconciliation and close evidence while preserving AIS as the accounting system of record. Bank statements remain immutable non-posting evidence; reconciliation cannot post/reverse journals, close periods, or alter accounting policy.

Exact current state — 2026-09-09

• root head: 12e1a4bb9d8de5e4b6c72e2893107b07c515416b;
• protected base: develop@239008c4edc7d305c97704c5102b593c6622b36f;
• open / Draft / mergeable / not merge-ready;
• feat(reconciliation): add evidence-derived run lifecycle command #43 is merged history inside this root through ordinary non-force composition;
• exact-root Accounting Foundation 34173498502 is GREEN on real PostgreSQL, complete owned statement/branch coverage, repository contracts, compile/import and reproducible package; same-head dependency diff/security/SAST are GREEN;
• required root CodeQL 34173498486 remains terminal RED at the central current-generation receipt/dispatch publication boundary owned by .github, not from an AIP source-analysis finding;
• no qualifying independent current-root APPROVED review exists.

Integrated lifecycle authority

The root contains the supported tenant-scoped idempotent reconcile_reconciliation_run() path. It admits the database lifecycle session lease before a fresh REPEATABLE READ authority transaction, derives review controls and the exact book-to-bank bridge from PostgreSQL-owned evidence, persists database-owned transition identity/hash, and atomically commits transition command, reconciled status and the matching transactional-outbox event. Direct SQL status mutation is not an alternative authority path.

Dependent maker-checker lane

Current child is #47@263e4ffb79607dccee715686d0aa451981c2eeb8, targeting this exact root, open/Ready/mergeable. Root migrations remain 0019/0020/0021; #47 owns 0022..0030. #53 remains dependency-blocked and must not be restacked until #47 is normally integrated and the resulting parent head is reverified.

Fresh review on predecessor #47 found the P1 stale-session-lease continuity defect. The ordinary TDD lineage is 4e301153... real PostgreSQL attack RED → 24c8ca34... transactional lease invalidation plus exact-lease SELECT ... FOR UPDATE freshness repair → 55c0d65f... / current 263e4ff... code-current ADR/doctoring. FORCE RLS, command/status/outbox invariants, maker-checker separation and PUBLIC helper revocations remain intact.

Exact #47 Accounting Foundation 34237450022 is terminal GREEN on unchanged 263e4ff...: Accounting 102098735789 ran 1,315 real-PostgreSQL tests / 0 failures / 0 errors, with 6,211/6,211 statements and 2,330/2,330 branches, repository contracts, compile/import and reproducible package/evidence GREEN. Security 102098735619, SAST 102098735914, dependency diff 102098735946 are GREEN; integrated-head attestations are correctly skipped while stacked. Retained artifacts are behavior 10061043416 (sha256:efd4e6f9...24e09), coverage 10061189106 (sha256:c33ae1a3...ac81), package/evidence 10061193521 (sha256:2bfd0539...2de7), dependency diff 10060933382 (sha256:6ba6073d...751f). The P1 thread is resolved from hosted PostgreSQL evidence. Fresh CodeRabbit exact-head review 5586974629 found no current actionable defect in the requested lifecycle/accounting-authority/security boundaries but explicitly is not an approval.

Effective dependent stack is #29@12e1a4b... -> #47@263e4ff... -> #53. #43 remains merged history.

Separate DDD architecture lane

#41 is exact 3bdbeec6cc35e5b111739499c562f988f5fcaa18, targeting this exact root, open/Ready/mergeable after the stale physical-owner-row repair reacquired complete exact-head evidence. The TDD lineage b2fd20fb... rejects ownership rows for absent files/directories, 5e8f8a06... removes deleted reconciliation_completion.py from current physical ownership, and 3bdbeec... makes the #41-owned doctoring/regression contract code-current without moving runtime authority.

Accounting Foundation 34239818457 is terminal GREEN on unchanged 3bdbeec...: Accounting 102106807702 passed behavior/repository, complete owned statement/branch coverage, strict denominator, repository contracts, compile/import and reproducible package/evidence; Security 102106807452, SAST 102106807652 and dependency diff 102106807711 are GREEN. Retained evidence is behavior 10061809339 (sha256:90f4b2cb...573cc), coverage 10061915751 (sha256:0775fd1c...46995), package/evidence 10061921252 (sha256:377fe47e...3d0a6) and dependency diff 10061846663 (sha256:4433ebe9...75d2d). Integrated-head attestations are skipped because the stacked head is not protected integration evidence. No qualifying independent APPROVED review exists.

All current #41 review threads are resolved. The ADR 0059 shared CHANGELOG.md / docs/doctoring/STANDARD_TRACEABILITY.md finding was not silently waived: it is explicitly transferred to canonical single-writer #37@bdf076466b1cde0e7ae6247f44309fac153ae4c4. #41 remains Proposed; after protected #41 integration, #37 must rebuild on that exact authority and record ADR 0059 / Context Map / UL provenance before #37 can merge.

Central CodeQL owner path

The historical root required run 34173498486 is retained as exact evidence but is not rerun as a substitute for a newer central workflow definition. Protected central authority is .github/main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db after #2028.

The current canonical combined central repair is .github#2040@6706c231ab06a3c91c43fdb5b989cfcd79fff593, Ready/mergeable on that protected base. Its exact-head Runtime Quality 34251822381, Security 34251822390, SAST 34251822314, and Python Security 34251822251 are terminal GREEN, while required CodeQL 34251822255 is terminal RED. Actions receiver 102154521648 and Python receiver 102154523061 fail current-head verdict enforcement, then coordinator 102154736341 fails before dispatch with CodeQL coordinator could not bind every pending language to an exact failed job.

The canonical central owner has already classified that current P1 as a bootstrap evidence/settlement incompatibility: protected pre-cutover main@7fd571... publishes legacy unbound codeql-dispatch/<language> evidence/title, while the repaired producer correctly requires base/source-bound evidence; repeated per-language wake has fragmented one required run across attempts. That must be repaired centrally without accepting legacy head-only evidence or weakening exact repository/PR/base/head/language/required-run/SARIF provenance. .github#1902 remains Draft/mutable, so AIP does not copy either mutable central branch or create a competing leaf workflow fix.

No historical AIP CodeQL rerun, synthetic status, no-op leaf commit, Draft/Ready churn, leaf PAT, gate weakening, or manual evidence substitution is an accepted recovery path. Root integration waits for ordinary central repair and a genuinely fresh required-workflow generation.

Accounting authority

Authority-bearing close construction derives locked run status/scope/currency/cutoff, retained statement artifact and balances, admitted statement entries, posted cash-journal population, complete approved matches/approvals/allocations/exceptions, deterministic population identities and exact Decimal book-to-bank bridge from PostgreSQL-owned evidence. Caller-shaped balances, populations, state labels, tenant identities and bridge amounts are not authority. Billing remains authoritative only for usage/rating/invoice/payment/refund/dispute/provider-settlement commercial truth and interacts through released/versioned event/API/ACL boundaries; cross-service SQL and mutable sibling dependency are prohibited.

Merge / release boundary

Keep this root Draft. Required central root CodeQL terminal evidence and qualifying root review are absent. #47 has exact-head hosted GREEN and fresh clean current-head review but still lacks qualifying independent approval before normal integration. #41 has exact-head hosted GREEN and all threads resolved, but still lacks qualifying independent approval; its shared-record requirement is transferred to #37's post-integration rebuild rather than duplicated here. Do not self-approve, bypass, force-push, destructively rebase, synthesize status, restack #53 early, duplicate #37-owned shared documentation, tag or release.

[coderabbitai]

📝 Walkthrough

Walkthrough

이 변경은 조정 도메인에 실행 명령 증거, 은행 잔액 증거, 다중 승인 매치 보존, 승인 스냅샷 잠금 수리, 구조화된 close-review 증거, 권위 있는 close-package 재검증, 관련 HTTP/API 공개면, 마이그레이션 로더, 문서, 회귀 테스트를 추가합니다.

Changes

조정 통제

Layer / File(s)	Summary
원천 및 실행 증거 database/migrations/0018_bank_statement_balance_evidence.sql, database/migrations/0019_reconciliation_run_command_evidence.sql, src/accounting_information_platform/bank_statement.py, src/accounting_information_platform/reconciliation_run.py, src/accounting_information_platform/http_api.py, src/accounting_information_platform/persistence.py, tests/test_bank_statement_*, tests/test_reconciliation_run_*	bank_statement_balance와 reconciliation_run_command 저장 구조를 추가합니다. 은행 잔액 정규화, 레거시 재생, canonical UTC cutoff, run 멱등성, provenance 검증, POST/GET /reconciliation-runs, 로더 설치 순서와 관련 회귀 테스트를 추가합니다.
다중 매치 및 승인 스냅샷 database/migrations/0015_reconciliation_multi_match_conservation.sql, database/migrations/0016_reconciliation_approval_evidence.sql, database/migrations/0017_reconciliation_approval_lock_order.sql, src/accounting_information_platform/reconciliation.py, tests/test_reconciliation_*approval*, tests/test_reconciliation_*allocation*, tests/test_reconciliation_*conservation*, tests/test_reconciliation_*lock_order*	단일 승인 제한을 제거하고 source-capacity 보존, candidate pairing, append-only 후보·할당, 승인 증거, 스냅샷 버전 1/2, parent-row-first 잠금 순서, 연결 그래프 검증, terminal 상태 제약을 데이터베이스에서 강제합니다.
close-review 및 close-package src/accounting_information_platform/reconciliation_bridge.py, src/accounting_information_platform/reconciliation_read_model.py, src/accounting_information_platform/reconciliation_close_package.py, src/accounting_information_platform/__init__.py, tests/test_reconciliation_close_review_*, tests/test_reconciliation_close_package_*, .github/workflows/tmp-pr29-authoritative-bridge*	ReconciliationReviewedMatch와 allocation evidence를 close-review 입력과 출력에 추가합니다. exact Decimal 합산, source capacity 검증, schema v2/v3 projection, schema v4 close package, database-owned run/match/exception 재검증, 내부 테넌트 스냅샷 바인딩, 권위 있는 모집단 로더와 관련 테스트를 추가합니다.
계약, 설치 및 문서 CHANGELOG.md, README.md, docs/ARCHITECTURE.md, docs/DATA_MODEL.md, docs/ERD.md, docs/OPERABILITY.md, docs/TEST_STRATEGY.md, docs/adr/*, docs/doctoring/*, docs/product-technical-gap-baseline.md, scripts/validate_repository.py, tests/*documentation*, tests/test_postgres_runtime_rls.py	문서는 0015~0019 마이그레이션, run API, 잔액 증거, close-package 권위 경계, RLS, PostgreSQL 버전, reversal 설명, product baseline을 반영합니다. 저장소 검증과 문서 계약 테스트도 같은 범위로 갱신합니다.

Estimated code review effort: 5 (Critical) | ~120 minutes

Merge Risk: 🟠 High · up to a9bec

This PR changes authoritative close-evidence construction and adds temporary branch-writing workflows. At the current head, close evidence can be assembled from inconsistent database snapshots, journal evidence is not explicitly constrained to the owning accounting book, and repository-controlled code runs with a persisted repository-write credential; these correctness and security risks must be fixed and verified in the reviewed commit before merge.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant HTTP as http_api
  participant Run as reconciliation_run
  participant DB as PostgreSQL
  Client->>HTTP: POST /reconciliation-runs
  HTTP->>Run: accept_reconciliation_run(...)
  Run->>DB: validate command and resolve statement binding
  Run->>DB: insert reconciliation_run + reconciliation_run_command + evidence
  DB-->>Run: persisted run document
  Run-->>HTTP: evaluating run
  HTTP-->>Client: response

Loading

sequenceDiagram
  participant Builder as close_package builder
  participant DB as PostgreSQL
  participant Review as close_review projection
  participant Package as close_package
  Builder->>DB: load run, command, artifact, matches, exceptions
  DB-->>Builder: database-owned evidence
  Builder->>Review: validate scope, cutoff, reviewed matches, bridge
  Builder->>Package: build canonical payload
  Package-->>Builder: sha256 digest

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 56.87% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 517 functions across 61 files. (3 skipped…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	제목은 보존 규칙을 적용한 다중 매치 조정 승인을 허용하는 핵심 변경을 정확하고 간결하게 설명합니다.

Full details: Docstring Coverage

Explanation

Docstring coverage is 56.87% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 517 functions across 61 files. (3 skipped: 3 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/reconciliation-multi-match-conservation

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

Current-head CI failure is source-real but occurs before the new conservation guards run. In Accounting Foundation CI run 33073685926 / job 98522218358, both test_two_independent_matches_can_be_approved_in_one_run and test_approved_matches_cannot_overconsume_one_statement fail when the second approved reconciliation_match is inserted because PostgreSQL still has reconciliation_match_approved_single from migration 0014. The exact checkout is 52416a10227bf25ea43d16eff4cee25256536b3a.

The first causal boundary is the foundation migration loader split, not the 0015 conservation SQL itself: tests/test_postgres_posting.py intentionally initializes the real PostgreSQL catalog through accounting_information_platform.persistence.apply_foundation_migration, and that canonical chain still stops after 0014_reconciliation_candidate_allocation.sql. This PR changed migration_install.apply_foundation_migration into a wrapper that applies 0015 afterward, so public-wrapper callers and the durable foundation path now install different schemas.

Narrow repair: keep one authoritative install chain. Extend persistence.apply_foundation_migration through append-only migration 0015 and keep migration_install.py as the public alias/thin boundary rather than a second migration executor. Do not make the PostgreSQL test import the wrapper merely to turn it green; that would leave internal/operational callers able to stop at 0014. Strengthen test_foundation_install_manifest_contract.py so missing 0015 fails closed on the canonical loader.

The same current head also leaves canonical install metadata stale: docs/OPERABILITY.md still says/apply-through 0014, and scripts/validate_repository.py::REQUIRED_FILES does not require 0015. Update OPERABILITY/ARCHITECTURE/required-file contracts together with the loader, then rerun the failed PostgreSQL boundary before full 100% coverage/package/SBOM/provenance gates. Keep this PR Draft until that exact-head proof exists.

[seonghobae]

Current-head review on dccc6737abf043962aea132e56b112626a89eeb9: the canonical-loader/install-contract defect is repaired and repository-owned exact-head CI is green, but migration 0015 still scopes allocation conservation to a single reconciliation_run_id. Both reconciliation_allocation_conservation_guard() and reconciliation_match_approval_conservation_guard() derive capacity and consumed amount with WHERE ... reconciliation_run_id = NEW.reconciliation_run_id, and the advisory-lock key also includes the run id. A second non-superseded run can therefore approve the same immutable statement_entry_reference or journal_reference again without seeing consumption from the first run.

That violates Issue #8's source-consumption invariant: a consumed statement-entry amount or journal amount cannot be consumed by a second active approved match; only rejected/superseded evidence may release consumption through explicit state transition. The current PostgreSQL tests cover two matches inside one run but do not exercise cross-run reuse.

Please add a real-PostgreSQL RED regression with two reconciliation runs in the same tenant/book/bank-account scope that reference the same statement entry (and separately the same journal), approve the first allocation, then prove the second active approval fails closed. The narrow repair should conserve/lock by immutable source identity across active runs (while explicitly excluding released/superseded allocations), not merely remove reconciliation_run_id from one query without preserving tenant/scope safety. Keep exact Decimal/numeric conservation, append-only history, and no automatic posting authority. Re-run the failed PostgreSQL boundary first, then the exact-head 100% coverage/repository/package/security gates.

[seonghobae]

Current exact-head RED is now observed on b1e1b1fd3fbec26ecd822a23b6d4bd6077cf6665 in Accounting Foundation CI run 33087013727 (job 98569306261). PostgreSQL 18.4 ran 472 tests; the cross-run source-conservation/release tests now pass, but the suite fails exactly four append-only evidence contracts in tests/test_reconciliation_append_only_evidence_red.py: recorded candidate source identity can still be UPDATEd; an unmatched recorded candidate can still be DELETEd; and statement/journal allocations can still be UPDATEd or DELETEd after their match is superseded.

The current migration explains the boundary: reconciliation_candidate_capacity_guard allows UPDATE and has no DELETE immutability guard, while reconciliation_approved_allocation_immutability_guard rejects allocation mutation only when the current match status is approved; once status becomes superseded, historical allocation rows become mutable/deletable. That defeats the intended model where status transition releases capacity without rewriting retained evidence.

Narrow GREEN: make recorded reconciliation_candidate rows append-only after INSERT, and make statement/journal allocation rows immutable regardless of later match status. Keep release semantics entirely in reconciliation_match.match_status_code, so only approved rows count toward active capacity while superseded/rejected rows remain durable historical evidence. Preserve tenant/scope FKs, exact numeric conservation, cross-run advisory locking, and the no-posting authority boundary. Do not weaken the RED tests or obtain green by deleting historical rows.

After the narrow DB-owned repair, rerun the four focused PostgreSQL tests first, then the full real-PostgreSQL suite and current-head 100% owned statement/branch coverage, repository/docstring/compiler contracts, exact-head SAST/security/live-base OSV, reproducible package and SHA-bound SBOM/provenance. Keep Draft until those exact-head gates and the ruleset-required Strix path pass and an independent qualifying approval exists.

[seonghobae]

Current-head causal boundary after exact job-log inspection (Accounting Foundation CI 33122367392 / job 98692151054): exact checkout of 9ce884b85a856aba13da741e604e3a398973b302 and PostgreSQL 18.4 succeeded; 479 tests ran and exactly one repository-contract test failed: test_unreleased_changelog_records_balanced_approval_invariant. The database-owned approval-balance tests themselves pass, including equal non-empty allocation totals, missing-side rejection, and unequal-total rejection. The current [Unreleased] migration-0015 bullet therefore understates an already-enforced invariant rather than exposing a migration defect.

Narrow repair only: strengthen that existing CHANGELOG bullet so the same entry explicitly states (1) non-empty statement allocations, (2) non-empty journal allocations, and (3) approved statement/journal allocation totals are exactly equal. Preserve append-only evidence, cross-run conservation, no-posting/reversal/close/policy authority, and released history. Then rerun the full exact-head PostgreSQL/100%-coverage/repository/package/SBOM/provenance gates; do not transfer predecessor evidence. Keep Draft while Accounting Foundation CI is red, Strix is pending, and qualifying approval remains absent.

[seonghobae]

Current-head accounting-control review on c0af868004dabde4a99205271dc77d502abfa9d9: the sequential late-allocation RED is fixed, but the freeze is not concurrency-safe yet.

reconciliation_allocation_conservation_guard() reads the match status with a plain SELECT and rejects inserts only when the visible status is not proposed. It does not lock the reconciliation_match row. reconciliation_match_approval_conservation_guard() concurrently totals currently visible allocations before allowing proposed -> approved, but it likewise has no synchronization with a concurrent allocation INSERT on that match.

A real PostgreSQL interleaving can therefore violate the reviewed snapshot: transaction A begins proposed -> approved and sees balanced committed allocations; transaction B, from a snapshot that still sees the match as proposed, inserts an additional allocation before A commits; A can approve without seeing B's uncommitted row and both transactions can later commit, leaving an approved match whose allocation population changed across the approval boundary. The new sequential tests do not exercise this race.

Please add a two-connection PostgreSQL RED that coordinates the transactions explicitly (barrier/event, not timing sleeps): start with a proposed match and balanced allocations, begin approval in one connection while a second connection attempts a further statement allocation and separately a further journal allocation. Prove that exactly one serialization order wins and that no committed state can contain an approved match with allocation rows added after the reviewed snapshot. Also assert the final approved statement/journal totals remain equal.

Narrow GREEN: serialize allocation INSERT and terminal review on the same match identity at the database boundary, e.g. acquire a row-level lock on the parent reconciliation_match before accepting a proposed-state allocation (with the approval UPDATE naturally taking the conflicting row lock), or an equivalent DB-owned lock discipline. Preserve the existing cross-run source advisory locks, append-only evidence, terminal-state freeze, exact numeric conservation, and no-posting/reversal/close authority. Re-run the focused concurrency RED first, then real PostgreSQL/full 100%-coverage/repository/SAST/security/OSV/package/SBOM/provenance gates on one unchanged head.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[opencode-agent]

Scheduled review-feedback autofix for this PR head.

• Head SHA: a4db2ca98391183037b6b7215caff89decf6f7c5

[seonghobae]

Child-state correction: live lifecycle successor #43 is now exact 4bc4945a6ca69c8ab0b1b1a93f5b913d76cd6b9d, still normally stacked on this root a4db2ca98391183037b6b7215caff89decf6f7c5. Predecessor 2004f058... reached hosted PostgreSQL and reduced the lane to 847 tests / 1 failure / 0 errors; the opening-book precursor and blocked-writer no-side-effect acceptance now execute. The sole remaining predecessor failure was a stale test assertion expecting mocked application population references despite migration 0021's BEFORE INSERT database-authority trigger. 14bb3d6... repaired the targeted review finding by computing real SHA-256 provenance over canonical fixture source facts; current 4bc4945... then repaired the stale assertion to require replay/persistence identity of the PostgreSQL-owned refs and reject the mocked placeholders. Current Foundation 34156230453 is non-terminal; Security 101848508427, dependency diff 101848508459, and SAST 101848508489 are GREEN while Accounting 101848508287 is running. Root evidence does not transfer to the child, and the child remains Draft until unchanged-head GREEN and independent review. #47 must not restack before that.

[seonghobae]

Exact-stack correction for 2026-09-08: the PR body’s #43@baf5b47... terminal-RED paragraph is now predecessor evidence. #43 advanced by an ordinary single-writer descendant to b37c1614e2c753f63a7e7ef3f647e6151ec1d171 on this unchanged root. Commit b37c161... changes only tests/test_reconciliation_lifecycle_postgres.py: it satisfies the lifecycle-outbox leg in the historical status-pair test using the database-assigned transition id/hash while deliberately leaving status unreconciled, preserving the production command/status/outbox constraints. Exact-head Accounting Foundation run 34168746132 is admitted but still queued; Accounting 101884865880, SAST 101884865988, Security 101884866000, dependency diff 101884866023 have no executable terminal evidence yet. Do not transfer baf5b47... or cb50da... results, restack #47, resolve review gates, or merge this root until #43’s unchanged descendant is terminal GREEN and its current review boundary is closed.

[seonghobae]

Dependent-stack state correction; root source is unchanged.

#47 is no longer e9de629... RED. The existing #47 single writer has advanced ordinary descendants to exact 9a49750363d394656dd3830d8a977e0ebefb8c79, preserving this root's 0019/0020/0021, moving child-owned migrations to 0022..0030, repairing the stale installer/migration test ABI, and composing child maker-checker/source-payload/session-lease authority onto the newer root lifecycle implementation.

Current #47 Accounting Foundation run 34179885509: dependency diff 101916654229, Security 101916654210, and SAST 101916654269 are GREEN; Accounting 101916654198 is running the behavior/repository suite. This is current child evidence only and does not change #29's own exact-head gate state. Do not edit #29 source to absorb a mutable child or infer child GREEN before that exact job completes. Effective open dependency order remains #29 -> #47 -> #53; #43 is merged history.

[seonghobae]

Stack correction from fresh #47 review: current child is #47@6c3a92fdc4d0b143e9e2da07f263661fe58357cd, open/Draft/mergeable, not the historical Ready 4527ca02.... The later Codex review found three P1 relational/session-authority defects; focused PostgreSQL REDs were added first, and 6c3a92fd... source-addresses the stacked-session/xact-lock ambiguity plus FORCE tenant RLS on the lifecycle lease. The retained-evidence UUID-only FK in migration 0022 remains an active repair finding in the existing #47 single-writer lane. 4527ca02... Foundation GREEN does not transfer. Effective dependency remains #29@12e1a4b... -> #47 -> #53; do not restack #53 or treat #47 as merge-ready until the successor is exact-head GREEN and review-complete.

[seonghobae]

Exact child update: #47@27309ca78c59608ff2ee6dce4d5f001f10c4f875, still open/Draft/mergeable. Hosted predecessor 6c3a92... ran 1,314 PostgreSQL tests and RED only on the intended composite retained-evidence FK plus a stale static single-unlock text matcher; the stacked-session and lifecycle-lease RLS regressions passed and those two review threads are now resolved. 27309ca... is tests-only and repairs that stale static ratchet. The migration-0022 composite FK remains the sole known source P1 under #47's existing single writer. Effective stack remains #29 -> #47 -> #53; no child GREEN transfers and #53 stays blocked.

[opencode-agent]

Scheduled review-feedback autofix for this PR head.

• Head SHA: 12e1a4bb9d8de5e4b6c72e2893107b07c515416b

[seonghobae]

Central CodeQL owner-path correction — keep the AIP root unchanged.

Required root CodeQL run 34173498486 on exact #29@12e1a4bb9d8de5e4b6c72e2893107b07c515416b remains a central publication/convergence failure, not an AIP source-analysis finding. The current protected central authority is .github/main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db (#2028).

Fresh owner-path evidence now advances the RCA beyond the earlier 403-only diagnosis. Canonical combined repair .github#2040@6706c231ab06a3c91c43fdb5b989cfcd79fff593 is Ready on base 7fd571db...; its exact-head non-CodeQL lanes are terminal GREEN (Security Scan 34251822390, SAST 34251822314, Python Security 34251822251, Runtime Quality 34251822381). Its required CodeQL run 34251822255 is terminal RED: actions receiver 102154521648 and python receiver 102154523061 fail current-head verdict enforcement, then coordinator 102154736341 fails before dispatch with CodeQL coordinator could not bind every pending language to an exact failed job.

The live #2040 owner review has already classified the exact cause: the protected pre-cutover handler publishes the legacy unbound codeql-dispatch/<language> receipt/title while the repaired producer correctly requires base/source-bound evidence; repeated per-language wake attempts have also fragmented one required run (actions already attempt 7, python attempt 4). Payload wire compatibility alone therefore cannot converge without weakening the security binding. The canonical owner lane is carrying the production-shaped RED→GREEN requirement; do not create a competing AIP workflow fix.

.github#1902 also remains Draft and mutable (live head c8d7caa0d699cec0200815fdfbca8bc0b2f7a4ec at this read), so neither central branch is consumer authority yet. Preserve fail-closed exact repository/PR/base/head/language/required-run/SARIF provenance. Do not rerun the historical AIP required run, synthesize status, churn Draft/Ready, make a no-op leaf commit, add a leaf PAT, or weaken required checks. Root #29 remains Draft until the central repair normally lands and a fresh required CodeQL generation on the unchanged/rebased exact AIP authority is terminal, plus a qualifying independent approval exists.

[seonghobae]

Fresh central-owner recheck, 2026-09-09 KST: root required CodeQL 34173498486 remains historical exact-head evidence for #29@12e1a4bb9d8de5e4b6c72e2893107b07c515416b, but I am not rerunning it as a repair action. .github#2028 is now protected in central authority and fixed base/head/required-run binding plus paginated completed-dispatch lookup; however fresh new-definition consumer canaries still reproduce receiver-before-coordinator settlement, and bounded targeted receiver wakes have not yet converged. A rerun of this pre-#2028 required run would preserve its historical workflow definition and cannot prove the central successor. Keep #29 Draft/fail-closed; no AIP no-op commit, synthetic status, Draft/Ready churn, broad rerun, actor weakening, or leaf credential shim. Central acceptance remains a genuinely current-generation exact (repo, PR, base, head, language, required run/job) producer/receipt/settlement path, then a normal AIP required-workflow instance on unchanged accounting truth.