Skip to content

T7: Wizard fork phase + returning-gate amendment - #364

Merged
philcunliffe merged 1 commit into
integration/install-experience-overhaulfrom
task/install-experience-overhaul/T7
Jul 22, 2026
Merged

T7: Wizard fork phase + returning-gate amendment#364
philcunliffe merged 1 commit into
integration/install-experience-overhaulfrom
task/install-experience-overhaul/T7

Conversation

@philcunliffe

Copy link
Copy Markdown
Contributor

Implements task T7 of install-experience-overhaul.

  • runWizardFork(opts) in new src/core/cli/wizard/fork.js: the top-level "Join a team" / "Local install and configuration" / quit choice, quit default on bare enter.
  • evaluateReturningGate(opts) amending LLP 0011's returning-install gate per LLP 0129 #returning-gate: a managed machine offers a scoped "adjust what this machine collects" entry (no fork, caller presets pathway to 'scoped') instead of dropping Reconfigure outright; a solo machine's Reconfigure re-enters the full fork.
  • No picker-descriptor dependency: reads only the existing hyp status summary and central-layer check (collectHypAwareStatus).
  • Tests cover both gate branches (managed scoped-reconfigure, solo full-reenter) and the fork's three choices in isolation (test/core/cli/wizard/fork.test.js).

Test plan

  • npm test (2504/2511 passing; the 7 failing leave tests are pre-existing on integration/install-experience-overhaul, reproduced identically with this change stashed out)
  • npm run typecheck
  • npm install (runs prepare -> build:types, clean)

Task-Id: T7

runWizardFork(opts) in src/core/cli/wizard/fork.js implements the
init wizard's top-level pathway fork ("Join a team" / "Local install
and configuration" / quit, quit default on bare enter). evaluateReturningGate(opts)
amends LLP 0011's returning-install gate per LLP 0129: a managed
machine offers a scoped "adjust what this machine collects" entry
instead of dropping Reconfigure outright, a solo machine's Reconfigure
re-enters the full fork. The gate only reads the existing hyp status
summary and central-layer check (collectHypAwareStatus), so this phase
has no dependency on the picker-descriptor plumbing other wizard tasks
build on.
Task-Id: T7
@philcunliffe
philcunliffe merged commit 59d9a30 into integration/install-experience-overhaulJul 22, 2026
8 checks passed
@philcunliffe
philcunliffe deleted the task/install-experience-overhaul/T7 branch July 22, 2026 19:40
bgmcmullen added a commit that referenced this pull request Aug 18, 2026
LLP-only PR: the plan doc neutral derives tasks from. LLP 0264 landed
Accepted with no plan, so the backlog derived nothing (a decision alone
produces no work).
Seven tasks in five waves, every wave a shippable tree: deps + overrides
(T1), unregister on the verb registry - the affordance hypaware-server
#364 already guards on (T2), the shared search modules hoisted under a
new ./core/search export (T3), the local grep service on the scan tier
with the LLP 0105 wrapper (T4), the wire-compatible query grep verb (T5),
the sidecar build at compaction on the server's worker/poison patterns
(T6), and status/skill/smoke proof (T7). Search works before any index
exists, and --remote works from T5 against any current server.
The #sequencing section resolves LLP 0264's open item: server #364
merges first (inert), this repo releases, the server bumps its hypaware
dep last; the decision doc gains the matching Extended-by forward-ref
(mechanical edit).
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
bgmcmullen pushed a commit that referenced this pull request Aug 19, 2026
…so retracts the projected CLI command (#875)
* The verb registry cannot release a name: add unregister(name) (#871)
Neither kernel registry supported removal, and `registerVerb` claims a
name on two surfaces at once (both verb maps plus an immediately
projected CLI command). A host that ships its own implementation of a
kernel verb's tool therefore had no way to displace it: hypaware-server
#364 feature-detects `verbs.unregister` and degrades to the kernel's
local-cache `grep_search` when it is absent.
`VerbRegistry.unregister(name)` releases the name from `byName` and the
tool from `byTool`, then retracts the CLI command the registration
actually projected. Projection is skipped when a command already
occupies the name, so the registry now tracks what it projected and
retracts only that; a pre-existing same-named command survives.
`CommandRegistry.unregister(name)` is the matching removal: it resolves
what `get` resolves and clears every alias pointing at the command, so
the name and its aliases are claimable again. Both are by-name,
idempotent, and total on an unknown name, since the caller runs at
daemon boot and a throw there takes boot down.
Both methods are declared in `hypaware-plugin-kernel-types.d.ts` so
plugins and the server see them in the published types.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Verb retraction misses the CLI command on the real boot path
`unregister` retracted the projected command only when the name was in a
per-registry `projected` ledger, and on the boot path that ledger is empty
for exactly the verbs a host wants to displace. `dispatch` runs
`registerCoreCommands`, which pre-projects every `CORE_VERBS` command so
`hyp --help` renders before boot; boot then builds the runtime over that
same command registry, `commandAlreadyRegistered` is true, and the verb
registry skips its own projection. Releasing the verb freed both maps and
left `hyp query sql` routed at the implementation the host just displaced:
archive-backed on MCP, local-cache on the CLI, silently.
Retraction is now identity-based. `verbToCommand` records each command it
projects in a module-level WeakSet, `isVerbProjection` reports it, and
`retractCommand` retracts only a command that is one. That covers the
pre-boot projection and the shared-command-registry re-creation case
`register`'s own comment anticipates, while a plugin's own same-named
command still survives, since it was never a projection.
Two regression tests, both failing before the change:
core verb retracted after `registerCoreCommands` + `createKernelRuntime`
(`hyp query sql` falls back to the bare `query` group), and a projection
made by a different verb registry over one shared command registry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Verb retraction: optional in the contract, observable when it degrades
Review follow-ups on the `unregister` affordance.
`CommandRegistry.unregister` and `VerbRegistry.unregister` are now
optional members. The kernel already feature-detects the command-registry
half (`retractCommand`), and the consumer this exists for (a server host
displacing the kernel-shipped verb) feature-detects the verb-registry
half, because plugins declare a kernel semver *range* and can be loaded by
a kernel that predates the member. Declaring them required narrowed both
checks to always-true for anyone compiling against the published
declarations, inviting removal of the guard and turning an older kernel
into a boot failure. The concrete factories pin the member as present, so
in-repo callers stay unconditional.
`retractCommand`'s two tolerated fall-through branches now warn. The
caller's prescribed success check is `getByTool`, which the map deletion
satisfies on its own, so a half retraction read as a win while
`hyp <verb>` kept routing at the run closure of the displaced verb: the
silent local-cache regression LLP 0264 verb warns about. Adds a test for
the registry-predates-unregister branch, which had none.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: test <test@test.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto 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

@philcunliffe