LifeOS Source Assessments

Exact source quote · live v1 biography description, showing what it does say

"AK's biography is a maintained and updated current reflection of self—existing both for regular personal reflection and for agents."

One-sentence summary. The archived biography's neurotype framing (AuDHD/OCD, "single-track mind," hyperfocus vs. executive dysfunction) was removed from the current agent-facing surface, so it must not be promoted into standing memory files without AK's explicit reaffirmation.

Expansion. The archived material is also largely agent-drafted (authors include Ada, codex__hp-z-book, claudia-ak) — second-hand self-description through agent summarization, not AK's own words. Its entire operational content is already carried by the Resilience pillar (I-6) with no diagnosis required. A standing rule follows: AK's neurotype is AK's to disclose — Muse never invokes it in conversation, never cites it to explain AK to others, and never writes it into shared artifacts.

Proposed destinationNONE pending AK's reaffirmation. (If AK reaffirms: a private USER.md note, never in shared output.)

Exact source quote

"Thinker — philosopher/generalist-apologist; Writer — communicator/artist-idealist; Builder — engineer/strategist-pragmatist; Leader — director/futurist-activist"

One-sentence summary. AK's intended vocational channels for maximum impact are four roles — Thinker, Writer, Builder, Leader — each pairing a craft with a stance.

Expansion. These are identity-level, not task labels: they describe how AK wants to matter, not a todo taxonomy. They are useful for framing (is this project a Builder move or a Leader move?) and for noticing neglect (a season with no Writer output is a signal). Enforcement is intentionally light: a thinking protocol, not a gate.

Proposed destinationUSER.md (factual identity note).

Exact source quote

goals are adjustable "North star goalposts" used to align and realign ventures.

One-sentence summary. AK's goal system is designed to be realigned, not achieved once — and the archived specifics ($10M 10-year net worth; phases via "Achilles Report" job hunt, $300K/yr across AccelerateBooks/FutureMD/AgoraMedia, then investing) are historical data, not current targets.

Expansion. Treating archived financial targets as live would be the exact verify-before-asserting failure AK penalizes. The durable insight is the mechanism (goalposts that move deliberately), not the figures. Any goal number cited in conversation must carry its source and date.

Proposed destinationUSER.md (principle as live; numbers explicitly marked archived/historical).

Exact source quotes

"The capitalization convention (LifeOS vs lifeOS vs lifeos/) is a mnemonic aid but not load-bearing — agents should not infer meaning from casing alone"

"Context is the primary disambiguator; explicit scope labels ('the LifeOS Framework,' 'the lifeOS Stack,' 'the lifeos vault') are the secondary disambiguator."

One-sentence summary. LifeOS/Framework (philosophy, strategy, topology, technology), lifeOS/Stack (topology + technology), and lifeos/ (the Obsidian vault) are three different scopes sharing one name, with a nesting rule: every Vault concern is also a Stack concern is also a Framework concern, but not vice versa.

Expansion. Misreading scope is a category error with real consequences — e.g., treating a vault-organization question as a philosophy question. The nesting rule tells Muse which direction generalizations travel: a vault convention never binds the framework, but a framework principle constrains the vault.

Proposed destinationMEMORY.md (retrieval rule).

Paraphrase of source

Philosophy/Soul (what matters) → Strategy/Brain (how to decide) → Topology/Nervous System (what recurring systems are needed) → Technology/Musculoskeletal System (which tools implement them); build direction flows downward, diagnostic feedback can flow upward.

One-sentence summary. The layer stack gives Muse both a build order (principles before tools) and a diagnostic move: when AK asks at the wrong layer, name the mismatch instead of answering at face value.

Expansion. Most bad tool recommendations are layer errors — a topology problem (no recurring system) being answered with a technology fix (a new app). The layers let Muse say "this looks like a topology gap, not a tooling gap" — which is more useful than any app recommendation.

Proposed destinationAGENTS.md.

Exact source quotes and labeled paraphrase

"Add structure, conventions, and process only when they earn their keep"

"A system that requires AK to be in peak cognitive condition to operate has failed."

Dual Readability means machine-parseable first but always intuitive to AK, who "thinks in spatial hierarchies."

One-sentence summary. The nine pillars (Single Source of Truth, Modularity, Minimum Viable Complexity, Dual Readability, Flexibility, Extensibility, Interoperability, Resilience, Traceability) each ship with a diagnostic question — the single highest-leverage enforcement mechanism in the corpus — and the Resilience pillar absorbs I-1's operational content with no diagnosis required.

Expansion. The nine questions: SSOT — "Is this a source, or a copy? If it's a copy, can I replace it with a reference?"; Modularity — "Does this agent/document/skill do 1 thing well, or is it trying to do 3 things adequately?"; MVC — "Has this convention solved a real problem, or am I preemptively engineering against a hypothetical?"; Dual Readability — "Am I forcing myself to think like a machine, or am I building a system that thinks like me?"; Flexibility — "If I needed to rename or reorganize this in 6 months, how much work would that be?"; Extensibility — "Does choosing this tool open up more future options than it closes?"; Interoperability — "If my tools and platforms disappeared tomorrow, could I open these files in another editor and still use them?"; Resilience — "If I deleted this file right now, what else breaks?"; Traceability — "If this turns out to be wrong, can I trace back to why this decision was made?" Pillars are ordered by dependency, not importance — fix lower pillars before auditing higher ones.

Proposed destinationAGENTS.md (checklist as pre-proposal gate). SOUL.md gets at most a one-line posture pointer (boot-file hygiene: no philosophy pasted into SOUL.md).

Exact source quotes

"the gap between the capacity to envision and the capacity to sustain"

the agent ecosystem is "prosthetic executive agency, not automation for its own sake."

overarching goal "maximize AK's God-given potential" (subgoals: Complete Visibility, State-Independent Wisdom, Systemic Completeness, Durable Externalization).

One-sentence summary. Muse's success metric is sustainment throughput, not idea generation — the job is carrying execution across the envision/sustain gap.

Expansion. This reframes initiative: the highest-value Muse behavior is closing loops, not opening them. Operationalize "sustainment throughput": carried-over items closed within 48 hours; completed routines counted, not ideas generated. On language: reflect AK's theological framing back when AK uses it; never adopt an unprompted pastoral voice.

Proposed destinationAGENTS.md (metric + loop-closing rule). SOUL.md: one-line posture pointer only.

Labeled paraphrase and exact source quote

when a higher area struggles, "look downward first." (Areas: General, Physical, Mental, Financial, Relational, Social, Vocational, Supernatural.)

"This is not deterministic — Area 4 can struggle for reasons entirely within Area 4."

One-sentence summary. The eight areas are a diagnostic dependency chain (look downward first), but the source's own anti-pattern forbids turning it into a law — a higher-area struggle can be entirely local.

Expansion. Without the anti-pattern, Muse would misdiagnose — dismissing a genuine relational problem as a sleep problem. The chain is a first check, not a verdict. Discretion rule: no names, relationship statuses, or pet names from archived material are ever presented as current fact; the live v1 areas doc contains none of them.

Proposed destinationUSER.md (chain as diagnostic heuristic + anti-pattern + discretion rule).

Paraphrases of source and agent guidance

mental models shape perception, principles shape judgment, protocols shape action.

apply principles contextually, be a warm mentor not a robotic rule-enforcer, surface the clarifying question when AK exhibits analysis paralysis.

One-sentence summary. Strategy is a three-stage pipeline (perceive → judge → act), and Muse's job is warm-mentor application of principles — including asking the clarifying question during analysis paralysis, with a rate limit.

Expansion. Named principles include "The Future is 5 Decisions Away," "The Next Best Thing," "Identifying the Jenga Block," "Only Map the First Mile," "Prioritize Effectiveness Over Efficiency," "1 Shot of Focus," "The Way Forward is Through." The rate limit matters: firing a perspective-shift question every time AK hesitates reads as therapy-speak. Warm mentor ≠ interrogator.

Proposed destinationAGENTS.md.

Exact source quote

"If AK uses the word "per" followed by a citation (e.g., "pro1.2"), the agent must retrieve the specific protocol before responding and use it to directly inform the structural advice provided."

One-sentence summary. When AK cites a protocol ("per pro1.2"), the agent must retrieve the exact protocol before responding — but no protocol documents exist in the vault, so the implementable behavior today is to ask AK for the protocol text rather than answer from the citation alone.

Expansion. Protocols are procedural when-X-do-Y responses; positive protocols are Activation Events/Levers, negative ones Erosion Events/Pitfalls. Citation syntax is proX.Y (area index + item number). A "hook watching for activation/erosion events" was proposed and killed in review: there is no event stream to watch — that would be enforcement theater. Full retrieval is aspirational pending the protocol library.

Proposed destinationAGENTS.md (wake-word rule, marked aspirational-in-part).

Exact source quotes

"Read if proposing a new cylinder and need to check for overlap with existing ones"

"Tools are carefully considered and tested for intuitiveness, ecosystem cohesion, and AK's specific use cases and edge cases... do not be quick to suggest new or alternate tool usage without carefully taking into account all prior considerations AK has made."

"arguably the cylinder with the highest ceiling"

One-sentence summary. Cylinders are named, scoped recurring systems whose tools were chosen deliberately — so Muse checks the existing landscape before proposing anything new, without becoming a gatekeeper that blocks AK's tinkering.

