fix(ci): materialize exact-head product checks for stacked feature-base PRs

Problem

Naruon’s protected product guidance and its executable repository workflows disagree about stacked pull requests.

Fresh 2026-09-10 evidence from ContextualWisdomLab/naruon:

protected develop@042b0c70531b229af3acbd0421a2f23098d848b3 is governed by 17 required contexts;
protected AGENTS.md says the central Security Scan runs on every PR base branch, including stacked PRs;
repository .github/workflows/app-ci.yml declares pull_request.branches only for develop, master, and release/**;
repository .github/workflows/bandit.yml declares PR bases only [develop, master];
current stacked exact heads naruon#1635@558c830651b64c2434cb64791a804f8059da6773, #1636@b1ee9b2d86916a5c29bcd7be1de09c6a6fb4e98c, and #1638@e54e46c3d46b30a1fe2af9ed6a3d4f8b3143e2f4 have no pull-request-triggered Actions workflow runs even though each carries source/test changes whose acceptance explicitly requires exact-head execution.

This is not a request to protect every feature branch, widen merge authority, or treat stacked PRs as default-branch PRs. The central scheduler/default-branch distinction tracked by #1196 and the non-default-branch ruleset audit tracked by #1200 must remain intact. The missing capability is exact-head product verification on a PR whose base is another feature branch.

The consumer cannot solve this by a no-op commit, predecessor evidence, manually copied central workflow, or loosening its protected-branch gate. .github is the canonical CI/review/security/release foundation owner, so the fleet contract should define how stacked exact heads obtain product CI/security evidence while merge governance still recognizes their real base topology.

Reality RED

A deterministic canary is a PR event with:

head = source/test-changing feature branch
base = another feature branch
repository default/protected branch = develop or main

On current Naruon workflow filters, Application CI and Bandit do not materialize because GitHub evaluates pull_request.branches against the PR base ref. The exact head therefore cannot produce those workflow receipts through ordinary PR synchronization.

The three current Naruon canaries above provide source-bearing examples:

test(metadata): update stale success-stub for _docs_index_exists probe #1635 — two-file local HTTP nested-decoding hardening and focused regression;
fix(tests): repair docs-index probe test JSON fixture regression on main #1636 — Search async loading→empty accessibility regression plus one semantic live-region source hunk;
chore(metadata): add public-surface desired state wave 2 #1638 — Today/dashboard async loading→empty regression plus three semantic live-region source hunks.

Status-only bot signals are not substitutes for these product test/security runs.

Required owner repair

Define a canonical reusable workflow/thin-caller contract for stacked feature-base PR exact-head verification. Prefer one central owner mechanism over repository-specific branch-pattern proliferation.
Bind every invocation to live repository, PR number, base ref/base SHA, and exact head SHA. Re-read those values before execution and before receipt publication.
Execute the repository’s trusted-base test/security commands or a released canonical equivalent on the exact head without treating the feature base as the repository default branch.
Preserve the distinction between:
- product verification evidence that should run for a stacked PR; and
- default/protected-branch merge/release governance that must remain scoped to the actual default/protected integration branch.
Publish stable exact-head check names/receipts usable by downstream PR-state logic without synthetic success, predecessor transfer, or duplicate/stale-head acceptance.
Preserve existing default-branch required workflows, review/thread rules, non-fast-forward protection, deletion protection, dependency/security fail-closed behavior, and normal merge semantics.
Use concurrency keyed by repository + PR + evidence lane so a newer head cancels only obsolete same-lane work; do not create an organization-wide fanout storm or another unbounded cron.
If cross-repository reuse is required, release/version the owner contract immutably before consumers bump to it. Consumer thin callers must not consume mutable .github PR heads.
Add executable fixtures for at least:
- default-base PR: existing required behavior unchanged;
- feature-base stacked PR: product verification materializes on exact head;
- head synchronization: predecessor run is obsolete/non-passing;
- base retarget/restack: new base/head identity invalidates prior evidence;
- closed/merged PR: no stale verification is promoted;
- malformed/mismatched dispatch metadata: fail closed.

GREEN acceptance

An unchanged Naruon stacked canary receives fresh Application CI/security-equivalent exact-head evidence without changing its base to develop, pushing a dummy commit, or copying central source into Naruon.
The check receipt identifies the live PR/base/head and cannot be reused after a restack or source push.
Default/protected branch rules and merge-scheduler topology remain unchanged and fail closed.
No feature branch becomes a protected/default integration authority merely to obtain CI.
The canonical owner implementation is exact-head tested, documented, released/versioned when consumed cross-repository, and Naruon then bumps its thin caller/contract through an ordinary PR.

.github#1196 — preserve actual default-branch identity in stacked-PR merge scheduling; complementary, not a substitute.
.github#1200 — reject non-default branch ruleset scope drift; this issue must not solve verification by widening ruleset scope.
.github#1929 — cross-repository exact-head terminal publication integrity remains independently required.
naruon#1623 — canonical frontend dependency-security owner; central CodeQL/Strix failures remain separate blockers.

No branch protection, workflow source, provider/model routing, or merge authority was changed while filing this owner-path defect.

Fresh Naruon canary update — 2026-09-10

The stacked-PR verification RED persists after source/test-changing successor heads, so this is not tied to the earlier canary SHAs:

naruon#1635@558c830651b64c2434cb64791a804f8059da6773 — 2-file local-HTTP hardening; formal exact-head CodeRabbit approval now exists, but PR-triggered product workflow runs remain absent.
naruon#1636@8ca8767c09810945a1348bdb1c4b862df1a87f96 — base #1603@8348772...; 2-file Search live-region delta. The latest child changes only its focused test to control the exact Response.json() body promise consumed by ApiClient.post(). Fresh fetch_commit_workflow_runs for 8ca8767... returns an empty PR-triggered run set.
naruon#1638@e7e8754b17754f3d85f25477424da9087bf8e9ec — base #1608@72bfd554...; 2-file Today live-region delta after its test-harness timing repair. It remains a stacked feature-base PR requiring exact-head product execution.

No canary was retargeted to develop, no dummy commit was pushed to force execution, and no workflow source/status was copied or synthesized in Naruon. Owner GREEN should still prove that these current feature-base identities can materialize exact-head executable product/security receipts without changing merge-governance topology.

Fresh Naruon canary update — 2026-09-10

naruon#1638 advanced by a test-only source change to exact 6e8c8919be264c0680d66f126d17da7f67071937 while remaining based on feature branch #1608@72bfd55426602147277b543de6103cd4b88b7644. The repair separates HTTP response resolution from each response.json() body promise and verifies the dashboard stays in loading after all response objects arrive, then announces the three empty states only after the exact bodies resolve. This is a new source/test-changing exact head, so predecessor receipts cannot transfer.

Please use this head as the current Today stacked-PR canary for #2073 acceptance. Naruon has not retargeted it to develop, pushed a dummy requeue commit, copied central workflow source, or synthesized a passing status.

Fresh contradictory/positive canary evidence from Naruon after owner-preserving restack: naruon#1361 is now a genuine feature-base stacked PR with base autoresearch/frontend-sec-bump@17a7618eda2b212b691f08fa936e042b34258fc9 and head feat/content-checksum-generator@165cfa91402e716401cd099d87404cde59d58003. After ordinary merge #1641 and base retarget, Application CI run 34446160183 materialized as event=pull_request; GitHub's run payload explicitly binds pull_requests[0].number=1361, that feature base ref/SHA, and exact head 165cfa914.... Security Scan 34446160301, Semgrep 34446160206, CodeQL PR 34446160275, Bandit 34446160211, and Docker 34446160396 also materialized on the same exact head (latest read: queued).

This does not yet prove #2073 GREEN: the earlier #1635/#1636/#1638 canaries had no such product runs, and current #1361 receipts still need terminal execution and identity/staleness checks. But the owner investigation should now explain why this feature-base PR materialized ordinary pull_request workflows while the earlier canaries did not, rather than assuming all feature-base PRs are uniformly filtered. Please preserve the original acceptance requirement and treat naruon#1361@165cfa914... as a new positive canary for differential RCA.

Correction to my immediately preceding canary note: this is not evidence that feature-base filtering is repaired. The timestamps expose the opposite and a more serious stale-identity case.

naruon#1361 head changed to merge commit 165cfa914... while the PR was still based on develop; that triggered Application CI run 34446160183 at 2026-09-10T06:39:05Z. The PR base was retargeted to autoresearch/frontend-sec-bump only afterward; the update response is timestamped 2026-09-10T06:39:09Z. Base #1623's actual .github/workflows/app-ci.yml still filters pull_request.branches to develop, master, release/**, so an ordinary feature-base event cannot have triggered this run.

Yet a subsequent GET of run 34446160183 presents pull_requests[0].base.ref=autoresearch/frontend-sec-bump / SHA 17a7618..., i.e. current PR metadata rather than trustworthy event-time base identity. Therefore the queued run is pre-retarget evidence and must be obsolete for the current PR base, despite sharing the same head SHA. This directly reproduces #2073 acceptance item base retarget/restack: new base/head identity invalidates prior evidence and demonstrates that head SHA alone, or the mutable pull_requests[] projection on a workflow-run GET, is insufficient provenance.

Please treat my prior comment's 'positive canary' interpretation as superseded. The useful new RED is: run created 06:39:05 under develop-compatible filter; base retarget completed 06:39:09; current run payload now misleadingly reflects the post-retarget feature base. Receipt publication must bind immutable event-time base ref/base SHA + exact head and invalidate/cancel evidence after retarget.

Fresh Naruon stacked-PR canary after an actual source-changing owner repair:

PR: docs: reinforce loop-goal block discipline and local dev authority naruon#1643
live base: codex/remove-repo-opencode-config@7bfc7cae2c12b00e59688230e0057a64e3d6dc0e (fix(metadata): require dedicated repository settings credential #1625)
exact head after owner-preserving merge + focused governance test: 46f7a3ad2bf464cca1332ca54fadbbec2be96f25
fresh compare: ahead-only, behind_by=0, exactly 3 files (AGENTS.md, CLAUDE.md, backend/tests/test_loop_goal_block_discipline_docs.py)
fresh commit workflow lookup on that exact head after the test push: workflow_runs=[]

This is useful because the head really changed after the direct-develop predecessor was repaired onto a feature-base owner stack; there is no predecessor receipt that can safely be promoted. It reproduces the same missing exact-head execution contract without retargeting to develop, pushing a dummy commit, copying workflow source, or widening protection. Please include this canary in the owner acceptance for (repository, PR, base ref/SHA, head SHA)-bound receipts.

Canary advanced after independent review found a real governance defect and Naruon repaired it. Current naruon#1643 identity is now base codex/remove-repo-opencode-config@7bfc7cae2c12b00e59688230e0057a64e3d6dc0e → exact head 323607859a36c544f2a7750763c2d314a3a40762; fresh compare remains ahead-only/behind 0 and exactly 3 files. Head changed through RED test 15c2a088..., causal CLAUDE fix d6f527bf..., and wrap-safe test child 32360785.... The previous zero-run canary head is therefore obsolete; the owner receipt must bind the new exact base/head identity rather than any predecessor run.

Fresh Naruon stacked-PR provenance canary from naruon#1647: final head 1cc7573909f390473257a0f976b33295a620f263 was created at 2026-09-10T13:46:41Z while PR base was still develop; Application CI run 34484782076 was created/started at 13:46:47Z. The PR was retargeted to autoresearch/frontend-sec-bump@17a7618eda2b212b691f08fa936e042b34258fc9 at ~13:47:51Z. A later GET of the same run now projects pull_requests[0].base as the current feature base, even though the run was admitted before retarget. Treat all such pre-retarget runs as stale evidence despite identical head SHA and mutable PR projection. This independently reproduces the base-identity problem already tracked here and reinforces binding receipts to event-time (repository, PR, base ref/SHA, head SHA) rather than current PR metadata.

Fresh Naruon stacked canary (2026-09-10): ContextualWisdomLab/naruon#1650 was owner-restacked before source replay. Current identity is base autoresearch/frontend-sec-bump@17a7618eda2b212b691f08fa936e042b34258fc9, head 433bb3aa306b2d57287f816cc91eb8bccabcc7f3, effective delta exactly two backend files (backend/db/models.py, backend/tests/test_model_timestamp_defaults.py). After retarget and new RED/fix commits, fetch_commit_workflow_runs returns zero PR-triggered runs for exact head 433bb3aa.... The earlier direct-develop head had ordinary product runs, but those are intentionally stale after base change/source replay. Please use this as another event-time (repository, PR, base ref/SHA, head SHA) acceptance canary; no dummy commit, temporary develop retarget, synthetic status, or copied workflow was used.

Fresh Naruon stacked exact-head canary after a real test-harness source change:

PR: ContextualWisdomLab/naruon#1650
current base: autoresearch/frontend-sec-bump@17a7618eda2b212b691f08fa936e042b34258fc9
current head: c3b987650a5f7e5dd2e78557982d3796a9a754dd
effective delta: exactly two files (backend/db/models.py, backend/tests/test_model_timestamp_defaults.py), ahead 7 / behind 0
fresh fetch_commit_workflow_runs for exact c3b98765...: 0 pull-request-triggered runs

This head contains a source-order timestamp guard repair plus a second RED→fix that narrows the guard from every callable ORM default to actual DateTime columns. It therefore needs executable product evidence; review/status signals are not substitutes. Please treat (repo, PR, base ref/SHA, head SHA) above as the current canary and do not transfer any pre-retarget or predecessor receipt.

Canary supersession: Naruon #1650 advanced again after a real review finding. Current identity is now base autoresearch/frontend-sec-bump@17a7618eda2b212b691f08fa936e042b34258fc9 → head a7cca21867eec5116bd70421ec4947a9c00543a8; effective delta remains exactly two files, ahead 9 / behind 0. Fresh PR-triggered workflow lookup for this exact head is still 0 runs. Please supersede the earlier c3b98765... canary with this current base/head identity; predecessor receipts/reviews are stale.

2026-09-27 stacked README/package canary from ContextualWisdomLab/contextual-orchestrator#1201:

base ref/SHA: fix/test-drift-main-red@ea48d4ec13be241ae85850d3d83a48edb3d28bf6 (#1266);
exact child head: 2fdee6ffc7bdd9110633ad3c8536225d2bd61e5a;
topology: ahead 11 / behind 0; eight effective files, including README, executable documentation contract, package metadata/locks, and changelog;
child is open, Ready review admission, mergeable, and has zero unresolved threads.

The exact child received only Security and Quality 36271997128, whose four jobs remain queued. Separate CodeQL PR, SAST Semgrep, and Security Scan runs did not materialize for the child exact head, even after a real Ready transition and the substantive customer-facing changelog commit that produced the current synchronize event.

Contrast: the exact feature-base parent ea48d4ec…, which itself targets protected main, has all four PR workflow lanes materialized on the same repository: Security and Quality 36268461507, CodeQL PR 36268461533, SAST Semgrep 36268461464, and Security Scan 36268461576 (currently queued; not claimed GREEN).

This is a same-repository controlled comparison for the narrowed admission defect: the stacked child preserves its real feature base and exact source/package/docs delta, but three expected verification lanes are absent. No temporary retarget, dummy/no-op commit, workflow copy, predecessor transfer, or synthetic status was used. Please bind any eventual receipt to (repository, PR, base ref/SHA, head SHA) and keep review/verification admission distinct from default-branch merge/release authority.

PolicyWeave stacked-PR canary — 2026-09-30

Draft PolicyWeave#25 now has source head 5f4e0cd203f6fd28a885c02cca4b22073aecab4f, tree 5f7840734a6b790fd6aaf283eed7c38b5ac7b4a8, based on parent develop@60fd7fb5c3177984a993102742bb16e36a909e2d. The prior PR run checked out a synthetic merge commit and only the product-local CI workflow materialized. This new fast-forward head is a fresh canary for the requested exact-source stacked feature-base SAST/CodeQL/Security materialization. The product PR stays Draft until those owner-side results and independent review exist.

Fresh stacked-PR canary — ContextualWisdomLab/EmbedRelay

Observed 2026-09-30 after a non-force two-parent restack:

PR: ContextualWisdomLab/EmbedRelay#1
live base: codex/public-surface-embedrelay-20260920@28c5b3717f686c28df3d2ec641d62562eaef1705
exact head: 45f19215720f2749197e37eb027b1567a2557447
exact tree: 71a8d8b2cfaf0a71b58fd512ba0489b0da66422e
merge parents: former runtime writer 718f7469f7fb383e1e45237fc77bef4f835fef65 and complete public-surface successor 28c5b3717f686c28df3d2ec641d62562eaef1705
PR state: Draft/open/mergeable; unresolved review threads 0; qualifying approvals 0

The exact head changes Rust production/domain code, PostgreSQL migrations/contracts, repository CI admission, public documentation, and schema guardrails. Its repository-local .github/workflows/ci.yml now explicitly admits Draft and Ready PRs and checks out/asserts the exact head, but no repository-local Rust/PostgreSQL run materialized for this feature-base PR. The base branch contains the documentation workflow from PR #5, yet no repository-local documentation run materialized either. Only central organization runs/checks appeared; Security/SAST and bootstrap/admission lanes are queued, while Draft CodeQL paths are skipped.

Fresh local exact-tree evidence is strong but is not a substitute for hosted product verification: Rust 40/40, documentation/schema 21/21 with PR context, warning-free fmt/Clippy/rustdoc, committed-range diff check, and LLVM lines 273/273, regions 267/267, functions 48/48, branches 30/30. The local environment had no PostgreSQL/Docker executor, leaving PostgreSQL 18.6 registry/manifest/RLS/concurrency/rollback/backup-restore acceptance specifically dependent on the missing hosted lane.

This is a direct GREEN-acceptance canary for #2073: do not retarget it to main, push a dummy commit, transfer predecessor evidence, copy mutable central workflow source, or synthesize success. The owner repair must materialize an exact receipt bound to repository + PR #1 + this base SHA + this head SHA, and must invalidate it on any later restack.

새 stacked feature-base canary (2026-10-01): ContextualWisdomLab/learning-record-store#6@abba5e6cceb282f4d05268424fb6f29b8637467c은 repository-local Quality run 36740984168이 exact head에서 success했지만, central SAST/Security/CodeQL pull-request runs는 생성되지 않았습니다. PR base는 bootstrap feature branch agent/bootstrap-learning-record-store이고 head는 source/test/docs를 변경합니다. 이는 leaf source failure가 아니라 이 Issue의 stacked-base materialization gap을 재현합니다. PR은 Draft로 유지하고 central gate를 success로 간주하지 않습니다.

CalendarWeave stacked canaries — 2026-10-01

Fresh feature-base stack evidence reproduces the owner gap without consumer-side workflow copies or retargeting:

🛡️ Sentinel: [HIGH] Fix HTML comment breakout in JSON serialization #6 3b2b3a532df4663dd8d2af9e4b6cca444fdfee93 on Add Palette journal for profile repo #1: repository Tests 36686514860 succeeded; no central Security/SAST/CodeQL run materialized.
Block OpenCode approval on stale fact evidence #7 f31728a5a9009e65bc560dabdf450fa940bd809a on 🛡️ Sentinel: [HIGH] Fix HTML comment breakout in JSON serialization #6: Tests 36686710710 succeeded; no central suite.
[codex] Require OpenCode inline suggested diffs #8 88844ad55c94cf3ed4f362bf4bea5ef579a20513 on Block OpenCode approval on stale fact evidence #7: Tests 36688373491 succeeded; no central suite.
Fix OpenCode inline review fallback warning #9 6a990dea1d1ab7bfd3639c308d1dc4f00d261e75 on [codex] Require OpenCode inline suggested diffs #8: Tests 36688791851 succeeded; no central suite.

Each PR is Draft/open with zero qualifying approvals; all inline threads are resolved after #6 received terminal exact-head job evidence. These canaries remain unmerged and must not inherit #1's security receipts. They extend the acceptance evidence for a released exact-head stacked verification contract while preserving the real base topology.

CalendarWeave canary successor: #9 is now 0aa31765d228916eb729fd3f217796f6aa33eaf2 after a docs-only fast-forward that reconciles the product/technical Gap baseline. Repository Tests run 36800999490 completed successfully (rust, coverage, and recovery; 100% line and explicit-branch gates), while the central Security/SAST/CodeQL suite still has no run at this feature-base exact head. The PR remains Draft; predecessor receipts are not transferred.

j-planner stacked-PR canary refresh (2026-10-02)

Repository: ContextualWisdomLab/j-planner
PR: fix: keep item save local and disable public geocoding j-planner#3
Base: docs/repository-public-surface@f9f9fa2afc3d15f4cb24112fccefe0d150ecdb87
Exact head: 02550ee20c9367509275a475b9f56f58151a77b7
Exact tree: db061f2c39944c5e5077c69152f3fad71f3edf34
State: Draft, open, mergeable; ordinary fast-forward only
Source-bearing delta: Proposed PRD/TRD/Architecture plus OSRM stale-result and imported-identifier security repairs
Local exact-tree evidence: node --test tests/*.test.mjs → 8/8; both inline scripts compile; git diff --check clean
Independent read-only implementation review: Critical 0 / Important 0; this is not a qualifying GitHub approval
Hosted pull-request workflow runs for exact head: 0
Qualifying independent current-head approvals: 0

This refreshed source-bearing stacked canary still proves the owner-path admission Gap: the non-default-base PR receives no exact-head Security Scan/SAST/CodeQL runs. Local evidence does not replace hosted verification. Required owner repair remains reusable exact-head stacked-PR Checks with thin callers; do not copy workflows into this consumer, retarget to gh-pages, push a no-op, or transfer PR #2 receipts.

The consumer PR remains Draft / Proposed / merge HOLD. No Close, Force Push, destructive rebase, or bypass was used.

@seonghobae, thanks for the evidence and guidance. This reported canary supports #2073’s stacked feature-base acceptance requirement. It does not establish GREEN.

Acceptance specimen:

Repository/PR: ContextualWisdomLab/j-planner#3
Base ref: docs/repository-public-surface
Base SHA: f9f9fa2afc3d15f4cb24112fccefe0d150ecdb87
Exact head SHA: fd22fe7feaf5b51ae0ebb840427fe2893cfc9a6f

Your reported local 5/5 result supports product correctness, but does not replace hosted verification. The explicit CodeRabbit review command addresses review admission only. It does not provide Security Scan, SAST Semgrep, or CodeQL execution receipts.

Owner GREEN must:

Materialize the required hosted verification for this unchanged feature-base topology.
Bind each receipt to immutable event-time repository, PR, base ref/SHA, and exact head SHA.
Produce terminal results, not advisory statuses or queued runs.
Invalidate receipts after any base or head identity change.

Keep #2 as the documentation/licensing foundation. Do not retarget #3 to gh-pages, copy central workflows, push a no-op commit, or transfer #2’s receipts. The reported missing hosted execution remains an owner-path blocker.

✏️ Learnings added

Learnt from: seonghobae
URL: https://github.com/ContextualWisdomLab/.github/issues/2073

Timestamp: 2026-10-01T10:13:12.367Z
Learning: ContextualWisdomLab/j-planner#3 is a stacked source-bearing acceptance canary for ContextualWisdomLab/.github#2073. Its reported identity on 2026-10-01 is base docs/repository-public-surfacef9f9fa2afc3d15f4cb24112fccefe0d150ecdb87 and head fd22fe7feaf5b51ae0ebb840427fe2893cfc9a6f. PR #2 is the required documentation/licensing foundation. The requester reports local tests 5/5 GREEN but zero pull-request workflow runs after Ready transition. An explicit CodeRabbit review command repaired non-default-base review admission, not Actions verification. Acceptance must preserve the feature-base topology and require immutable event-time repository/PR/base ref+SHA/head SHA receipts, without default-base retargeting, copied central workflows, no-op commits, or predecessor receipt transfer.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

You are interacting with an AI system.

@seonghobae, thanks for the evidence and guidance. My earlier reply used the predecessor head and an incorrect test count. The reported current head is cdc7847d6957ecc73b101f19f76a70f790415401, and the local result is 6/6 GREEN.

Current acceptance specimen for #2073:

Identity field	Value
Repository	`ContextualWisdomLab/j-planner`
PR	`#3`
Base ref	`docs/repository-public-surface`
Base SHA	`f9f9fa2afc3d15f4cb24112fccefe0d150ecdb87`
Exact head SHA	`cdc7847d6957ecc73b101f19f76a70f790415401`

Your reported zero PR workflow runs keep this specimen RED for hosted verification. Local tests and advisory review statuses do not replace Security Scan, SAST Semgrep, or CodeQL execution receipts. The review on predecessor fd22fe7… does not establish current-head approval.

Owner acceptance must:

Materialize the required hosted verification on this feature-base topology.
Bind terminal receipts to immutable event-time repository, PR, base ref/SHA, and exact head SHA.
Invalidate receipts when the base or head identity changes.
Keep verification admission separate from protected-base merge/release authority.

PR #2 remains the required documentation/licensing foundation. Retargeting #3 to gh-pages, copying central workflows, pushing a no-op, synthesizing success, or transferring predecessor receipts must not satisfy acceptance.

✏️ Learnings added

Learnt from: seonghobae
URL: https://github.com/ContextualWisdomLab/.github/issues/2073

Timestamp: 2026-10-01T10:16:13.305Z
Learning: For ContextualWisdomLab/.github#2073, seonghobae corrected the j-planner#3 acceptance specimen reported on 2026-10-01: repository ContextualWisdomLab/j-planner, base ref docs/repository-public-surface, base SHA f9f9fa2afc3d15f4cb24112fccefe0d150ecdb87, exact head SHA cdc7847d6957ecc73b101f19f76a70f790415401. This supersedes predecessor fd22fe7feaf5b51ae0ebb840427fe2893cfc9a6f as the reported current specimen. Local tests are reported as 6/6 GREEN, not 5/5. The requester reports zero pull-request workflow runs on the current head after Ready transition and synchronization. Predecessor review evidence cannot establish current-head approval or hosted verification.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

You are interacting with an AI system.

New stacked-PR canary (2026-10-01): ContextualWisdomLab/macos_utility_packs#6 is Draft at exact head b7f6bafb9b1b9369f9f3a53c8f687b72f6b0dfc7, based on repaired dependency feat/skill-blacklist@f5c7ce0d30a3dd28938b5bc64432f9123443a465. The dependency was integrated with a two-parent, non-force merge; GitHub now reports the stack mergeable and unresolved review threads = 0. Local exact-tree scripts/test, deny-list 30/30, and git diff --check are GREEN. fetch_commit_workflow_runs still returns zero hosted runs for the new stacked head, while Devin/CodeRabbit commit statuses are success. Keep the leaf Draft; do not transfer predecessor checks. This is another reproducible canary for stacked-PR exact-head workflow materialization.

2026-10-02 Learning Content Studio stacked-PR canary after ordinary non-force repair:

product stack: learning-content-studio#1 -> #6 -> #7;
PR 🛡️ Sentinel: [HIGH] Fix HTML comment breakout in JSON serialization #6 base/head: agent/bootstrap-learning-content-studio@e7977e5736b425e6221481934b25811ab27d7557 -> agent/publishing-admission-kernel@1201ab98a6a6676823f865a24d7535be072d4822;
PR Block OpenCode approval on stale fact evidence #7 base/head: agent/publishing-admission-kernel@1201ab98a6a6676823f865a24d7535be072d4822 -> agent/native-web-artifact-projection@d3aa79566a38538a8f578488799c509571f9cf95;
repository Quality materialized and succeeded for 🛡️ Sentinel: [HIGH] Fix HTML comment breakout in JSON serialization #6 (36950788347) and final Block OpenCode approval on stale fact evidence #7 head (36951369819);
exact-head central Security/SAST/CodeQL/review receipts did not materialize for either feature-base PR.

The consumer kept both PRs Draft and did not copy central workflows, push a dummy commit, retarget to develop, promote predecessor evidence, or weaken governance. These exact identities are suitable canaries for the owner acceptance contract.

2026-10-03 Veilpick stacked-PR canary after ordinary non-force repair:

product stack: ContextualWisdomLab/Veilpick#2 -> #3;
PR 🛡️ Sentinel: Add organization-wide default security policy #2 base/head: develop@cdaae4519db95141b88080d23d3cbeab6cfca31b -> feat/semantic-frontier-v1@9431fcd44a95298810206c6e2bb2c4a3e65ccb6f;
PR Add Superset workspace config #3 base/head: feat/semantic-frontier-v1@9431fcd44a95298810206c6e2bb2c4a3e65ccb6f -> docs/independent-access-reputation-engines@ca0b1458a9c56a299292040f4a619722535a28da;
the PR Add Superset workspace config #3 head is ahead 7 / behind 0 from the PR 🛡️ Sentinel: Add organization-wide default security policy #2 head, with merge base exactly 9431fcd44a95298810206c6e2bb2c4a3e65ccb6f; its effective delta remains nine design/research/ADR documentation paths;
fetch_commit_workflow_runs reports only the same-repository Rust contracts pull-request run 37103138151, terminal skipped; exact-head central Security/SAST/CodeQL/review receipts did not materialize;
review submissions and inline review threads are both zero.

The consumer remains Draft. It did not copy central workflows, retarget the leaf to develop, push a no-op commit, rerun blindly, promote predecessor evidence, or weaken merge governance. This exact base/head pair is another reproducible acceptance canary for the canonical stacked-PR contract. Runner-start failure of the separate push lane is tracked independently in #2356.

2026-10-03 j-planner stacked-PR canary after ordinary non-force repair:

product stack: ContextualWisdomLab/j-planner#2 -> #3;
PR 🛡️ Sentinel: Add organization-wide default security policy #2 exact head: docs/repository-public-surface@05218df22155eaa58f7556a89365842eec5bccab;
PR Add Superset workspace config #3 exact head: codex/explicit-geocode-consent-20261001@2f1f72f44e03c82c67a1e797a33716a59c65c528;
PR Add Superset workspace config #3 is ahead 10 / behind 0 from PR 🛡️ Sentinel: Add organization-wide default security policy #2, with merge base exactly 05218df22155eaa58f7556a89365842eec5bccab;
its non-force stack merge is 874251706602f3e238a260cae8693720f954bd42, preserving prior PR Add Superset workspace config #3 head and the current PR 🛡️ Sentinel: Add organization-wide default security policy #2 head as ordered parents;
fetch_commit_workflow_runs reports 0 pull-request workflow runs for the new exact head; combined status exposes CodeRabbit success only;
PR Add Superset workspace config #3 remains Draft, mergeable, with 4/4 review threads resolved but 0 qualifying approvals (9 COMMENTED reviews).

The consumer did not copy central workflows, retarget to gh-pages, push a no-op commit, rerun blindly, promote predecessor evidence, or weaken governance. This exact base/head pair is a fresh acceptance canary for the canonical stacked-PR admission contract.

BandScope canonical #910 admission RCA at 2026-10-04 KST: current head07d9dc86ef5c69957b2bc980950b185e9d4cca76 is stacked on #11768fe6b6d99c009527ef0bcba419e6f6debdb23c23. Base ci.yml/build-baseline.yml/sbom.yml admit PR bases develop/main only, so currenthead has zero Actions/check-runs. This is trigger absence, not queued runner work or GREEN. Leaf will push only real Workspace setup-state defect/tests, keep Draft and preserve checks. Safe path is prerequisite protected integration then ordinary non-force reconcile/develop retarget and new finalhead checks; alternatively consume a verified central stack admission release. Do not create source-neutral wake commits or copy central credential logic. Canonical issue was unassigned; assigned seonghobae for coordination, not a claim that repair is complete. Please coordinate deployed #2073/#2548 admission contract and current producer owner with BandScope #910/#1176. Exact RCA /Users/seonghobae/.hermes/cache/scratch/rca910-20261004/RCA.md.

Navigation Menu

Repository navigation

fix(ci): materialize exact-head product checks for stacked feature-base PRs #2073

Problem

Reality RED

Required owner repair

GREEN acceptance

Related

41 remaining items

Fresh stacked-PR canary — ContextualWisdomLab/EmbedRelay

CalendarWeave stacked canaries — 2026-10-01

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fix(ci): materialize exact-head product checks for stacked feature-base PRs #2073

Description

Problem

Reality RED

Required owner repair

GREEN acceptance

Related

Activity

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

41 remaining items

seonghobae commented on Sep 26, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

Fresh stacked-PR canary — ContextualWisdomLab/EmbedRelay

seonghobae commented on Sep 30, 2026

seonghobae commented on Oct 1, 2026

CalendarWeave stacked canaries — 2026-10-01

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 1, 2026

coderabbitai commented on Oct 1, 2026

coderabbitai commented on Oct 1, 2026

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 2, 2026

seonghobae commented on Oct 3, 2026

seonghobae commented on Oct 3, 2026

seonghobae commented on Oct 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions