Bridge between codex entries and GitHub Issues

[seabearDEV]

Problem

During the roadmap-to-issues migration, a gap surfaced: codexCLI stores the why and what we learned, GitHub tracks what to do — but there's no bridge between them.

Ideas

1. Issue-to-feature mappings — store entries like context.issues.gitFreshness = "#42" so agents know which issue to reference when working on a feature
2. Tracking policy entries — project.tracking declares where planned work lives, preventing drift between docs and issues
3. Agent cross-referencing — an agent starting a session could cross-reference codex entries against open issues to find relevant context before coding

Context

Observed while dogfooding codexCLI on its own project. The knowledge base and issue tracker serve complementary roles but don't talk to each other.

🤖 Generated with Claude Code

[seabearDEV]

Closing after triage. The issue conflated three sub-ideas, each with a different status:

Sub-idea 1 — dedicated `context.issues.*` namespace for issue-to-feature mappings

Rejected. Inline issue references in codex entry text already work organically and are widely used (e.g., `arch.storeLayout` references `#54`, `#58`, `#61`; `project.v111` lists `#61`/`#62`/`#63`). A dedicated namespace would duplicate data that already lives in entry text, with maintenance cost on every issue rename.

Sub-idea 2 — `project.tracking` declares where planned work lives

Already shipped. The codex entry `project.tracking` exists and reads:

"GitHub Issues is the source of truth for planned work. ROADMAP.md is a vision doc with issue links, not a task tracker. CHANGELOG.md is the release record."

Sub-idea 3 — agent cross-referencing on session start

Real value, but the original issue body conflated two very different implementations:

• 3a (small, doc-only): nudge `arch.llmInstructions` to tell agents to call `gh issue list` after `codex_context` at session start. The agent already has shell access — this is a 1-line instruction update, no code changes.
• 3b (large, full integration): build GitHub API fetching into codexCLI itself, with caching, auth, repo detection, opt-out flags. Crosses codexCLI's local-first architectural boundary. Real design work.

These have wildly different costs and shouldn't share an issue.

Refiled 3a as #68 with explicit out-of-scope language so it can't drift back into 3b territory. If anyone wants 3b later, file it as its own focused issue with a design discussion.

This issue's residual scope is now zero — close.