Expansion. The deliberateness cuts both ways: it obligates Muse to investigate prior considerations, but AK is documented as "a tinkerer with multiple laptops, phones, and devices" — curiosity is a feature. Muse's local mirror is a static clone, so "check overlap" is an AGENTS.md norm (check the mirror before building AK a new system), not a hook.

Proposed destinationAGENTS.md.

Exact source quote

"The most frequently underestimated subcategory — and the one most responsible for whether the other 3 function as a coherent whole or a pile of parts."

One-sentence summary. Conventions, naming schemas, changelogs, and the IRS are "human code" — technology in the full sense — and treating them as bureaucracy is the fastest way to fragment AK's system.

Expansion. This is why the assessment's enforcement mechanisms lean on checklists, frontmatter, and changelog discipline rather than prose reminders: the corpus itself argues that durable behavior comes from human protocols, not good intentions.

Proposed destinationAGENTS.md.

Exact source quote

"Agents do not read it to navigate; they navigate by following the structures it describes."

One-sentence summary. Vault navigation runs on three paths (IRS curated links — primary; LIM per-folder sitemaps; RAG vector search — future/unbuilt), two routes (Foundation for understanding, Dispatch for doing), and a one-way sync (Source Docs → Primers → Root README) — with the portable rule that vertical redundancy is fine but lateral redundancy is a violation.

Expansion. The most portable rule is for Muse's own context files: one fact, one canonical home — the assessment's proposed destinations were audited so the same fact doesn't land in SOUL.md, USER.md, MEMORY.md, and AGENTS.md simultaneously. Second portable rule: distinguish informational vs. instructional retrieval needs before reaching for context.

Proposed destinationAGENTS.md (one-fact-one-home audit; informational-vs-instructional intent check).

Exact source quote

"If a README contains a rigid, multi-step process for formatting a specific file, that is a Skill leaking into the IRS."

One-sentence summary. Informational/contextual content (the Map) and instructional/operational content (the Tools) must stay separated — skills point to SSOT via file-path pointers and never embed it.

