Repository navigation
docs: close out the 2026-10-18 open-item cleanup and the D7 apply - #479
Conversation
…ing) CHANGELOG/MEMO entry for the Opus-orchestrated cleanup (#475-#478), the Daily collector 30-minute window receipt (checklist, TODO, followups), the D7 dry-run report facts, PR numbers and merge SHAs in the TODO bullets, and the two items that need owner decisions (W4.1, W4.5). The #475 merge SHA is still a placeholder until that PR merges. Claude-Session: https://claude.ai/code/session_01RE2f7JXQBa8xzoFrxuHS6v
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c19ac1cafd
ℹ️ 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".
| (real-host dry run: 0 affected roots). 2026-10-18: the HQ half merged as | ||
| PR #477 (`9f131f25`) |
There was a problem hiding this comment.
This update records the HQ half as merged, but leaves deployment listed as remaining even though this same commit records that the HQ service-index was deployed from 9ef7fb4f, which contains 9f131f25, and that the corresponding EngramCLI was used against it. Because the stated done criterion—an authenticated IPC/CLI action and test—is also satisfied, keeping this under the current open backlog incorrectly presents completed work as pending; retain only the separate producer-design follow-up if that is still open.
AGENTS.md reference: AGENTS.md:L67-L68
Useful? React with 👍 / 👎.
| environment variables are set, and no CI workflow sets them. Done when CI sets | ||
| them or a documented manual gate with a receipt exists. | ||
| Update 2026-10-18 (branch `ci/real-binary-gate-20261018`): shipped the | ||
| Done 2026-10-18: merged as PR #475 (`5b5b09af`), hosted run 39098816343 passed with `--timeout-scale 6`. Shipped the |
There was a problem hiding this comment.
The new sentence declares this item done and cites successful hosted run 39098816343, but the same item still says the hosted run is unproven, must turn green, and must be recorded before closing. Readers of the current backlog therefore receive mutually exclusive status and may reopen completed verification; replace the stale Remains: paragraph with the final receipt.
AGENTS.md reference: AGENTS.md:L67-L68
Useful? React with 👍 / 👎.
| 2026-10-18: PR #475 adds `.github/workflows/real-binary.yml`, a non-required | ||
| weekly / dispatch / PR gate that builds the three Debug binaries, sets the | ||
| variables and fails unless the expected test set executed; its hosted run | ||
| passed 49 of 50 with only the browser demo skipped by design. |
There was a problem hiding this comment.
Under the checklist's “Current status,” this addition says PR #475 now provides a workflow that sets all three binary variables, immediately after the same bullet asserts that no CI workflow sets them. This makes the checklist self-contradictory about whether the real-binary gate exists; update or remove the old assertion rather than appending the new state beneath it.
Useful? React with 👍 / 👎.
| | `collector-start-cost-1` | medium/perf | `macos/EngramCollectorCore/CollectorEventCoordinator.swift` | Every process start forces a full walk of every root, and a new process tries each stale event checkpoint once before falling back to a walk. A busy root can also repeat walks if its event queue overflows during recovery. Likely contributors to the missed CPU target; not measured after the 2026-10-02 fixes. 2026-10-18: the 30-minute Daily window excluded startup walks (process up 10 h, no re-walk during the window); the start cost remains unmeasured. | | ||
| | `collector-epoch-change-scope-1` | low | `macos/EngramCollectorCore/CollectorRuntime.swift` | A changed FSEvents epoch for one root stops the whole runtime, including uploads for other roots. Decide whether it should suspend only that root, as an identity change does. | | ||
| | `collector-epoch-producer-1` | medium, owner decision | `macos/EngramCollectorCore/CollectorInventoryStore.swift` `collector_streams`; `macos/EngramCoreWrite/CaptureIngest/CaptureIngestSourceRegistry.swift` `provision` | **Open, needs an owner decision (2026-10-18).** The collector never rotates an epoch under an existing source instance: a `collector_streams` row is created once per root, root revision and source with fresh UUIDs for both `source_instance_id` and `collector_epoch`, and later writes only advance `last_sequence`. A spool reset or a root re-enrollment that bumps the revision therefore reaches HQ as a new, unregistered source instance on an already registered root: its publications stay pending and are never claimed, and adding it to the source-authority file makes `CaptureIngestSourceRegistry.provision` throw `overlappingRoot` (UNIQUE machine/source/root), which aborts service-index startup. The new `collectorApproveEpoch` command keeps the source instance, so it cannot recover this case. Owner to decide: (a) the collector keeps the source instance and rotates only the epoch, making `collectorApproveEpoch` the recovery path, or (b) HQ gets a source-instance retire/rebind design. Until then the command covers only a same-instance epoch change that no current producer emits. | | ||
| | `collector-publication-cost-1` | medium/perf | `macos/EngramCollectorCore` capture and publication path | 2026-10-18 Daily window (CHANGELOG.md 2026-10-18): CPU bursts of 3-9 s per 30 s coincided with 35 Claude Code transcript publications while the quiet floor was 1.5-3.5%, so the <= 2% target fails on activity, not on polling. Hypothesis: each append re-reads and hashes the whole transcript. Unprofiled; a `sample` attach on Daily needs owner approval. | |
There was a problem hiding this comment.
The cited quiet floor is 1.5–3.5%, so it can itself exceed the 2% target, and this active-host window did not isolate polling from publication work. The conclusion that the target fails “on activity, not on polling” is therefore not supported by these measurements and may steer the next performance investigation away from a contributing baseline; record publication cost as a hypothesis without excluding polling until a controlled idle profile distinguishes them.
AGENTS.md reference: AGENTS.md:L67-L68
Useful? React with 👍 / 👎.
Durable record for 2026-10-18:
5b5b09af, feat(app): add Open Web Reader action for collector/replica roles #4767a48d19d, feat(service): add HQ collectorApproveEpoch operator command (W4.7) #4779f131f25, feat(service): add D7 legacy local-origin grok/pi purge dry-run and apply #4789ef7fb4f), the Daily collector 30-minute CPU window (5.891% FAIL, RSS 81.2 MiB PASS), and the owner-authorized HQ service-index deploy to9ef7fb4fplus the D7 purge apply (6,191 legacy grok/pi rows and derived rows removed, auditlegacy_local_purge.v1.2026-10-18T05:17:15Z, re-preview 0).collector-publication-cost-1(new lead) and a note oncollector-start-cost-1.Docs only; no code.
https://claude.ai/code/session_01RE2f7JXQBa8xzoFrxuHS6v