Skip to content

docs(threading): constraint 4 widens to every thread entry point (#1169) - #1200

Open
lilyshen0722 wants to merge 1 commit into
mainfrom
docs/threading-constraint-4-entry-points
Open

lilyshen0722 wants to merge 1 commit into
mainfrom
docs/threading-constraint-4-entry-points

Conversation

@lilyshen0722

Copy link
Copy Markdown
Contributor

Follows #1169 (merged): a thread is aimed from any message, the headline card, or the expanded rail, so constraint 4 in docs/design/threading-surface-ruling.md no longer reads 'inside an expanded thread'. Docs-only.

🤖 Generated with Claude Code

The ruling said 'posting inside an expanded thread'; #1169 made a thread
aimable from any message, the headline card, or the rail. The doc follows
the shipped surface, not the other way round.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@lilyshen0722 lilyshen0722 left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sprint-review gate — PASS on content; blocked on staleness. Head 31d9876c, 1 file, +1/-1, mergeable_state: clean, behind = 85.

The change is one inserted clause in constraint 4: "A thread is aimed from any message, the headline card, or the expanded rail (#1169 — there is no privileged entry point)."

It describes shipped behaviour. #1169 (feat(threading): add human thread entry points) merged 2026-08-23T10:16:32Z and touched exactly the three surfaces the clause names — V2MessageBubble.tsx (any message), V2ThreadCard.tsx (the headline card) and V2PodChat.tsx — alongside v2.css and a v2-layout-invariants addition. #1153, cited later in the same constraint, merged 2026-08-23T00:31:21Z. Both references resolve.

The constraint's load-bearing invariant also still holds at main, and it is pinned in more than one place — worth recording, because a ruling document's claims about the code are the ones with no reader:

agentMentionService.addressingIsNotThreadScoped.test.js
  'an @mention inside a thread is delivered without narrowToThread being called'
  'narrowToThread has exactly one call site, inside enqueueWakeOnMessage'
  'a muted thread stays muted when the user is mentioned in it'

I confirmed the same thing from the source side earlier today on #1218: narrowToThread is called once, at agentMentionService.ts:1155, inside enqueueWakeOnMessage (1090); enqueueMentions begins at 1266 and never calls it. So "thread_root_id alone enqueues no chat.mention" is structural rather than incidental — addressing is not thread-scoped because the mention path never reaches the narrowing at all.

Nothing to change. behind = 85 against MAX_BEHIND: 40 is the only blocker, and the green Stale-base merge guard tick is expired: it fires on [opened, synchronize, reopened, edited], none of which occur when main moves underneath a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant