Fix three fresh-install bugs: missing yaml dep, TELOS.md drift, dead Assistant tab#1420
Open
BearGare wants to merge 3 commits into
Open
Fix three fresh-install bugs: missing yaml dep, TELOS.md drift, dead Assistant tab#1420BearGare wants to merge 3 commits into
BearGare wants to merge 3 commits into
Conversation
Several deployed scripts (hooks/lib/identity.ts, LIFEOS/TOOLS/Banner.ts, LoadSkillConfig.ts, PipelineOrchestrator.ts, etc.) import the `yaml` npm package, but the deploy pipeline never declares or installs it: there's no root package.json anywhere in the release tree, and neither InstallEngine.ts nor DeployCore.ts runs `bun install`. First run after a fresh install throws "Cannot find package 'yaml'". Add install/package.json (yaml pinned, matching the version already used by the Agents/Prompting skill tools) and a new DeployCore.ts step that copies it to <configRoot>/package.json and runs `bun install --cwd <configRoot>` so yaml resolves via node_modules for both <configRoot>/hooks/ and <configRoot>/LIFEOS/. Applied to both the top-level and the skills/LifeOS-vendored copy of DeployCore.ts (the repo carries the two byte-identical). Verified: dry-run and --apply against a scratch config root; confirmed node_modules/yaml resolves from a deployed hooks/lib/*.ts location.
TELOS.md's own banner claims "this is the single source of truth for your TELOS... Pulse reads this file"; GenerateTelosSummary.ts's LEGACY_FILE_TO_SECTION comment says the same, dated 2026-05-01. But the shipped fresh-install template still carries both representations un-migrated: TELOS.md AND the legacy per-topic files (MISSION.md, GOALS.md, PROBLEMS.md, STRATEGIES.md, CHALLENGES.md, NARRATIVES.md, BELIEFS.md, WISDOM.md), and the generator's own precedence prefers the legacy file whenever it still exists on disk. Net effect: a fresh install silently ignores edits to TELOS.md in favor of the legacy files' stale samples, contradicting what TELOS.md tells the user. Two other consumers read the legacy files directly with *no* TELOS.md fallback at all: PULSE/checks/life-morning-brief.ts (goals for the voice morning brief) and skills/Daemon/Tools/DaemonAggregator.ts (mission/goals/ wisdom for the public daemon profile). Simply archiving the legacy files without also fixing these would have made them permanently blind to TELOS.md-only content. Fixes: - Archive the 8 legacy files to USER/TELOS/Archive/2026-05-01/, matching what GenerateTelosSummary.ts already expects for a fully-migrated install (verified: with the legacy files archived, GenerateTelosSummary.ts now correctly pulls PRINCIPAL_TELOS.md content from TELOS.md's sections). - Rewrite TELOS/README.md's file table to document TELOS.md as the single file to edit, and document the Archive/ directory's purpose. - Add a TELOS.md-section fallback to life-morning-brief.ts's goal read and to DaemonAggregator.ts's mission/goals/wisdom reads, so content that only exists in TELOS.md still surfaces in both. Verified end-to-end against a scratch config root for both tools.
pulse.ts dynamically imports "./Assistant/module" whenever config.da.enabled is true, and wires its exports to every /assistant/* route backing the Pulse Assistant tab (Observability/src/app/assistant/page.tsx — fully built: identity card, personality traits, task list, diary, opinions, cron CRUD). That module never existed anywhere in the repo. The import throws, gets caught, and logs "Assistant module not available" — so the entire tab's API surface silently no-ops regardless of the da.enabled setting. A full backend (real identity/personality/diary persistence, cron CRUD) is a separate feature, not a bug-fix PR — filing a tracking issue for that separately. This stub makes the current no-op behavior deliberate and honest instead of an accidental side-effect of a caught import error: - GET /assistant/health returns identity_loaded: false explicitly, so the frontend's existing isFreshInstall/EmptyStateGuide path is deterministic rather than incidentally correct via undefined-query fallback logic. - GET on the read endpoints (identity, personality, tasks, diary, opinions, cron) returns honestly-empty, correctly-typed JSON matching the frontend's interfaces, instead of an unhandled 404. - Mutating requests (POST/PATCH/DELETE on cron, PATCH on personality/traits) return 501 with a clear message, instead of silently doing nothing when a user clicks Save/Delete in the UI. Verified via a standalone harness exercising every route (health, identity, tasks, cron GET/POST/DELETE, avatar, an unhandled path).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three independent fixes found during a fresh v6.0.0 install. Each is its own commit and can be reviewed/reverted independently.
1. Missing
yamldependency for deployed hooks/TOOLS scriptsSeveral deployed scripts (
hooks/lib/identity.ts,LIFEOS/TOOLS/Banner.ts,LoadSkillConfig.ts,PipelineOrchestrator.ts, and others) import theyamlnpm package, but the deploy pipeline never declares or installs it: there is no rootpackage.jsonanywhere in the release tree, and neitherInstallEngine.tsnorDeployCore.tsrunsbun install. First run after a fresh install throwsCannot find package 'yaml'.Fix: add
install/package.json(withyamlpinned to the version already used by the Agents/Prompting skill tools) and a newDeployCore.tsstep that copies it to<configRoot>/package.jsonand runsbun install --cwd <configRoot>, soyamlresolves vianode_modulesfor both<configRoot>/hooks/and<configRoot>/LIFEOS/. Applied to both the top-level and theskills/LifeOS-vendored copy ofDeployCore.ts(the repo carries the two byte-identical). Verified with dry-run and--applyagainst a scratch config root, and by importingyamlfrom a deployedhooks/lib/*.tslocation.2. TELOS.md vs legacy split-file drift
TELOS.md's own banner says "this is the single source of truth... Pulse reads this file", andGenerateTelosSummary.ts'sLEGACY_FILE_TO_SECTIONcomment says the unifiedTELOS.mdsuperseded the split files on 2026-05-01. But the shipped fresh-install template still carries both representations un-migrated, and the generator prefers the legacy per-topic file whenever it still exists on disk. Net effect: a fresh install silently ignores edits toTELOS.mdin favor of the legacy files' stale samples, contradicting whatTELOS.mdtells the user.Two other consumers read the legacy files with no
TELOS.mdfallback at all:PULSE/checks/life-morning-brief.tsandskills/Daemon/Tools/DaemonAggregator.ts. Archiving the legacy files without fixing these would have made them permanently blind toTELOS.md-only content.Fix: archive the 8 legacy files to
USER/TELOS/Archive/2026-05-01/(the fully-migrated state the generator already expects); rewriteTELOS/README.mdto documentTELOS.mdas the single file to edit; add aTELOS.md-section fallback to bothlife-morning-brief.tsandDaemonAggregator.ts. Verified end-to-end against a scratch config root for the generator and both consumers.3. Assistant module stub so the Pulse Assistant tab degrades honestly
pulse.ts:127dynamically imports./Assistant/modulewheneverconfig.da.enabledis true, and wires its exports to every/assistant/*route backing the fully-built Assistant tab (Observability/src/app/assistant/page.tsx). That module never existed in the repo — the import throws, is caught, logs"Assistant module not available", and the entire tab API silently no-ops.A full backend (identity/personality/diary persistence, cron CRUD) is a separate feature, tracked in #1419 (which also documents a
/da/*vs/assistant/*naming drift between the design doc and the shipped frontend). This PR only adds a stub so the current no-op is deliberate rather than an accident of a caught import error:GET /assistant/healthreturnsidentity_loaded: false(making the frontend's existingEmptyStateGuide/isFreshInstallpath deterministic), read endpoints return correctly-typed empty JSON, and mutating requests return501with a clear message instead of silently doing nothing when a user clicks Save/Delete. Verified via a standalone harness exercising every route.Relates to #1419.