Onboarding feedback: adopting LifeOS v6 as an experienced engineer — friction log + the missing getting-started path #1461
Replies: 4 comments
-
|
Hey, really good stuff here. I've been thinking about how to enhance the install and make this stuff more obvious. Let me do some thinking on it. |
Beta Was this translation helpful? Give feedback.
-
|
With 5.0 I also stumbled upon this onboarding/where do I start issue and started thinking about how to address it but then I got swallowed up by endlessly trying to "unbreak" the system... |
Beta Was this translation helpful? Give feedback.
-
|
Hi Daniel, I've not talked to you since the days of Fabric started transition to Python. Since then I've been creating what I call importable-context (as the outputs) from every worthwhile inference on a given project and now just watch closely for the context window to > 60% when I regularly restart it. So thanks for that technique !! I've been listening on and off to your podcasts and looking forward to LifeOs and here it is !! I'll be watching this space for the guide to get me going -- Thanks Everybody !! |
Beta Was this translation helpful? Give feedback.
-
|
I ran into some of these as well. I've not yet gotten all of my PAI changes ported to V6, but one of the big things I focused on when making changes to PAI was to document them separately in a PAI-Changes folder - and often created a revert script to revert the change. Some changes were based on evals and tests with actual data -- which was then referenced as well, other tweaks were based on preferences or claude repeatedly not doing what I wanted. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Onboarding feedback: adopting LifeOS v6 as an experienced engineer — friction log + the missing "getting started" path
Context: Migrating an existing customized PAI install onto LifeOS v6 (6.0.5) on macOS (Claude Code harness), over several days. I'm an engineer/builder and comfortable in a terminal. I'm writing this because the system itself is impressive, but getting to a trustworthy running state was slow and confusing in ways that seem fixable — and most of them trace back to one missing thing: there is no onboarding guide that takes you from "installed" to "actually using it with all the pieces working."
Posting as friction feedback + a consolidated bug list. Happy to split the bugs into individual issues if that's more useful.
The headline gap: no "getting started / operate it" guide
INSTALL.md+ the install skill do a good job of the first install (scaffold, hooks, TELOS interview). But after that, you're on your own to discover that a bunch of features silently depend on tools the docs never tell you to set up:@openai/codex)The failure mode this creates: the Algorithm invokes these capabilities as if they exist. When they don't, they degrade silently rather than erroring. Concretely — an E4 run spawned the "cross-vendor" auditor, codex wasn't installed, and it fell back to the same model family it was supposed to check, without surfacing that the cross-vendor guarantee didn't hold. An experienced user can't tell the difference between "verified by an independent vendor" and "quietly reviewed by itself."
Request: a
GETTING-STARTED.md/ onboarding doc that, after install, walks through each optional-but-doctrine-assumed tool: what it's for, how to install + authenticate it, and how to verify it's live. Bonus: have the install skill offer to set them up, or at least enumerate them at the end.Bugs / stumbling blocks encountered (several look like genuine upstream issues)
Literal
$HOMEin env values creates shadow directories (matches settings.system.json env values ship a literal, unexpanded $HOME — breaks USER scaffold on fresh installs (regression of the #1124 / #1270 class) #1404/fix: expand literal $HOME in injected env path vars (LIFEOS_DIR/LIFEOS_CONFIG_DIR/PROJECTS_DIR) — fixes #1404 shadow-$HOME directories and orphaned learning data #1451 — appears fixed in newer commits, reporting the downstream damage). Env vars shipped as the literal string"$HOME/..."reached tools unexpanded, so a real directory named$HOME/was created on disk and silently captured live data (ratings, learning signals, gate logs). Found two such shadow trees. Suggest the installer/MergeSettingsexpand$HOMEat generation time, not rely on runtime.RepeatDetection.hook.tsusesprocess.exit(2)onUserPromptSubmit. On that event, exit 2 blocks and erases the user's prompt (stderr goes to the user, not into model context — that's PreToolUse semantics). So a user repeating a request the assistant missed gets their repeat deleted. The hook meant to catch "they're repeating themselves" was suppressing exactly those messages. Fix: emit{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":"..."}}on stdout + exit 0 (the pattern its sibling hooks already use).Dormant hooks shipped but unwired, while docs describe some as live. Several hook files ship in the payload but aren't wired into any settings (
SkillSurface,DriftReminder,SkillExecutionLog,SkillVoiceNotify,LoopDetector,EgressClassGuard), and at least a couple are documented as active. Nothing surfaces the discrepancy — a dormant hook emits no event, so no check ever notices it. (Structural: see "verification is change-scoped" below.)Duplicate hook registration → double-fire. Two
UserPromptSubmithooks appeared twice in settings (once grouped, once standalone), causing duplicate model calls per prompt.Default
default_voice_idis an ElevenLabs "famous voice" that 401s via API. Every voice notification fails withfamous_voice_not_permitted("Famous voices can only be used within the Reader App"). The shipped default isn't usable through the API path the notifier uses. Suggest defaulting to an API-permitted voice and documenting the voice-selection step.Post-rename stale paths in shipped content. After the PAI→LifeOS rename, ~50 shipped skill docs + a couple of code files still referenced the old
.claude/PAI/...tree. Because the old tree often still exists, these succeed silently against stale data rather than erroring — the worst kind of bug to notice.Docs site is ahead of the published repo. The docs describe components (e.g. Conduit, "shipped in 6.1.0") that aren't in any public release/tag/branch. For a new user this reads as "my install is broken / incomplete" when actually the code was never published. Suggest gating docs on shipped versions, or clearly marking unreleased components.
Structural observation: verification is change-scoped, not state-scoped
The through-line behind most of the above: LifeOS's self-checks are triggered by change (a hook fires when a file is edited;
DocIntegritychecks files touched this session). Anything that is never wired / never fires / was set up wrong at rest is invisible to every check, forever. Dormancy and misconfiguration are grandfathered by design.A state-scoped reconciler would close this: on session start (or on demand), diff three inventories — declared (what docs/frontmatter say exists), registered (what merged settings/env actually wire), and observed (what actually fires, from the existing observability logs) — and report drift. The health-check tool (
Doctor) is the natural home; it currently probes ~9 subsystems but didn't probe codex, the egress guard's live behavior, or Interceptor liveness. Every gap found in this session became a new standing probe locally; upstreaming that pattern would help every adopter.What would have made this smooth (concrete asks)
GETTING-STARTED.mdcovering the post-install tool setup (codex, Interceptor, Arbol/Cloudflare, voice) with install + auth + "verify it's live" for each.Doctor(declared vs registered vs observed)..claude/settings.jsonbut not included in thehooksfolder #5 are the most user-visible).The system is genuinely powerful once running. The gap is purely the path to running — and for a builder, that path currently runs through trial, error, and reading source, not through a guide.
Beta Was this translation helpful? Give feedback.
All reactions