Two cosmetic issues in Outstanding Items Tracker Doc edits during 2 Nov session (post-mortem) #162

Found during the 2 Nov session when programmatically reconciling the Outstanding Items Tracker Doc at the end of a 9-decision closure. Both resolved in the same session (02:19 AEDT, 3 Nov). Recording here for traceability.

Context

The Outstanding Items Tracker lives at https://claude.ai/artifact/KjdTM4cYCJLCpR2MtEfU7H as a Claude Doc. During the 2 Nov session, Claude reconciled it programmatically via the Claude Docs connector: 9 rows moved from main tabs to Completed, 3 new rows added, count sentences updated, change-log entry appended. Two cosmetic issues surfaced on review.

Issue 1 — D7 comment thread detached

When Claude deleted the D7 row from the main tab Decisions table, the attached comment thread 4b380d9b-b61f lost its anchor. The deletion succeeded with allowDetach: true (the correct response given D7 was asked to be moved to Completed), but the thread remained open with no block to hang on.

Root cause. The D7 row had a comment thread attached — a question from the product owner on 25 Oct asking "Should this doc be the master tracker, with your project memory file pointing to it?" with suggested replies "This doc is master · Memory file is master · Mirror both." That question was the input to the D7 decision, so it was logically answered when D7 closed, but the anchor to the question row disappeared when the row did.

Action taken. Read the thread content via mcp__Claude_Docs__query. Posted a reply in the thread pointing at the D7 resolution (DECISIONS/2026-11-02-tracker-long-term-home.md on main via PR #157) with the chosen answer ("This doc is master"). Reply visible in the thread as 7fc1eb57-b9ed. Per the Claude Docs comments guide, Claude cannot resolve a thread the product owner wrote in without an explicit chat-message ask; thread stays open for the product owner to resolve in the Doc UI.

Lesson for next time. Before deleting rows with comment threads, check if those threads need their resolution captured. If yes, post the reply pointing at the resolution before the delete, not after.

Issue 2 — Inline code formatting stripped on three paragraphs

Three paragraphs rewritten during the reconciliation lost their inline <code> formatting on specific identifiers (main, 81a5ea4, claude/project-status.md, SECURITY.md). The paragraphs remained readable but didn't visually distinguish filenames and commit hashes from prose.

Root cause. The initial rewrites used plain markdown text without backticks. The Claude Docs engine represents inline code as a text-run attribute (not a block-level chip), so markdown backticks are the right way to request it. Without them, the stored text had no code attribute, and the system issued a dropped unset: ["code"] notice.

Action taken. Re-sent the three paragraphs with proper markdown backticks around the identifiers. All code runs now render correctly:

• Intro paragraph (m7rthwe9tgj.60): main, 81a5ea4, claude/project-status.md now formatted
• A-items count sentence (m7rthwe9tgj.3012): SECURITY.md now formatted
• X-gap sentence (m7rthwe9tgj.8114): API_INTEGRATION.md was already formatted (no_op on this one — content already matched)

Lesson for next time. When rewriting paragraphs that contain filenames, commit hashes or code tokens, always use markdown backticks in the inline content string. Pre-flight check: scan the replacement text for any identifier that should be inline code and verify backticks are around it before sending the update call.

Resolution

Both issues addressed in the same session. Nothing in the tracker or the project state is now broken or stale.

Related

• Session notes: claude/project-status.md on main at 81a5ea4 (via PR docs: fix project-status.md content (replaces placeholder) #161)
• Outstanding Items Tracker Doc: https://claude.ai/artifact/KjdTM4cYCJLCpR2MtEfU7H
• D7 decision record: DECISIONS/2026-11-02-tracker-long-term-home.md on main via PR docs: record D7 decision (tracker long-term home) #157