Problem
The docs index (https://code.claude.com/docs/llms.txt) lists 112 core /docs/en/ pages. This repository cites 73 of them. Most of the 39 uncited are irrelevant here (IDE integrations, mobile, gateways, accessibility). Six are not, and each is a platform surface the doctrine has never evaluated:
| Page |
Why it matters here |
cross-session-messaging |
ListAgents / SendMessage, crossSessionInbound, isolatePeerMachines, /list-agents. A whole inter-session channel with its own permission semantics — including that an incoming message can never approve anything or change configuration. Not available on native Windows. |
agent-teams |
A coordinated team of sessions Claude spawns and supervises — a rung the dispatch ladder does not have. |
agents |
The docs' own comparison of every way Claude Code runs multiple agents. Directly the ladder's subject matter. |
feature-availability |
Which features exist on which platform and provider. This repo has an explicit cross-platform contract; a per-feature availability matrix is exactly its input. |
sessions |
Resume semantics — the documented way to carry context, distinct from messaging. |
checkpointing |
Rollback surface, relevant to any skill that mutates. |
This is not drift. Nothing in the repo is wrong about these; the doctrine simply predates them.
Why it needs deciding rather than ignoring
docs/PLUGIN-PHILOSOPHY.md ("Native-first") already owns the decision procedure — the adoption gate: adopt a native mechanism when it (1) fills a real existing gap, (2) is stable and works cleanly, and (3) meets repository standards. That gate has not been run against any of these six.
The most affected doctrine is Delegation mechanics → Dispatch ladder, which runs generic fresh-context subagent → named agent → cross-vendor advisor. It does not mention agent teams, background sessions, or cross-session messaging, so an author choosing a delegation mechanism today is choosing from a list that predates three of the options.
The cross-platform contract is second: feature-availability is the canonical input, and this repo's primary development machine is Windows, where at least one of these surfaces does not exist at all.
Proposed work
Run the Native-first adoption gate against each of the six, one at a time, and record the outcome — adopt, defer with a recheck trigger, or decline with a reason. A decline is a perfectly good result; what is not acceptable is the current state, where the question has not been asked.
Where the answer is adopt, the follow-on is doctrine text (most likely in the dispatch ladder and the cross-platform contract), not new plugins.
Source
Gate doc-currency audit, PR #2169. Graduated from that PR's findings slice per the topic-docs Contract-tier prune rule.
Problem
The docs index (
https://code.claude.com/docs/llms.txt) lists 112 core/docs/en/pages. This repository cites 73 of them. Most of the 39 uncited are irrelevant here (IDE integrations, mobile, gateways, accessibility). Six are not, and each is a platform surface the doctrine has never evaluated:cross-session-messagingListAgents/SendMessage,crossSessionInbound,isolatePeerMachines,/list-agents. A whole inter-session channel with its own permission semantics — including that an incoming message can never approve anything or change configuration. Not available on native Windows.agent-teamsagentsfeature-availabilitysessionscheckpointingThis is not drift. Nothing in the repo is wrong about these; the doctrine simply predates them.
Why it needs deciding rather than ignoring
docs/PLUGIN-PHILOSOPHY.md("Native-first") already owns the decision procedure — the adoption gate: adopt a native mechanism when it (1) fills a real existing gap, (2) is stable and works cleanly, and (3) meets repository standards. That gate has not been run against any of these six.The most affected doctrine is Delegation mechanics → Dispatch ladder, which runs generic fresh-context subagent → named agent → cross-vendor advisor. It does not mention agent teams, background sessions, or cross-session messaging, so an author choosing a delegation mechanism today is choosing from a list that predates three of the options.
The cross-platform contract is second:
feature-availabilityis the canonical input, and this repo's primary development machine is Windows, where at least one of these surfaces does not exist at all.Proposed work
Run the Native-first adoption gate against each of the six, one at a time, and record the outcome — adopt, defer with a recheck trigger, or decline with a reason. A decline is a perfectly good result; what is not acceptable is the current state, where the question has not been asked.
Where the answer is adopt, the follow-on is doctrine text (most likely in the dispatch ladder and the cross-platform contract), not new plugins.
Source
Gate doc-currency audit, PR #2169. Graduated from that PR's findings slice per the topic-docs Contract-tier prune rule.