docs(gaps): restore section dropped by #1423's merge

docs/product-technical-gap-baseline.md

@@ -398,6 +398,16 @@ flowchart LR
 
 ## 2026-08-30 hourly loop recheck: bootstrap/sidecar-pin cycle still open, one independent fix landed
 
+**Superseded by the entries below.** This section was drafted before #1413
+(Strix `orchestrator/auto` route) and #1422 (stale sidecar-pin refresh)
+merged into `main`; its premise that they "have not merged" no longer holds.
+Kept here, unedited, only as a record of the queue's state at that earlier
+point in the loop — see "2026-08-30 post-#1413/#1422 backlog refresh cycle"
+below for the accurate current-cycle account. (This same annotation was lost
+from an earlier resolution of this PR's own merge conflict against `main`,
+which also silently dropped the "2026-08-30 sidecar pin staleness
+recurrence" section below out of the file entirely; both are restored here.)
+
 - Reconfirmed at the start of this hourly pass: protected `main` is
   `6c8ee24046d743b3981c566c6e29f99f09137f6a` (this has moved on from the
   2026-08-26 107-open-PR snapshot's `826b92394c63deb6981c3a8d16a724d71f85a0d7`
@@ -455,6 +465,141 @@ flowchart LR
   way this pass found #1417's, and consider merging `main` into #1394's head
   to get it off its stale base.
 
+## 2026-08-30 sidecar pin staleness recurrence
+
+- Same class of defect as the 2026-08-29 entry above recurred within one day:
+  `scripts/ci/contextual_orchestrator_review_sidecar.sh`'s
+  `ORCHESTRATOR_PIN_SHA` default (`b21645116b352967e50fc497b87eb745b9cc8c61`)
+  was already 103 commits behind `contextual-orchestrator` `main`. Observed
+  directly in hosted `noema-review` job logs (`.github` PR #1421,
+  `ContextualWisdomLab/contextual-orchestrator#857` and others): the
+  vendored sidecar's own preflight against the stale pin fails closed with
+  `gateway preflight returned HTTP 502` (and, on a differently-shaped request,
+  `request_failed status=413 code=request_too_large`) before the model pool
+  can run, so `opencode-agent`/Noema never post a verdict and the required
+  `opencode-review`/`noema-review` checks fail on unrelated PRs across both
+  repos. Confirmed via `contextual-orchestrator` main history that
+  `5f2753ace756ddd81049a5221d55e8977572a416` is the current `main` HEAD and
+  passes its own Tests/Security/Fuzz gates.
+- This PR bumps the pin to `5f2753ace756ddd81049a5221d55e8977572a416` in the
+  three places the contract tests pin it: the sidecar script default,
+  `tests/test_contextual_orchestrator_review_sidecar_contract.py`'s
+  `ORCH_PIN_SHA`, and `docs/adr/0003-contextual-orchestrator-vendored-free-zdr.md`'s
+  "today" reference. `requirements.lock` needs no separate sync — the sidecar
+  installs it fresh from the freshly-checked-out pinned commit, not from a
+  copy embedded in this repo.
+- Acceptance remains open the same way the 2026-08-29 entry describes: this
+  fixes the reproduced local preflight failure and all static contract tests
+  pass, but only a fresh post-merge hosted `noema-review`/`opencode-review`
+  run against the new pin is proof the live gateway path actually completes
+  and posts a verdict. Given this is the second staleness incident in as many
+  days, the underlying gap is process, not just this one value: nothing
+  currently keeps this pin near `contextual-orchestrator` `main` on an
+  ongoing basis. A scheduled or CI-triggered pin-freshness check (e.g., fail
+  a nightly job once the pin falls more than N commits or M days behind a
+  green `contextual-orchestrator` main) would close that gap; not implemented
+  in this PR, left for a follow-up.
+
+## 2026-08-30 post-#1413/#1422 backlog refresh cycle
+
+- Confirmed at the start of this pass: protected `main` is
+  `c48859ac3919f1e7d2f24e744e5c551b94e66ac2`, which includes both #1413
+  (Strix `orchestrator/auto` route recognition) and #1422 (sidecar pin bump
+  to `5f2753ace756ddd81049a5221d55e8977572a416`) merged. Both root-cause
+  fixes are live on `main` as of this pass, alongside the pre-existing
+  bootstrap `if:` guard fix.
+- Since `strix`/`opencode-review`/`noema-review` are `pull_request_target`
+  required checks, an already-open PR does not get a fresh run merely
+  because `main` moved; each needs a new push event on its own branch. This
+  pass merged current `main` into as many otherwise-viable open PR branches
+  as could be validated in the time available, always as an ordinary
+  non-force-push merge commit (never a rebase), and only after a local
+  test-merge confirmed either a clean merge or a genuinely trivial conflict.
+- **15 PRs refreshed against the new `main`** (all pushed as plain merge
+  commits):
+  - Clean merges, no conflicts (6 via `update_pull_request_branch`, GitHub's
+    native "merge base into head" API): #1416, #1417, #1418, #1419, plus
+    #1276 and #1275 (dependency/security-action version bumps).
+  - Trivial conflicts resolved by hand, all confined to the additive
+    `## [Unreleased]` list in `CHANGELOG.md` (both sides had independently
+    appended unrelated bullets to the same list; resolution kept both):
+    #1411, #1398, #1397, #1348, #790, #821, #1391.
+    - #1348 additionally collided on Gap ID: its own draft `G-15` entry
+      (queue-hygiene live-ref race, `ContextualWisdomLab/LineageWeave#667`) numerically collided
+      with `main`'s already-merged, unrelated `G-15` (attachment-processing
+      boundary). Renumbered the branch's entry to **G-16**; confirmed no
+      test or cross-reference in that PR's diff pins the literal string
+      `G-15`, so the rename is safe.
+    - #1391 additionally conflicted in
+      `tests/test_pr_review_autofix_nvidia_nim_contract.py`'s
+      `REVIEW_DISPATCH_BLOB_SHA` pinned-blob-hash constant, because #1391's
+      own change (a Cargo-prefetch step) edits
+      `.github/workflows/opencode-review-dispatch.yml` inside the same
+      region `main` had independently changed, so neither side's pre-merge
+      constant was correct post-merge. Resolved by computing
+      `git hash-object` on the actually-merged file
+      (`50752bfef4c8db87bf971c5e9c2a98da72fc281c`) rather than guessing;
+      verified with `pytest tests/test_pr_review_autofix_nvidia_nim_contract.py`
+      (23 passed).
+  - Already on current `main`, no merge needed, just stuck: #1233 and #1176
+    both showed `base.sha` already equal to current `main` yet
+    `mergeable_state: blocked` (no conflict, just no fresh check run).
+    Pushed an empty retrigger commit to each to generate the required new
+    event.
+- **8 PRs left untouched this pass due to real (non-trivial) conflicts**,
+  each confirmed by an actual local `git merge --no-commit --no-ff origin/main`
+  rather than by SHA-staleness alone: #1394 and #1347 (both edit
+  `scripts/ci/sandboxed_web_e2e.py`, which `main` has independently changed
+  for its own SSRF hardening — same file, overlapping logic, not attempted);
+  #1415 (edits `scripts/ci/contextual_orchestrator_review_launcher.py`,
+  colliding with #1422's own sidecar changes); #1382 (nine conflicting files
+  spanning `strix.yml`, the ZDR policy module, and the sidecar script —
+  large surface, not attempted); #1009 (eleven conflicting files across
+  agent-mention routing, the merge scheduler, and Strix); #834 (conflicts in
+  `scripts/ci/contextual_orchestrator_review_policy.py`); #789 (six
+  conflicting files including `AGENTS.md` and the sidecar token loader);
+  #1114 (`strix.yml` — `main` has already independently grown equivalent
+  retry-with-backoff visibility-lookup logic to what #1114 itself proposed,
+  so this PR may now be moot rather than merely stale; flagging for owner
+  review rather than guessing). None of these were pushed; none were force
+  anything.
+- **Independent, non-systemic defect found on #1420** (whose branch was
+  already exactly on current `main` — no refresh needed): its fresh
+  `noema-review` run *did* vendor the corrected sidecar pin
+  (`5f2753ace756…`, confirmed in job logs) but then failed with
+  `request_failed status=413 code=request_too_large` during model
+  discovery, fell back to the OpenRouter ZDR feed, and the sidecar process
+  exited before its own healthz check with a non-zero status. Its
+  `opencode-review` gate failed separately and for an unrelated reason: at
+  the moment it ran, no `opencode-agent` review existed yet at the exact
+  current head (the verdict-lookup gate and the actual model dispatch that
+  posts the verdict appear to run on different, only loosely synchronized
+  schedules). Neither failure traces to the three already-diagnosed root
+  causes (Strix model recognition, the bootstrap guard, or the stale pin
+  value) — this is new evidence of a still-open sidecar/gateway runtime
+  defect and a possible review-dispatch timing gap, not yet root-caused or
+  fixed. Left for a follow-up pass; not in scope to fix blind this cycle.
+- **This PR's own earlier section above was corrected in place rather than
+  left to stand**, per the "search existing PRs for the same root cause
+  first" instruction: its content predated #1413/#1422 landing and was
+  simply wrong about the current backlog state, so amending this PR (which
+  already exists, unmerged, solely to record an hourly-loop dated entry) was
+  preferred over opening a duplicate doc-update PR for the same purpose. An
+  earlier attempt at this same correction, pushed concurrently by another
+  process to this same branch, resolved its `main`-merge conflict by
+  dropping the "2026-08-30 sidecar pin staleness recurrence" section above
+  out of the file entirely; that section is restored verbatim above as part
+  of this correction.
+- **No PR was merged this pass.** Every refreshed PR's required
+  `opencode-review`/`noema-review` verdict depends on an asynchronous model
+  dispatch (observed taking on the order of minutes just for sidecar
+  bootstrap and model discovery before any verdict posts) that had not
+  completed for any of the 15 refreshed PRs by the time this pass ended;
+  none had a qualifying current-head `APPROVED` review yet. This is expected
+  for one pass in an hourly loop, not a defect: the next pass should re-read
+  each of the 15 PRs' current-head checks and reviews, and merge whichever
+  come back green and approved with `--match-head-commit` per §5.
+
 ## 5. 실행 루프와 고객의 다음 행동
 
 각 hourly pass는 아래 순서를 유지한다.