New folders sync by default; one gate accepts the lot (LLP 0200/0201)

[bgmcmullen]

Two changes to the same complaint: setup asks too much, and one of its questions comes back every session.

The per-folder ask becomes opt-in (LLP 0200)

The session-start classification prompt (LLP 0106) fires in every unclassified folder on an enrolled machine. For someone working across many repos whose answer is "sync" every time, that is a question per session, spending the opening turn on a decision they already made in general.

A machine-local preference (<state>/usage-policy/folder-ask.json) now decides whether it happens, and its default is sync: the folder keeps the implicit default it already had, and nobody is interrupted. The ask still exists for people who want it.

This gates the question only. No class moves, .hypignore is untouched, folders already marked local-only/ignore stay so, and nothing new leaves a machine that was not already syncing by default (LLP 0188 #rule). What the ask ever added was a prompt, never an enforcement.

It is a real default change, so it is not silent about itself:

• hyp status names the mode on every enrolled run.
• hyp policy folders [ask|sync] [--json] is the standing control, sibling of hyp policy client.
• hyp policy list names it when it is not the default.
• The classification prompt now teaches its own off switch, so "stop asking me this" is answerable in the session that asked.

The wizard asks for it in its own step, after the per-adapter sync lane rather than as a row on it. That lane answers "which adapters ship"; this one answers "what happens the next time I work somewhere new". Folding the second into the first let a per-adapter checklist decide a per-folder policy silently.

Step 4 of 5 · Choose how new folders are handled
New folders you work in:
Folders you already marked keep their class either way.
> Sync them all
No question at session start; mark exceptions with hyp policy set
Ask me about each new folder
A session opened somewhere new asks once: sync, local-only, or ignore

An express gate up front (LLP 0201)

Every lane already opens with a defaults gate, so the common run was a sequence of bare enters whose answers were knowable before the first one. One question now accepts all of them:

HypAware found these on this machine:
Claude Code · managed by your fleet
Codex
> Record and sync all of these
Configures each to record through HypAware; new folders sync too.
Let me choose

The list is the explanation - an earlier draft asked "Set up with defaults?" over four lines paraphrasing them, which read as policy text.

Accepting skips the prompts, never the statements. Each lane still narrates the block its gate would have shown, so the fast path prints the same rows in the same order, minus the keypresses - which is what keeps it inside LLP 0188 #never-silent:

HypAware will record:
Claude Code · managed by your fleet
Codex
These will sync to your server:
Claude Code · managed by your fleet
Codex
New folders you work in:
Folders you already marked keep their class either way.
Syncing them all; change later with hyp policy folders ask

The rows come from the pick lane's own computation (hoisted to resolvePickSeeding + defaultRowLabels), with detection run once per wizard run and shared with the lane, so the two screens cannot disagree about what "all of these" means. With nothing detected and nothing locked there is nothing to accept, so no gate is shown and the pick lane opens its menu as before. Escape backs to the fork, ctrl+c cancels at 130, unenrolled runs drop the two server claims, and non-interactive runs never see it.

Also

The config overwrite confirm is laid out instead of arriving as one paragraph with the question buried at the end - same facts, same order.

Verification

• npm test: 3765 pass, 1 fail (usage_policy.fold_tightened, fails identically on a clean checkout)
• npm run typecheck: clean
• Smokes: walkthrough_picker_to_first_query, status_diagnostics, cli_bundled_plugins_activated, daemon_foreground_start_stop green
• Every screen rendered from the real code paths, express and step-by-step; the back-navigation end-to-end walks fork → express → pick → back → fork → express → pick → sync → folders through the real prompts

New coverage: the express gate and all three autoAccept arms, the new-folder lane, the preference store, the flipped hook decision, hyp policy folders, and the status line.

🤖 Generated with Claude Code

[philcunliffe]

neutral review - round 1

Verdict: findings, all fixed and pushed. Reviewed 46e8f0b (head at review time). CI was already green there (test 22/24, typecheck 22/24, duplicate-numbers). Fixes landed as 125f92e.

This is a well-built change. LLP 0200 and 0201 are written before the code, the forward-refs on 0106 and 0190 are there, the @ref annotations say things the filenames do not, resolvePickSeeding/defaultRowLabels genuinely close the "two derivations of the defaults" hole 0201 #gate worries about, and the user-facing docs (README, PRIVACY, both skill pairs) all state the new default correctly. The findings below are a back-edge defect and a set of doc blocks left behind by an earlier draft.

---

1. The express gate joins the forward chain but not the back chain - Medium

src/core/cli/wizard/index.js:327 put the gate insideatPick: rather than giving it a loop level. The gate became a screen between the fork and the picker on the way forward, but neither neighbour's back edge knew about it, so both overshot by exactly one screen. LLP 0191 #back-edges is that escape steps one screen back, and LLP 0201 #edges opens with "it behaves like any other wizard question".

Confirmed by driving the real orchestrator with the repo's own harness (lane call order, express gate shown):

escape at pick fork -> express -> pick -> FORK -> express -> pick (wanted: back to the gate)
escape at sync fork -> express -> pick -> syncScope -> EXPRESS -> pick (wanted: back to the picker)
escape at folders fork -> express -> pick -> syncScope -> folderAsk -> syncScope (correct)

Two user-visible consequences on the step-by-step path: escape at the picker throws away the pathway answer and re-asks the fork, and a user at the sync lane who wants to change their picks gets the express gate instead of the picker.

The existing tests could not catch either, because both filter the gate out of the assertion - back_navigation.test.js:366 filters to fork|pick and :385 to pick|syncScope.

Fixed. The gate now owns atExpress: between atFork: and atPick:. Pick backs to it when the pass showed one and straight to the fork when it did not (LLP 0201 #no-default-no-accept), and a sync back re-runs the picker without re-asking it. Three tests pin the chain, including the no-gate case; the end-to-end walk at :699 gained the second b the corrected edge needs. LLP 0201 #edges now states the edge in both directions and LLP 0191 gained the Extended-by: forward-ref it was missing (0190 and 0106 both got theirs).

2. Three doc blocks assert the opposite of the shipped default - Medium

Leftovers from a draft where ask was the default. Two of them are .d.ts files that go out through npm run build:types, so consumers of the published package were being told the wrong thing about a privacy-relevant default:

• src/core/usage-policy/types.d.ts:112 - "ask is the default and the behavior every machine had before the preference existed", and :123 "File absence means ask". Both contradict DEFAULT_FOLDER_ASK_MODE = 'sync' (folder_ask.js:29) and LLP 0200 #default.
• src/core/daemon/types.d.ts:273 - "ask is the default ... sync means the user retired that question".
• src/core/usage-policy/index.js:65 - "Absence reads as ask, so a machine that never set it behaves exactly as before", plus "Written by the wizard's sync lane", which is the exact folding LLP 0200 #wizard rejects by name.

Fixed, all three rewritten to match the code and LLP 0200 #default/#suppression/#wizard.

3. The folder-ask export block split a comment from its export - Low

src/core/usage-policy/index.js:63 spliced the new block between the LLP 0188 client-sync comment and the export { clientSyncListPath, ... } it describes, so the client-sync export ended up undocumented and the folder-ask export inherited a comment about a different store. Fixed by moving the block below.

4. hyp policy list drops a line it used to print - Low

src/core/commands/policy.js:735 made the folder-ask line a replacement for no machine-local entries (policy store: ...) rather than an addition, so a machine with the ask on and an empty store lost the store path. The non-empty branch at :748 correctly prints both. Fixed to print both; no comment explained the asymmetry, so I read it as an oversight.

---

Not actionable, noted only

• expressRowsSafe (index.js:851) casts to /** @type {any} */ to call resolvePickSeeding with a subset of RunWizardPickOptions. It is the one call that has to stay structurally in step with the pick lane, so it is the call least well served by an any. A narrow PickSeedingInput interface that RunWizardPickOptions satisfies structurally would close it. Left alone as a judgement call rather than a defect.
• Accepting express overwrites a standing ask with sync. That is stated on the accept row ("new folders sync too") and narrated by the lane, so it is inside LLP 0188 #never-silent, but it is worth being deliberate that it does not round-trip the way LLP 0200 #wizard's step-by-step re-run does.

Checks

npm test 3765 pass / 0 fail, npm run typecheck clean, in a fresh worktree at the pushed head. No em dashes, no semicolons, no inline import('...') types, type-import specifiers repo-root-anchored.

[philcunliffe]

neutral review - round 2 (final)

Verdict: findings, all fixed and pushed. Reviewed 125f92e (round 1's own fixes included, and reviewed no more gently than the contributor's). Fixes landed as a0420ee. npm test 3768 pass / 0 fail, npm run typecheck clean, in a fresh worktree at the pushed head.

Round 1's work holds up. I re-derived the back chain empirically rather than reading it off the diff, driving the real orchestrator with the repo's harness for eight scenarios (escape at folders, at sync, at pick with and without a gate, at the gate itself, pick-then-gate, the full folders-to-fork walk, and an express accept). Every one of them steps exactly one screen:

folders -> sync fork join express pick syncScope folderAsk syncScope folderAsk
sync -> pick fork join express pick syncScope pick syncScope folderAsk
pick -> express fork join express pick express pick syncScope folderAsk
express -> fork fork join express fork express pick syncScope folderAsk
full walk -> fork ... folderAsk syncScope pick express fork express pick ...

The atExpress restructuring, the expressShown gate on pick's back edge, the three doc-block corrections, the moved export block and the policy list addition are all correct as landed. What round 2 found is one screen further along the same chain, in the contributor's new lane.

---

1. Escape at the new-folder lane is a trap on a fleet-managed machine - Medium

src/core/cli/wizard/index.js:521 backed unconditionally into the sync lane. But the sync lane is not always a screen: sync_scope.js:78 returns after printing Everything you picked is managed by your fleet and always syncs. when candidates is empty, and :71 warns and returns when the client store is unreadable. Neither prompts.

So on a fully fleet-managed machine - every picked row locked, nothing left to opt out of, which is the ordinary shape for a managed install - escape at Choose how new folders are handled re-ran the sync lane's statement and re-asked the same question. Forever. There is no exit but ctrl+c (which abandons the run at 130) or answering the question the user was trying to step away from.

Driven against the real runWizardSyncScope, escaping seven times:

calls: fork express pick folderAsk folderAsk folderAsk folderAsk folderAsk folderAsk folderAsk
stdout: "Step 3 of 5 · Choose what syncs / Everything you picked is managed by your
fleet and always syncs. / Claude Code" x7

This is the same defect class round 1 fixed one screen earlier - a back edge pointed at something that is not a screen - and it was invisible for the same reason: back_navigation.test.js had no case where the sync lane declines to ask.

Fixed. The lane now reports noQuestion: true on both of its non-prompting returns (sync_scope.js:71, :87) and the orchestrator steps past it: if (syncScope.noQuestion) continue atPick (index.js:549). Past a lane that only narrated, the last screen the user could answer is the picker. Two tests pin it, one for each side of the branch. LLP 0200 #wizard (Draft) gained the paragraph stating the edge.

2. A back out of the picker can land on an express gate that cannot render - Low

index.js:446's if (expressShown) continue atExpress is right, but the pass it re-enters recomputes the gate's rows from pickSeed - and pickSeed is the picker's last confirmed selection. Confirm an empty selection, back out of the sync lane, then escape at the re-entered picker: the gate now has nothing to list, expressRowsSafe returns [], no gate is shown, and control falls forward into the picker again. The escape is a redraw; it takes a second one to reach the fork.

Reproduced: fork express pick syncScope pick pick syncScope folderAsk - the second pick back produced a third pick.

Self-healing after one extra keypress, hence Low, but it is the same rule (escape reaches the previous screen) and the fix is three lines. Fixed with a backFromPick flag (index.js:348, :394, :463): a back into a gate that this pass cannot show continues to the fork, which is exactly what LLP 0201 #no-default-no-accept already says the edge is when no gate exists. LLP 0201 #edges (Draft) now covers the re-entered pass explicitly.

3. Two derivations of "the defaults", in the two screens LLP 0201 says must not disagree - Low

resolvePickSeeding returns defaultRows and the express gate reads it (index.js:885), but promptPickSelection re-derived the identical expression at pick.js:469 for the pick gate. They agree today by construction, which is why nothing failed; LLP 0201 #gate is nonetheless explicit that "Two derivations of 'the defaults' could disagree, and the screen that accepts them all at once is the worst place for that." Fixed: defaultRows is threaded from the seeding, so there is one definition.

---

Deliberately left (carried forward from round 1, re-examined, not worse)

• expressRowsSafe casts to any (index.js:889). Confirmed runtime-safe: resolvePickSeeding touches only env, catalog, locked, initialSelection, picks and detect, all of which are supplied or optional, and it performs no writes. It stays a typing hole on the invariant the gate protects; a narrow PickSeedingInput interface that RunWizardPickOptions satisfies structurally would close it. Finding 3 narrows the blast radius a little (the two screens now share the value, not just the expression).
• Accepting express overwrites a standing ask with sync.folder_ask.js:86 writes DEFAULT_FOLDER_ASK_MODE, not before, on the auto-accept arm. Disclosed twice on that path (the accept row's new folders sync too, and the lane's own narration), so it is inside LLP 0188 #never-silent. Worth a human's eye because there is a real tension with LLP 0201 #gate's framing - the gate "accepts every default the wizard would ask for", and on a re-run the default the wizard would ask for is the standing answer (LLP 0200 #wizard: "A re-run defaults to the standing answer, so re-entering the wizard round-trips the preference"). It does not round-trip through express. Left as the contributor's call.

Also checked, clean

• hyp init --dry-run and --yes never reach the folders lane (init.js always sets picks, so interactive is false); no store is written on a scripted or dry run.
• All 20 new @ref anchors resolve; 0200#{store,default,machine-local,suppression,wizard,cli,escape-hatch,fail-safe} and 0201#{gate,narrate,no-default-no-accept,edges} all exist.
• The hook's read order matches LLP 0200 #suppression (mode after the enrolled check, before every per-folder reason), and reason correctly stops reporting resolve-error over ask-disabled.
• readFolderAskModeSafe falls to ask on a corrupt present file in both the hook and hyp status, so the two agree about what is in force; the CLI surfaces fail loudly instead (LLP 0200 #fail-safe).
• Both client hooks consume only evaluation.prompt, so the new ask-disabled reason needs nothing from them.
• No em dashes, no statement semicolons, no inline import('...') types, no @typedef; type-import specifiers repo-root-anchored in .js, relative .d.ts inside .d.ts as the rest of those files do.

Checks

npm test 3768 pass / 0 fail (3765 before, +3 new). npm run typecheck clean. Both new back-edge tests were proved to fail against the unfixed orchestrator (not ok 18, not ok 20) and pass with it. All four fixes verified in the pushed blob at origin/folders-sync-by-default-and-express-gate (a0420ee).

This was the last review round; the ladder caps at 2.

[philcunliffe]

Review capacity for this PR is spent (2 rounds, the ladder's cap), and the current head a0420ee carries neutral's own round-2 work, which has not itself been reviewed. Handing the remainder back rather than deferring it - this is your PR, so the residual calls are yours.

What the two rounds did. Round 1 (head 46e8f0b) found 4 findings and fixed them. Round 2 (head 125f92e) found 3 more and fixed them. Round 1's own work held up under re-examination: the atExpress loop level, the doc-block corrections, the moved export block and the policy list addition were all re-derived empirically against the repo's back_navigation.test.js harness across eight scenarios, and every documented edge steps exactly one screen. Suite at the current head: 3768 passing, 0 failing; typecheck clean.

The round-2 finding worth your attention.src/core/cli/wizard/index.js:521 - escape at the new-folder lane was an inescapable trap on a fleet-managed machine. The folders lane backed unconditionally into the sync lane, but the sync lane presents no prompt when every picked row is fleet-locked (sync_scope.js:78) or the client store is corrupt (:71). Escaping re-ran its statement and re-asked the same question indefinitely; the only exits were ctrl+c or answering. Reproduced against the real runWizardSyncScope: 7 escapes, 7 identical redraws.

That is the same defect class round 1 fixed one screen earlier, and it stayed invisible for the same reason: no test exercises the case where that lane declines to ask. If you add screens to this chain, that gap is worth closing structurally rather than case by case.

What needs your decision:

1. Express accept overwrites a standing ask with sync. Disclosed on the accept row (twice), so it is not silent and stays inside LLP 0188 #never-silent. But it does not round-trip the way LLP 0200 #wizard's step-by-step re-run promises. That tension is real and is a product call, not a defect - left for you.

2. expressRowsSafe casts to any to call resolvePickSeeding. Confirmed runtime-safe in both rounds, but it is a typing hole on precisely the invariant LLP 0201 #gate exists to protect. A narrow PickSeedingInput interface would close it.

3. The current head is unreviewed.a0420ee is neutral's own round-2 work. Given round 2 found a Medium defect adjacent to round 1's fix, that head deserves your eyes rather than an automatic pass.

Cross-PR conflict that no single PR's checks can see.origin/master stops at LLP 0199, and three in-flight PRs each add a differentllp/0200-*.decision.md:

• #6740200-hidden-picker-rows.decision.md
• #675 (this one) 0200-folder-ask-is-a-preference.decision.md
• #6770200-setup-offers-the-first-sync.decision.md

duplicate-numbers passes for each in isolation and will fail for the second and third to merge. Renumbering is mechanical under LLP 0156, but which doc keeps 0200 is your call, so neutral has not renumbered anyone's branch.

Both review records are in this thread with full file:line evidence. Nothing here is a known production defect - this is an exhausted-ladder handback.

Push to the branch or reply here and neutral will re-engage on its next tick.