[coder-xieshijie]

What changes

core-grill "Choosing the path" and core-spec/references/verify.md "Verification depth":

• light now covers a change inside one feature even when it touches persistence, concurrency or recovery within that feature. One feature includes its own UI, IPC and runtime layers and every client that offers the same action.
• full is for behavior across features or in modules other features share (a common runtime loop, a shared package's contract), default startup wiring, a migration or a contract shared with another repository or service, metering, permissions or security, or a kind of change that has gone wrong before. When unsure between light and full, full.
• When a requirement does not fit the quick path, the summary's path line says in one sentence what core-spec adds over the quick path for that requirement (which acceptance requirement gets a gap check and an independent run by another family). The user weighs that when confirming, and can still choose quick.

docs/basis.md and the changelog (Unreleased) follow.

Basis (agent-prompt-rules)

• §4.1, the shortcoming: over two weeks of one product (10 requirements through dev-skills), the agent recommended full 9 times, quick once and light never, because the full list included "persistence, concurrency, recovery", which nearly every change touched. The user overrode 6 of the full recommendations to the quick path ("implement directly"), dropping the spec, the gap check and the independent verification together. The one requirement the user put on light reached mergeable in about 7.7 hours, and its independent verification caught two defects the owner's own runs passed. One quick-path requirement whose summary admitted it did not meet the quick conditions left a completion criterion half-checked (its acceptance check covered "feature off at startup" but not "feature on, never used"), found by an audit the next day.
• §4.2: the old light line ("a small, local change") and the old full list are replaced, not added to; "full when in doubt" stays, scoped to light versus full.
• §4.5: before and after, 3 runs each in fresh subagents, below.

Before / after (fresh subagents, 3 runs per version per case)

Cases are self-contained rewrites of real requirements: A context reset (one feature, persistence + concurrency, Desktop and TUI entries); B emergency rebuild (four packages, a shared failure event, revises another frozen spec); C feedback upload made asynchronous (one feature, one local queue file); D compaction deadloop (one feature, concurrency + persistence).

Case	Expected	before (main)	after (this branch)
A	light	full 3/3	light 3/3
B	full	full 3/3	full 3/3
C	light or quick	full 3/3	light 3/3
D	light	full 3/3	light 3/3
Path line says what core-spec adds over quick	yes	0/12	12/12

The first draft of this change still put A on full (Desktop and TUI counted as "several entry points"); defining one feature to include every client that offers the same action fixed it. The table is the second draft. The path section grows from about 870 to about 1,230 characters, mostly the new sentence.

Not verified: how core-spec judges "one feature" when it writes verify, and how often users still choose quick once light is offered.

Version is not bumped here; bump at release.