Problem
Activation already writes Numan-owned autoload state safely (nu/autoload.rs, state/autoload_state.rs, journal recovery, drift detection), but the user-facing story still implies config.nu awareness of individual activate/deactivate/rollback operations. For Numan to feel invisible, the user should touch config.nu exactly once, ever.
Goal
numan owns a single generated file (e.g. <root>/nu_state/numan_init.nu) that the user sources from config.nu with one line, added once. Every numan activate, numan deactivate, and numan snapshot rollback atomically regenerates that one file to reflect current state — no other config.nu edits, ever.
Scope
- Define
numan_init.nu as the single top-level file config.nu sources; it aggregates/sources the existing per-kind generated autoload files rather than replacing their separation.
- Regeneration must use the same atomic-write guarantees as the rest of
util/fs_safety.rs and existing autoload state writers — no partial/torn file ever visible to Nu.
- A one-time setup step (extend
numan setup or numan doctor --fix) that idempotently inserts the single source line into the user's config.nu, without disturbing surrounding content.
- Drift detection: if
numan_init.nu doesn't match what current lockfile/snapshot state would generate, numan doctor should flag and offer --fix, consistent with existing drift-detection patterns from Phase 3/4.
Acceptance criteria
- After the one-time
config.nu edit, a full cycle of install → activate → snapshot → rollback → deactivate requires zero further manual config.nu changes.
numan doctor detects a hand-edited or stale numan_init.nu and can restore it via --fix.
- Real-Nu acceptance test verifies a fresh Nu session sourcing
numan_init.nu sees the exact activation state Numan's lockfile/snapshot claims.
Non-goals
- Managing any part of the user's
config.nu beyond the single source line.
- Replacing the existing per-kind autoload file architecture —
numan_init.nu is a thin aggregator on top of it.
Problem
Activation already writes Numan-owned autoload state safely (
nu/autoload.rs,state/autoload_state.rs, journal recovery, drift detection), but the user-facing story still implies config.nu awareness of individual activate/deactivate/rollback operations. For Numan to feel invisible, the user should touchconfig.nuexactly once, ever.Goal
numanowns a single generated file (e.g.<root>/nu_state/numan_init.nu) that the user sources fromconfig.nuwith one line, added once. Everynuman activate,numan deactivate, andnuman snapshot rollbackatomically regenerates that one file to reflect current state — no otherconfig.nuedits, ever.Scope
numan_init.nuas the single top-level fileconfig.nusources; it aggregates/sources the existing per-kind generated autoload files rather than replacing their separation.util/fs_safety.rsand existing autoload state writers — no partial/torn file ever visible to Nu.numan setupornuman doctor --fix) that idempotently inserts the singlesourceline into the user'sconfig.nu, without disturbing surrounding content.numan_init.nudoesn't match what current lockfile/snapshot state would generate,numan doctorshould flag and offer--fix, consistent with existing drift-detection patterns from Phase 3/4.Acceptance criteria
config.nuedit, a full cycle of install → activate → snapshot → rollback → deactivate requires zero further manualconfig.nuchanges.numan doctordetects a hand-edited or stalenuman_init.nuand can restore it via--fix.numan_init.nusees the exact activation state Numan's lockfile/snapshot claims.Non-goals
config.nubeyond the singlesourceline.numan_init.nuis a thin aggregator on top of it.