Skip to content

Gate 5 journal reconciliation detail#10

Merged
geraldarthurdavis merged 1 commit into
version/v28from
v28/gate-5-journal-diff-reconciliation
May 19, 2026
Merged

Gate 5 journal reconciliation detail#10
geraldarthurdavis merged 1 commit into
version/v28from
v28/gate-5-journal-diff-reconciliation

Conversation

@geraldarthurdavis

Copy link
Copy Markdown
Contributor

Summary

  • adds selected-run Terminal journal/readback payloads to the execution history detail API
  • adds Terminal Journal detail UI that separates ledger observations, database projections, canonical roots, repair receipts, and blocking drift reasons
  • records journal ids in harness settlement evidence and updates V28 spec, QA, and parity docs

Validation

  • pnpm --filter bitcode-uapi test
  • pnpm --filter bitcode-uapi exec tsc --noEmit --pretty false
  • pnpm --filter @bitcode/api exec tsc --noEmit --pretty false
  • pnpm --filter bitcode-uapi lint
  • pnpm --filter @bitcode/pipeline-hosts exec jest --config jest.config.cjs --runTestsByPath src/tests/asset-pack-harness.test.ts
  • pnpm --filter bitcode-uapi build
  • git diff --cached --check
  • literal secret scan for staging credential fragments

@vercel

vercel Bot commented May 19, 2026

Copy link
Copy Markdown

Deployment failed with the following error:

There is no GitHub account connected to this Vercel account.

@vercel

vercel Bot commented May 19, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
engi-uapi Ready Ready Preview, Comment May 19, 2026 2:25am

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f079673baf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +783 to +787
readRowById('btd_asset_pack_ranges', 'asset_pack_id', assetPackId, readErrors),
readRowById('btc_fee_transactions', 'receipt_id', btcFeeReceiptId, readErrors),
readRowById('btd_asset_pack_ledger_anchors', 'anchor_id', ledgerAnchorId, readErrors),
readRowById('btd_ownership_events', 'ownership_event_id', ownershipEventId, readErrors),
readRowById('btd_read_licenses', 'license_id', readLicenseId, readErrors),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Restrict ledger readback to this run's facts

When a user can fetch a selected execution, these admin-client lookups trust the ledgerSettlement IDs stored in that execution and then return select('*') rows from global ledger tables. Because postExecutionHistoryRoute persists caller-supplied output/context for the user's own run, a caller can create a run whose assetPackId, btcFeeReceiptId, or other IDs point at another user's ledger facts and this route will bypass RLS via supabaseAdmin, exposing rows such as BTC fee wallet authorization/PSBT data and read-license wallet IDs. The readback should derive/verify ownership from the selected run's persisted settlement or constrain each lookup to facts created for that run/user before returning the rows.

Useful? React with 👍 / 👎.

Comment on lines +735 to +739
const { data, error } = await supabaseAdmin
.from('btd_ledger_database_reconciliation_repairs')
.select('*')
.order('issued_at', { ascending: false })
.limit(100);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Filter reconciliation repairs before limiting

This query takes only the newest 100 repair receipts globally and filters for the selected run afterward. In any environment with more than 100 newer repairs from other runs, an older selected run's blocking repair will be omitted, causing the Terminal journal detail to show no repair/blocking reason even though the database contains one. Apply the runId/factIds predicates in the Supabase query before the limit, or page until all matching repairs are found.

Useful? React with 👍 / 👎.

@geraldarthurdavis
geraldarthurdavis merged commit 4c70c2b into version/v28 May 19, 2026
30 of 32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant