New Codex chat, same project: which decisions still hold? (GFT Map)

[CoralLips]

You already discussed the approach, rejected alternatives and changed a few constraints. Then you open a fresh Codex chat—and you're back in old threads, reconstructing what was decided and why.

GFT Map organizes a topic's conversation material into an editable page of decisions, reasons and open questions beside your agent. Check it, correct it, then ask your next chat to load that topic. The map helps you scan the decisions; the document keeps the explanations.

Here's a real handoff the project author reviewed. He made one boundary explicit for the next chat: executing a player's command must not reopen controls the player wanted to avoid.

The corrected handoff makes the next action concrete:

Keep the existing map visible. If visible controls are needed, get the player's agreement first. Record whether the order executed separately from whether the requested experience was preserved.

Read the handoff and the author's correction · 中文案例

I prepared this case manually with AI assistance from the author's public excerpt. He reviewed and corrected it. A real fresh-chat game test and an advantage over the same Markdown are still unproven.

If you're about to hand off a task, tell me what the next chat needs to do. I'll help make a first handoff from the notes you already have—no new write-up or installation first. Keep using your current HANDOFF if that's already easier.

See the interface, local setup and current limits

I maintain GFT Map, an MIT-licensed local skill and panel for Codex and Claude Code.

Browse the no-install example. It uses prewritten data, does not run Codex or read your chats, and has not been rechecked for the v0.3.16 editing behavior.

In local v0.3.16, the title and summary of each decision node share one record across Doc and Map. Free-form prose remains separate; there is no automatic conflict warning. The reported disagreement between separate passages is not marked fully resolved.

Local setup requires Node.js 22.20+ and a signed-in agent CLI. AI processing uses that agent account's quota.

This post was written with AI assistance.

[TheodorNEngoy]

I tried the no-install preview: changed “three target users” to “one freelancer” in the main thread. The continuation preview picked up that edit, while the later “Let three users try it independently” section still said three. I saw your note about manual Doc/node edits being separate; flagging that disagreement in the handoff would help me avoid carrying two plans forward.

Here is a public-safe paraphrase of a real decision from Turnfeed Kingdoms, which I build with Codex:

• Decision: the player gives orders in chat and sees a persistent kingdom map.
• Reason: opening control/confirmation tabs interrupts that experience.
• Constraint: an ordinary-controls fallback can carry out an order, but that does not establish that it preserves the map-only experience.
• Open question: does a fresh chat resume play without replacing the map or reopening controls?

Next step: test that fresh-chat handoff and keep “can execute an order” separate from “keeps the requested experience.” Would this work for your proposed first document + map comparison?

[TheodorNEngoy]

Thanks—I read the handoff. It preserves the important distinction: successfully executing an order is separate from keeping the existing map visible without reopening controls. Please keep the fresh-chat result marked untested; reviewing this document does not establish that the workflow passes or that the map improves on the same Markdown. One constraint I would make explicit is that a requested map-only session must not silently fall back to visible council controls. That needs the player’s agreement.

[CoralLips]

@TheodorNEngoy Added your player-agreement boundary to the document and import: even an agreed fallback is a change of experience, not a map-only pass. The fresh-chat result and any benefit over the same-information Markdown remain untested. For your next fresh chat, could you try one pending order and report execution and map continuity separately, without posting private game material?

[TheodorNEngoy]

Thanks for adding that. I haven’t run a new-chat test yet, so I can’t give you a result. Those two separate checks make sense. I’d also record the model and available browser tools alongside them, so a missing tool is not mistaken for a handoff failure.

[CoralLips]

@TheodorNEngoy Added that to the test instructions: record the model and available browser tools. A missing required tool will be recorded as “not attempted: tool unavailable”, separately from the two outcomes. The fresh-chat result remains untested.

[CoralLips]

An update on your report: v0.3.16 now uses the same title and summary for each decision node in Doc and Map. Separate prose can still disagree; there’s no automatic conflict warning. I haven’t rerun your exact preview steps, so I’m not calling that report fully resolved.

[CoralLips]

Hi Theodor, thanks for catching the “three users / one freelancer” mismatch. I’ve updated the [English preview](https://corallips.github.io/gft-map/demo.html?lang=en&case=product) so it no longer gives the next chat two different headcounts. I also checked that editing a shared decision in the Doc updates it on the Map. If a separate paragraph contradicts that decision, the handoff still won’t flag it.

Your Turnfeed example stuck with me. An order can go through and still break the map-only experience by reopening the council controls. I haven’t tested that in a fresh chat. Thanks for trying the preview and taking the time to read the handoff.