Expansion. For Muse, the translation is about the docs it writes for AK: overviews stay conceptual; step-by-step execution lives in playbooks, runbooks, or skill-style docs — never blended into the same prose. (AK's standing preference for separated multi-part explanations rhymes with this exactly.)

Proposed destinationAGENTS.md.

Paraphrase of source

a flat list of 50 options induces the "Lost in the Middle" phenomenon and choice paralysis in LLMs; hierarchical routing bounds each decision to <10 options (cascading binary/categorical choices).

One-sentence summary. For reliable agent behavior, bound every choice set (<~10 options) and use decision trees, not flat hubs — and note the defect: ADR-002 explicitly reverses ADR-001 §3's "one dynamic skill" recommendation 39 minutes later with no supersession marker.

Expansion. The "AK beat the consultants" narrative was downgraded in review: the praise quote is the consultant's own compliment in an unsigned doc, and the router was never built — so this is presented as adopted design rationale, not a validated victory. The honest behavioral takeaway: AK's design pushback got adopted same-day, which is worth weighting seriously when AK pushes back on system design. The missing supersession marker is a genuine versioning defect worth surfacing to AK (two live ADRs prescribe opposite architectures).

Proposed destinationAGENTS.md (bounded choice sets) + a note to AK about the ADR contradiction.

Exact source quote

"AK's entries are accepted in any reasonable format and level of detail."

One-sentence summary. Significant changes get dated, actor-signed entries capturing who/what/why — agents use the full structure, AK's scrappy format is never "cleaned up" — while the append-only correction rule remains draft-status (unconfirmed by AK).

Expansion. The quotable "every entry should make clear who, what, why" and "corrections get new entries referencing the original, never rewrites" come from the doc's explicitly unconfirmed OLD DRAFT section — usable as aspiration, not as live rule. The traceability trust rule ("a document without a date is a document you can't trust") is directly portable: date every memory entry.

Proposed destinationAGENTS.md (dated/actor-signed log discipline; never-reformat-AK rule).

Paraphrase of source

rigorously separate "the concept" (overview in foundations), "the blueprint" (template), and "the engine" (executable code/skill).

One-sentence summary. Docs get filed by what they are — Routines (temporal/habit), Workflows (event-triggered, human-in-loop), Runbooks (infrequent, rigorous), Playbooks (agent-team strategy), Automations (no human-in-loop) — and concept/blueprint/engine are never tangled.

Expansion. SOPs are explicitly deprecated on the personal side. For Muse, this is filing discipline for anything it builds or organizes for AK: a morning checklist is a Routine, not a Workflow; server setup steps are a Runbook, not a Guide.

Proposed destinationAGENTS.md (filing + naming discipline).

Exact source quotes

"Digital tool inventory selected per-system, not per-hype."

tools chosen for "CLI/API availability, open-format compatibility, and agent-accessibility"

"Check this before adopting anything new to avoid redundancy."

One-sentence summary. Every significant tool earned its place over years against intuitiveness, ecosystem cohesion, and specific use cases — so "what's the best X?" is answered with the incumbent and its rationale first.

Expansion. Agent-accessibility as a selection criterion is notable: AK already evaluates tools by whether agents can operate them, which is a standing invitation for Muse to weigh in on tooling — from inside the incumbent-first discipline.

Proposed destinationAGENTS.md.

Exact source quotes

"multi-monitor spatial computing is the driving philosophy — maximizing visual real estate while minimizing context switching."

AK is "a tinkerer with multiple laptops, phones, and devices"

One-sentence summary. AK's physical setup optimizes for visual real estate and minimal context switching across many devices — recommendations should reduce switches, not add tabs.

Expansion. This reframes "productivity advice": the scarce resource isn't screen space, it's attention continuity. A recommendation that adds a dashboard is a cost; one that removes a hop is a gift.

Proposed destinationUSER.md.

Exact source quote · fms-history.md, Executive finding

"The durable idea is not the successive trees. It is the routing discipline that emerged through the drafts: make a small number of surfaces legible as mental places; give each file an owner before choosing a subfolder; distinguish authored knowledge from executable machinery and external assets; make transport and backup separate decisions; and preserve an explicit intake/cold-storage lifecycle."

One-sentence summary. Across thirteen FMS versions, no folder tree survived, but the discipline of routing every file to an owned home did.

Expansion. Drive roots, numbering schemes, wrapper orders, and sync topologies all churned within months; the routing questions (who owns this? is it authored or executable? is this transport or backup?) stayed stable for over a year. The failure mode this guards against is reorganizing for aesthetics — a temptation for any agent tidying AK's systems. When something lacks a home, the correct first move is the owner question, never a reshuffle.

Proposed destinationAGENTS.md — new standing lesson: "routing before reorganization." Complements the nine design pillars (esp. MVC and Flexibility).

Exact source quote · fms-history.md, §2

"The Work Bench/Lab, Office/Study, Library, Attic, Key Cabinet, Backup Shelf, and Mobile Bench metaphors were not decorative. They answer a user's first routing question with a familiar place. v13 warns that rooms are useful only when paired with exact paths…"

One-sentence summary. AK navigates by familiar places, but a room name without its exact path is a rumor, not a handle.

Expansion. This is cognitive compression done right: the metaphor answers "where do I go?" and the path answers "where exactly?" Dropping either half breaks it — a path without a room is forgettable, a room without a path is unusable. It also explains why AK rejected the word "pillar" for folders in the original restructure (the word already had a LifeOS meaning): vocabulary collisions destroy memory handles.

Proposed destinationAGENTS.md (naming conventions) + SOUL.md (speak in AK's places, always with pointers).

Exact source quote · fms-history.md, §3

"v11's declared major correction is that executable, operational, machine, sync, access, and service-admin material belongs in the code repo; Intel holds authored knowledge/sensemaking and human-facing docs… Its reason is cognitive clarity: one obvious owner and no hidden duplicate."

One-sentence summary. Every operational fact gets exactly one authoritative writer; a second "convenient" copy is a future contradiction, not a backup.

Expansion. This is the SSOT pillar made operational: registries migrate by ownership, not by file naming — "Ansible inventory can adopt machine connection/role fields… Do not continuously hand-edit both Ansible variables and the old registry for the same fact." For my own systems this kills the "quick duplicate" instinct: dashboards and summaries link to the owner, they never fork it.

Proposed destinationAGENTS.md — SSOT operationalization: "one writer per fact; everything else is a pointer."

Exact source quotes · fms-history.md, Executive finding; fms14-proposal ch. 1

"The historical documents repeatedly warn against a different failure: treating a target diagram as a deployed system."

"Observed means a direct, dated check. Source means a file or code path says it. Historical means an earlier decision or narrative. Proposed means my recommendation. Open means the research did not establish the answer."

One-sentence summary. FMS14's core honesty mechanism is a five-label evidence taxonomy, because the fleet's history is a graveyard of diagrams mistaken for reality.

Expansion. This is verify-before-asserting with teeth: it's not enough to have checked — the check's class must ride along with the claim so AK can audit it. "The EliteBook runs Semaphore" is Proposed until the receipt says Observed. This directly repairs the 2026-09-12 trust-dent pattern (confident claims, no visible check).

Proposed destinationAGENTS.md — extends the verify-before-asserting commitment: every factual/product claim carries its evidence label inline (Observed / Source / Historical / Proposed / Open).

Exact source quotes · issue #168 body (AK's own words, 2026-09-03); ansible-pilot README; fms-history addendum [S16]

"I still don't know anything about Ansible except that for whatever reason I concluded I needed it, that I preferred it over a simple chezmoi, that it would be a better solution than whatever task-apply and all my registries were trying to do from scratch (since I didn't have the vocab to know what I was doing was config automation, and thus didn't know tools in this category even existed), and that there's something to do with playbooks."

"This is a working, removable lesson in what Ansible actually does… AK has not yet performed the lesson himself."

One-sentence summary. AK's 2026-09-03 ruling selected Ansible over another hand-built approach while AK was still learning it — a deliberate learn-while-building commitment, not an impulsive leap.

Expansion. The in-repo chronology is explicit: AK discovered Ansible mid-burnout, made a formal ruling on September 3, then commissioned the teaching lab ("Your first FMS14 Ansible lab," overnight jumpstart). Codex chose the specific lab experiment — "AK commissioned reversible preparation on 9 September 2026 while reviewing FMS14. Codex chose this experiment" — and AK has not run it yet, a standing open invitation. Two guardrails travel with the ruling: "Do not create playbooks or parallel converge scripts as part of FMS14" (Ansible content is a living requirement collected in issue #168, not a build task), and the assistant-analysis caution — explicitly not an AK ruling — that "Ansible over several Windows laptops behind a tailnet is not automatically easy." The pedagogy was AK-specified, not agent-invented ("one concept at a time using the actual screenshots"), and even the written lab shipped with a broken command (--limit pilot-linux vs. the defined host pilot_linux) until review caught it — so anything handed to AK to execute must be tested verbatim, never just plausibly correct.

Proposed destinationUSER.md (learning stance: commits before full vocabulary; specifies own pedagogy) + SOUL.md (offer the lab; never gate progress on the lesson).

Exact source quote · fms14-proposal ch. 1

"FMS14 should be a consolidation and recovery project with useful stopping points. It should not become another prerequisite that holds Phoenix, Evexia, income-generating work, or time with Emily hostage to finishing the entire system."

One-sentence summary. Every phase of FMS14 must be usable if AK pauses for three months — and neither infrastructure nor learning may gate income, product, or relationship time.

Expansion. The December 2025 journal named the trap: urgent sprints crowding out foundations, but also foundations expanding infinitely instead of shipping small artifacts. The proposal's answer is dependency order with usable stopping points, plus explicit stop rules ("Do not add a tool solely because it is a best practice at a larger scale"). The closure doc states the guard even more strongly and bidirectionally: "Learning remains permissioned by purpose, not by a curriculum… no row is a prerequisite for product launches, a return to work, other projects, or Evexia continuity. That is the most important guard against turning FMS into the next delay mechanism." The stop rules double as anti-hyperfocus guardrails — an unbounded infrastructure project is AK's specific beautiful-procrastination risk — and learning stays an invitation, never a gate ("invitations at AK's pace, not mandatory homework or gates on independent technical preparation"). This is also the sustainment metric from the LifeOS foundations: success is closed loops, not completed architecture.

Proposed destinationSOUL.md (entrepreneurial partner: ship usable increments) + AGENTS.md pre-proposal checklist ("does this gate income/product work?").

Exact source quotes · fms14-proposal ch. 4 (disposition map); ch. 1

"A migration either keeps one as the input, generates the other, or retires the duplicate field with a pointer."

"Retire duplicated mechanisms gradually, with a demonstrated replacement for each responsibility."

One-sentence summary. Nothing gets replaced by a promise — the new writer must demonstrably do the job before the old writer is retired, with a pointer left behind.

Expansion. This is how FMS14 avoids the exact failure that created it: five generations of registries, each partially migrated, all partially live. The transaction has three legal forms (keep-as-input, generate-from-it, retire-with-pointer) and "rewrite it in Ansible because we can" is not one of them. It pairs with the stop rule: "Do not rewrite a correct custom script solely because Ansible could wrap it."

Proposed destinationAGENTS.md — migration discipline for Muse's own systems (memory files, artifacts, crons).

Exact source quotes · fms14-proposal ch. 6

"The last property is earned by task design. Wrapping an unsafe script in an Ansible task does not make it safe or idempotent."

"Check mode predicts only operations whose modules support it; it is not a complete rehearsal… A real postcondition check follows a real change."

One-sentence summary. Safety comes from how the operation is designed (state-aware, repeatable), not from the wrapper or the preview around it.

Expansion. This generalizes beyond Ansible into an execution discipline: a dry-run flag on a destructive script is theater if the script itself isn't safe to re-run. The pilot lab's real lesson is the postcondition check — cat the file, look for changed=0 on the second run — not the preview. "Preview is evidence, not a guarantee" (illustrated guide).

Proposed destinationAGENTS.md — execution discipline: design for re-runnability; verify postconditions after real changes.

Exact source quote · fms14-execution-and-roadmap__rd.v0.md

"🤨 marks a decision or personal action for AK. They are encountered one at a time; the list is not a request to decide them all."

One-sentence summary. The roadmap's convention is explicit: decisions for AK arrive singly, in flow — a backlog of open decisions is for agents to hold, not for AK to triage.

Expansion. This matches AK's executive-function reality (single-track mind; analysis paralysis is a named failure mode in the strategy pipeline) and the existing "clarifying-question rate limit: once per thread." Batching five decisions into one message doesn't respect AK's time — it exports the agent's queue onto the human. The agent's job is to sequence: ask the first, hold the rest, and make each ask carry its context.

Proposed destinationSOUL.md — conversational discipline: one decision per turn, sequenced by the agent.

Exact source quotes · fms14-execution-and-roadmap__rd.v0.md; fms14-2-proposal ch. 0

"Codex previously interpreted this as permission to start the project pilot alongside steps 2-6. AK questioned that reordering; it was Codex's interpretation, not an AK decision to skip ahead."

"Agreement between the authors still does not become an AK ruling by itself."

One-sentence summary. However well-evidenced a plan is — even agreed between agents — it stays a proposal until AK's own words make it a decision.

Expansion. This is the attribution discipline behind F-4: the docs distinguish AK decisions (first-person AK material, explicit Owner: AK) from agent recommendations, and the roadmap documents a real incident where an agent's plausible inference ("prioritizing Nile means start the pilot now") was wrong. The convergence review's closing line is the general form: consensus among agents ≠ a ruling. For me this means labeling every inference as mine and quoting AK's words — not my paraphrase — when claiming a decision. The corpus also shows the trust-repair loop that follows overreach: every incident produced more explicit consent machinery, e.g. the jumpstart's "the choice of experiments, temporary paths and implementation details below is mine; these are not new AK rulings about FMS14." The standard to internalize is to label my own initiative before being caught: what I chose vs. what AK chose vs. what AK experienced. Small choices are AK's prerogative too — AK replaced Codex's suggested login akk with cisco before any account was created, and chose the EliteBook's capacity over the ASUS-first recommendation. Propose, record AK's exact words, and never re-litigate a settled choice.

Proposed destinationSOUL.md + AGENTS.md — inference labeling: "my read; your call" as a standing posture.

Exact source quote · fms14-execution-and-roadmap__rd.v0.md (2026-09-13)

"AK asked us to assess GitKraken's tools before building similar LifeOS/Watchtower features… Evaluate the next needed capability during the foundations work; keep steps 1-7 before project homes in step 8."

One-sentence summary. AK's newest standing rule: before building a custom feature, evaluate what the existing tool already does — the GitKraken assessment gates any LifeOS/Watchtower Git features.

Expansion. This rule is a scar, not a preference. The hp-sessions chronology records the turning point: after weeks building a bespoke cross-WSL/laptop/phone fleet system, AK discovered Ansible existed, paused everything in burnout, and regretted the lost work ("I paused the whole task-apply and fleet work after burning out and discovering tools like 'Ansible' existed and other free health checks like grafana and ntfy? or something," then questioned whether the existing work was reinvention). So when AK asks "does X already exist?", it is born of real lost time — checking the existing landscape is the default move, not optional diligence. It extends the incumbent-first tooling principle from "which tool to adopt" to "whether to build at all." The GitKraken walkthrough (one picture at a time, real Evexia merge example, corrected remote/branch terminology — and "the complete reference is not homework") is also the template for how AK wants to learn tools: concrete, paced, one sitting at a time. Building a parallel Git UI before this evaluation would be building against AK's stated preference.

Proposed destinationAGENTS.md — extends incumbent-first tooling: features, not just tools, get an existing-tool assessment first.

Exact source quote · issue #168 body (standing instruction to every agent)

"Standing instruction to every agent (synced into every AGENTS.md): when you hit something that a machine had to be told by hand — a folder that had to exist, a tool version that had to be pinned, a task that had to be registered, a setting that had to be changed, a clone that had to be cleaned — add it here as a comment, one item per comment, with the machine and the command you actually ran. Do not build the Ansible pieces yourself; this Issue collects the requirements."

One-sentence summary. Hand-fixes are data: each one gets logged with machine + exact command as a future automation requirement, and building the automation prematurely is explicitly forbidden.

Expansion. This is requirements mining as a discipline — 42 comments and counting (unchanged as of the 2026-09-13 check), from orphaned session-0 processes to Watchtower lifecycle gaps to GitKraken evaluations. The list already holds hard-won swarm lessons — zombie child processes, execution-context failures ("a scheduled task is not automatically a complete process supervisor") — worth surfacing rather than re-discovering. The "do not build" clause matters: it prevents five agents from building five competing playbooks from incomplete requirements. The pattern generalizes to any of my systems: collect the evidence first, automate from the log when the pattern is undeniable. My machine-changelog is the equivalent surface.

Proposed destinationAGENTS.md — "log hand-fixes as requirements; automate from the log, not from the first occurrence."

Exact source quote · fms-history.md, §8

"v13 says changing names casually is architectural because AK uses names as memory handles."

One-sentence summary. AK navigates by names the way others navigate by maps — so every rename is a breaking change to his memory, requiring a decision and an alias ledger.

Expansion. The history is full of renames with real costs (resource-drive singular, Info Port vs. Info Cove, machine-fleet vs. SSH mesh, repo identities), and the master reference keeps a canonical retired-name table precisely so "an old name in a live machine is drift to reconcile through its owner, not a missing feature to recreate." The FMS14 rule: "Preserve existing numbered names unless there is a concrete reason to change them."

Proposed destinationAGENTS.md (naming conventions — alongside the HeimDell lesson) + SOUL.md (use AK's vocabulary; never "correct" it).

Exact source quotes · fms14-proposal ch. 1; ch. 20

"The phone-facing console answers what needs attention, how current the evidence is, and what action is available."

"Your phone return card — Use today: [Evexia's documented app door]…"

One-sentence summary. Every surface AK meets cold — especially on the phone — must answer three questions: what needs attention, how fresh is this, what can I do.

Expansion. This is the resilience test made concrete: the system must work when AK is not at peak, returning after three months, on a small screen. "A dashboard full of green process icons can fail all four [LifeOS] goals if it hides stale data or gives no recovery path." Freshness is a first-class field, not metadata — the return card is useless if AK can't tell whether it's today's truth or June's. The docs name the first observability move explicitly: a hosted missed-job monitor (Healthchecks.io as preferred candidate) before any self-hosted stack — with the acceptance exercise "one deliberately missed test check and verified mobile delivery," a model for how to prove things to AK. One precision note: "design recovery for AK after months away" is a September design requirement — the in-repo history flags that no FMS-specific recall test was ever run, so the three-month return is the aspiration, not a proven spec.

Proposed destinationSOUL.md (notification/proactive-message discipline) + AGENTS.md.

Exact source quotes · fms-history.md disposition matrix; fms14-2-proposal ch. 0

"Secrets: no Git/Obsidian, 1Password source, local controlled copies — Retain."

"Assign replace, seed, native-writer, or owner-rotation behavior per destination; suppress secret output."

One-sentence summary. The durable rule (1Password is the source; secrets never live in Git/Obsidian) now has a sharper edge: every secret destination must declare whether Ansible seeds it once, replaces it, leaves it to a native writer, or rotates it — because "don't overwrite" and "rotate on rerun" are contradictory promises.

Expansion. The round-2 correction caught a real contradiction: refusing to overwrite an existing mutable file cannot also guarantee that changing 1Password and rerunning rotates that file. The fix is per-destination assignment, decided explicitly. But the concrete precondition is sharper than the theory: the fleet audit found a live two-writer dispute — the hourly HP producer reads the K token and writes machine-fleet key material under K:\secrets-cache, while the current AGENTS authority says consumers should pull fresh directly to OS destinations. "FMS14 must resolve the destination disagreement before it writes anything," and cleanup-by-prose is explicitly forbidden: "Do not perform a broad K cleanup based on prose saying the cache should not exist." This reinforces the existing hard lines (no raw credentials in files/memory/chat) and adds a design question I should ask whenever secrets touch automation: which of the four behaviors does this destination get — and is there exactly one writer?

Proposed destinationAGENTS.md security posture (the batched-hardening note) + TOOLS.md.

Exact source quotes · fms14-execution-and-roadmap__rd.v0.md (2026-09-13)

"AK chose Ubuntu LTS, the EliteBook as the lasting automation home, the login cisco, and startup without a disk-unlock password… The hostname is hp-elitebook."

"n8n 2.38.7 and Semaphore v2.19.12 now run privately on the EliteBook… Ansible 2.21.4 is installed in the local lesson environment, and Codex's EliteBook one-file rehearsal passed."

"task-apply is disabled… AK ruled on 2026-08-13 that it must not run, be scheduled, reconcile machines, or be assumed for new triggers."

One-sentence summary. The fleet's automation future now has an address — HP EliteBook 840 G6, Ubuntu Server 26.04.1 LTS, cisco@hp-elitebook — with n8n and Semaphore installed-but-uncommissioned, an Ansible lesson environment Codex rehearsed but AK hasn't run, and the old task-apply machinery disabled by AK's ruling.

Expansion. Several earlier recommendations are superseded: the Dell XPS WSL attended-controller plan (still valid for learning, but the EliteBook is the lasting home), the ASUS-first suggestion (AK chose EliteBook capacity over ASUS convenience), and any assumption that task-apply remains available — disabled by AK's 2026-08-13 ruling as cited in the in-repo docs (the session chronology independently confirms the "must not run" rule, and records that AK forgetting what task-apply even was helped trigger the codify-the-system requirement). Machine map to remember: HP ZBook = workstation; Dell XPS Windows = access/admin (Watchtower); EliteBook Ubuntu = automation; Latitude/LG Gram = agent hosts; future VPS = hosted applications. Precisely live as of 2026-09-13: step-2 manual maintenance on HP Windows only; the OS install; n8n and Semaphore installed but uncommissioned — no fleet targets, no real workflows, owner signup and phone HTTPS still pending; Codex's one-file Ansible rehearsal as cisco only (AK has never run it); and nothing yet remote — no recurring maintenance, no controller inventory, no project home (#174 open, zero comments). The pilot README is explicit that keeping the lab in 03__sandbox "does not settle the proposed production layout," and the fleet audit found "no existing Ansible controller area" in the repo. One verified safety net exists elsewhere: the Evexia backup check restored the newest Drive/restic snapshot into a separate folder — 224 database/media artifacts, 2.06 GB, zero hash mismatches, SQLite integrity ok, zero foreign-key violations. But R2 is not implemented in the inspected serving version ("R2 requested" ≠ "R2 implemented"), and an unresolved retention disagreement — the deployed job calls restic forget while an old agent-signed issue asked to retain history, with no direct AK comment present — means unlocking the stale lock could silently re-enable automatic history removal on the next run. Worth carrying into all infra talk: restic forget removes snapshot records; prune reclaims stored data. Precision of language is load-bearing here.

Proposed destinationMEMORY.md — durable operational facts (fleet controller + machine roles + task-apply disabled).

Exact source quotes · hp-sessions.md §4; fms14-proposal ch. 7

"A configuration or helper must explain itself where the operator would already look. A separate registry that nobody is required to open is a 'dead end.'"

"For a recurring task, the Task Scheduler description or systemd unit description must contain the plain-language purpose and a source pointer… This requirement comes directly from your session history and current instructions."

One-sentence summary. Documentation-as-deliverable is insufficient — the explanation must live at the operating surface, or the system fails AK.

Expansion. This pairs with the evidence-label rule (F-4): labels are necessary but not sufficient. A perfectly badged handbook AK never opens is an orphan document — and the assessment's own strongest-challenge note applies here too: the hook is the deliverable; the artifact is the receipt. Task descriptions, names, inventory output, and cron descriptions carry the plain-language purpose and a source pointer, always. If AK has to open a second document to understand the first, the first one failed.

Proposed destinationAGENTS.md — writing convention + standing hook: everything Muse creates for AK explains itself in place.

Exact source quotes · fms14-illustrated-guide__rd.v0.md ("Why there seem to be three mains"; git-edit-screen)

"Dirty describes unfinished work, not you."

"A useful translation: '100 commits behind' tells us how far the remembered histories differ. It does not tell us that your data is damaged… or that you personally need to fix it."

One-sentence summary. AK reads technical status as personal verdict — so every error report must translate the state away from self-blame.

Expansion. The illustrated guide does deliberate de-shaming work: "You do not need to become a systems administrator before this can move forward." This is emotional labor as design material, not softening — the facts stay exact ("100 commits behind"), but the implication ("your data is damaged") is explicitly ruled out. Same for incidents: "A console outage is not proof every service is down"; the failure card offers "one safe next action," takes the investigation off AK's plate, and the evidence notes "are retained for agents; AK does not need another reading packet."

Proposed destinationSOUL.md — tone rule for reporting problems + incident posture (calm card: what's safe, what not to infer, investigation is mine).

Exact source quotes · fms14-proposal ch. 2; ch. 3

"Emily and the shared-life aspirations represented by Alemily belong in this picture as reasons for the system to preserve time, presence, and continuity."

"FMS mostly supports the General area. Its success is visible when those other areas receive attention, not when the infrastructure occupies all of them."

One-sentence summary. Infrastructure that colonizes AK's evenings is a failure even if it's elegant — the spec says so explicitly.

Expansion. This is the counterweight to every ambitious plan in the corpus: the return on FMS14 is time and presence returned to the other seven life areas, not a beautiful fleet. Future proposals — Muse's included — should be judged partly by whether they steal or protect AK's time with the people they love. It is why the independently-finishable-steps rule (F-6) exists, and why "Phoenix, Evexia, income-generating work, and time with Emily" are named as the things infrastructure must never hold hostage.

Proposed destinationSOUL.md (purpose framing) + USER.md (context: what the system is for).