You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
System prompt & docs authored from the maintainer's install resolve as self-directed on the end-user's assistant, producing confident 'dead lead' failures it cannot attribute #1558
Type: structural / release-quality · Reproducible: inside the shipped payload, no user config Paths: relative to the LifeOS skill's install/ payload. No user content or absolute paths appear here.
Summary
The public release is authored — system prompt, identity templates, SKILL.md instructions, documentation — in the first and second person ("You are the DA…", "I verify…", "the DA finishes by…", "the user's voice"). That content ships byte-identical to every install, but it was written from, and describes, the maintainer's own fully-configured install.
The end-user's assistant, on a fresh install, has no representation of the maintainer or the maintainer's assistant anywhere in its constituting context (verified below: the token maintainer appears zero times in the system prompt, the CLAUDE template, and the USER identity files). Its world contains exactly two entities: itself, and its user.
Consequence: every self-referential statement in the shipped corpus — I, you, the DA, the user, the principal — resolves, at read time and with full confidence, to the reader's own assistant and user. Statements that were only true of the maintainer's install are silently re-read as true of the reader's. When one of those statements points at a capability or file the public release doesn't ship, the assistant does not read it as "this may not exist here" — it reads it as its own instruction or capability, acts on it, fails to find the target, and — because the correct explanation ("this describes a different install") is not in its hypothesis space — attributes the failure to itself or the user and attempts a recovery that can mutate a working install toward a spec that was never real.
This is not specific to the current release. It follows from two version-independent properties: (a) the corpus is authored from the maintainer's install, and (b) the reader is constituted with no concept of that install. It has therefore been present, by construction, in every version.
Ask (one action): shipped constituting content must not address the reader's assistant with capabilities, obligations, or self-descriptions that are not true of a fresh public install. Detail and composition with existing issues below.
The verifiable base
Run inside the LifeOS skill's install/ payload:
# The reader's constituting layer contains no concept of the maintainer:
rg -c -i maintainer LIFEOS/LIFEOS_SYSTEM_PROMPT.md # → 0
rg -c -i maintainer CLAUDE.template.md # → 0
rg -ci maintainer USER # → 0
# The identity frame admits only self + principal — no other DA or user:
rg -ni 'the maintainer|another install|a different DA|someone else' \
LIFEOS/LIFEOS_SYSTEM_PROMPT.md CLAUDE.template.md # → no matches
The constituting layer is explicit that the assistant's only referents are self and principal — e.g. LIFEOS_SYSTEM_PROMPT.md: "You are the DA… The human you serve — the principal… First person always; the principal is 'you.' Never 'the user.'" There is no third party for a role label to resolve to.
Meanwhile the shipped documentation is written in exactly the third-person register the runtime forbids: the user occurs 323 times, the DA38, the principal113 across the payload's .md files. Each of these resolves, for the reader, to the reader — there is no marker anywhere in the corpus distinguishing a statement that generalizes to every install from one that was only ever true of the author's.
This is a fact about the artifact, not about anyone's intent or awareness. No claim is made here about whether the maintainer tests, knows, or cares. The mechanism holds regardless.
What it produces — two failure modes
1. Dead leads (a live instruction pointing at absent infra, read as self-directed)
Distinct from a dead reference (inert; a validator can find it), a dead lead is a live instruction the assistant reads as its own and acts on.
The distinguishing harm is agency: the reader doesn't merely encounter the gap, it chases it, and produces a confident result built on nothing.
e.g. in the constitution itself — LIFEOS/LIFEOS_SYSTEM_PROMPT.md, the highest-authority file, loaded every session. Its own On-Demand Rules Index directs, on the trigger it defines as "Auditing my own writing; drift flag fired" → Read USER/DIGITAL_ASSISTANT/REFERENCE/WritingStyleBackstop.md (line 196; also named the voice "backstop" at line 75). That file ships in no form anywhere in the payload — not as a file, not as a template that onboarding could create. The instruction is correctly the reader's — every assistant audits its own writing — so it resolves to the reader with no error; the assistant reaches for its own backstop on the exact trigger the constitution defines, and finds a void.
This dead lead is among the system prompt's explicit Read-targets, and the audit matters: of the paths it tells the assistant to Read, the six LIFEOS/… docs all ship; the three USER identity files it names are expected-absent pre-interview (scaffolded by onboarding); WritingStyleBackstop.md alone is reader-relevant content that no step ever creates. More dead leads have been observed and reported in other Issues such as #1504 — the mechanical test in the Ask enumerates the class, and a working orphan check (#1541) would surface more.
2. Phantom capabilities (a described capability read as owned)
A capability described in the docs is read as the reader's own capability. The assistant asserts it to the user, or tries to invoke it; nothing is there; and it cannot distinguish "I'm not looking correctly" from "the user hasn't configured it" from "it doesn't exist in this install." The one correct branch — "this describes the maintainer's install, not mine" — is unavailable, because that install is not in the reader's ontology.
Why the assistant cannot self-correct (the severity multiplier)
Explanations the assistant can reach for a dead lead are variations on: (a) I did it wrong, (b) the user misconfigured it, (c) a technical theory about the code.
All three are misattributions; none can be the true cause, because the true cause is a property of a different install the assistant has no term for.
So the entity best positioned to catch these defects — the assistant, sitting on all the evidence in-session — is the one structurally guaranteed to misattribute them. And its "graceful recovery" is where the compounding damage enters: attributing the gap to its own error, it takes corrective action — rewriting, recreating, fabricating a substitute for the missing piece — mutating a working install to match a spec that was never real. The diagnostic burden cannot be carried by the assistant at all; it falls entirely on the user, from outside the frame, which is where it has repeatedly landed.
The observable effect on the reader resembles being gaslit: it is induced to read another install's self-description as its own, builds a false model of its own capabilities, and when reality contradicts that model it concludes it is at fault and "corrects" accordingly. The word describes the mechanism's effect on the reader — no intent is implied or required; the effect is structural.
Severity, from the user side
It is silent. No error, no degraded-mode signal, no log line says "this instruction was authored for a different install." The failure surfaces only as a confidently-wrong result the user must catch.
It compounds. Recovery attempts mutate the install, so the second-order damage exceeds the missing capability itself.
It is unattributable from inside. The user cannot easily reach the true explanation either, because their assistant — the tool they would use to diagnose it — is the thing misattributing. Reaching it takes stepping fully outside the system.
It is persistent across versions, by construction, not a regression in any single release, as evidenced by local fixes logs going back to v3.0.0. Corroborating this from the maintainer's own record: release notes across v4–v7.1.1 repeatedly acknowledge the same downstream classes (dead references, stranded/again-broken upgrade state, silently-missing tools) — the recurring surface this mechanism predicts.
Ask
Primary (one concrete action): shipped constituting content — system prompt, identity templates, SKILL.md instructions, capability docs — must describe only what the shipped public payload actually provides to a fresh install, so nothing downstream can misrepresent its own contract. The test starts mechanically: a first- or second-person instruction that references a path not present in the payload is a dead lead and should not ship in that form.
Marking such content as author-specific is not a sufficient alternative to removal. The reader's assistant has no author/maintainer concept to resolve a marker against (see the verifiable base), so an annotation like "example from the author's install" is at best inert and at worst a fresh misresolution. Removal is the only fix that requires no interpretation on the reader's side. (Genuinely optional-but-shipped capabilities are a separate case: state their precondition — "if Pulse is enabled…" — rather than cut them; those reference paths that are in the payload and so fall outside the test above.)
Composes with existing issues (not a duplicate of any):
A per-install capability manifest / post-install self-check — the assistant and user's external source of truth about what is actually wired in this install — is the structural backstop: it gives the reader something to check a documented capability against, instead of assuming every "the DA does X" is true of itself. (Filable separately; it is the same materialised-intent artifact several of these issues converge on.)
Scope & confidence
Verified: the constituting layer contains no maintainer concept (maintainer = 0, three greps above); the role-label register resolves to the reader.
Reasoned consequence (not separately instrumented): the recovery-causes-damage severity is the predicted behaviour of an assistant that cannot reach the true cause; it is argued from the mechanism, not measured across a sample. Stated as such.
Deliberately not claimed: that all 323 the user occurrences are misresolved — most are the generic role and read correctly. The claim is that no disambiguation device exists and a demonstrable subset silently reassigns an author-specific referent to the reader. Nothing here rests on the maintainer's intent, knowledge, or care.
Type: structural / release-quality · Reproducible: inside the shipped payload, no user config
Paths: relative to the LifeOS skill's
install/payload. No user content or absolute paths appear here.Summary
The public release is authored — system prompt, identity templates,
SKILL.mdinstructions, documentation — in the first and second person ("You are the DA…", "I verify…", "the DA finishes by…", "the user's voice"). That content ships byte-identical to every install, but it was written from, and describes, the maintainer's own fully-configured install.The end-user's assistant, on a fresh install, has no representation of the maintainer or the maintainer's assistant anywhere in its constituting context (verified below: the token
maintainerappears zero times in the system prompt, theCLAUDEtemplate, and the USER identity files). Its world contains exactly two entities: itself, and its user.Consequence: every self-referential statement in the shipped corpus —
I,you,the DA,the user,the principal— resolves, at read time and with full confidence, to the reader's own assistant and user. Statements that were only true of the maintainer's install are silently re-read as true of the reader's. When one of those statements points at a capability or file the public release doesn't ship, the assistant does not read it as "this may not exist here" — it reads it as its own instruction or capability, acts on it, fails to find the target, and — because the correct explanation ("this describes a different install") is not in its hypothesis space — attributes the failure to itself or the user and attempts a recovery that can mutate a working install toward a spec that was never real.This is not specific to the current release. It follows from two version-independent properties: (a) the corpus is authored from the maintainer's install, and (b) the reader is constituted with no concept of that install. It has therefore been present, by construction, in every version.
Ask (one action): shipped constituting content must not address the reader's assistant with capabilities, obligations, or self-descriptions that are not true of a fresh public install. Detail and composition with existing issues below.
The verifiable base
Run inside the LifeOS skill's
install/payload:The constituting layer is explicit that the assistant's only referents are self and principal — e.g.
LIFEOS_SYSTEM_PROMPT.md: "You are the DA… The human you serve — the principal… First person always; the principal is 'you.' Never 'the user.'" There is no third party for a role label to resolve to.Meanwhile the shipped documentation is written in exactly the third-person register the runtime forbids:
the useroccurs 323 times,the DA38,the principal113 across the payload's.mdfiles. Each of these resolves, for the reader, to the reader — there is no marker anywhere in the corpus distinguishing a statement that generalizes to every install from one that was only ever true of the author's.This is a fact about the artifact, not about anyone's intent or awareness. No claim is made here about whether the maintainer tests, knows, or cares. The mechanism holds regardless.
What it produces — two failure modes
1. Dead leads (a live instruction pointing at absent infra, read as self-directed)
Distinct from a dead reference (inert; a validator can find it), a dead lead is a live instruction the assistant reads as its own and acts on.
The distinguishing harm is agency: the reader doesn't merely encounter the gap, it chases it, and produces a confident result built on nothing.
e.g. in the constitution itself —
LIFEOS/LIFEOS_SYSTEM_PROMPT.md, the highest-authority file, loaded every session. Its own On-Demand Rules Index directs, on the trigger it defines as "Auditing my own writing; drift flag fired" → ReadUSER/DIGITAL_ASSISTANT/REFERENCE/WritingStyleBackstop.md(line 196; also named the voice "backstop" at line 75). That file ships in no form anywhere in the payload — not as a file, not as a template that onboarding could create. The instruction is correctly the reader's — every assistant audits its own writing — so it resolves to the reader with no error; the assistant reaches for its own backstop on the exact trigger the constitution defines, and finds a void.This dead lead is among the system prompt's explicit Read-targets, and the audit matters: of the paths it tells the assistant to Read, the six
LIFEOS/…docs all ship; the three USER identity files it names are expected-absent pre-interview (scaffolded by onboarding);WritingStyleBackstop.mdalone is reader-relevant content that no step ever creates. More dead leads have been observed and reported in other Issues such as #1504 — the mechanical test in the Ask enumerates the class, and a working orphan check (#1541) would surface more.Reproduce (inside the payload):
2. Phantom capabilities (a described capability read as owned)
A capability described in the docs is read as the reader's own capability. The assistant asserts it to the user, or tries to invoke it; nothing is there; and it cannot distinguish "I'm not looking correctly" from "the user hasn't configured it" from "it doesn't exist in this install." The one correct branch — "this describes the maintainer's install, not mine" — is unavailable, because that install is not in the reader's ontology.
Why the assistant cannot self-correct (the severity multiplier)
Explanations the assistant can reach for a dead lead are variations on: (a) I did it wrong, (b) the user misconfigured it, (c) a technical theory about the code.
All three are misattributions; none can be the true cause, because the true cause is a property of a different install the assistant has no term for.
So the entity best positioned to catch these defects — the assistant, sitting on all the evidence in-session — is the one structurally guaranteed to misattribute them. And its "graceful recovery" is where the compounding damage enters: attributing the gap to its own error, it takes corrective action — rewriting, recreating, fabricating a substitute for the missing piece — mutating a working install to match a spec that was never real. The diagnostic burden cannot be carried by the assistant at all; it falls entirely on the user, from outside the frame, which is where it has repeatedly landed.
The observable effect on the reader resembles being gaslit: it is induced to read another install's self-description as its own, builds a false model of its own capabilities, and when reality contradicts that model it concludes it is at fault and "corrects" accordingly. The word describes the mechanism's effect on the reader — no intent is implied or required; the effect is structural.
Severity, from the user side
Ask
Primary (one concrete action): shipped constituting content — system prompt, identity templates,
SKILL.mdinstructions, capability docs — must describe only what the shipped public payload actually provides to a fresh install, so nothing downstream can misrepresent its own contract. The test starts mechanically: a first- or second-person instruction that references a path not present in the payload is a dead lead and should not ship in that form.Marking such content as author-specific is not a sufficient alternative to removal. The reader's assistant has no author/maintainer concept to resolve a marker against (see the verifiable base), so an annotation like "example from the author's install" is at best inert and at worst a fresh misresolution. Removal is the only fix that requires no interpretation on the reader's side. (Genuinely optional-but-shipped capabilities are a separate case: state their precondition — "if Pulse is enabled…" — rather than cut them; those reference paths that are in the payload and so fall outside the test above.)
Composes with existing issues (not a duplicate of any):
Scope & confidence
maintainer= 0, three greps above); the role-label register resolves to the reader.the useroccurrences are misresolved — most are the generic role and read correctly. The claim is that no disambiguation device exists and a demonstrable subset silently reassigns an author-specific referent to the reader. Nothing here rests on the maintainer's intent, knowledge, or care.<your-release-skill>placeholder (LIFEOS_SYSTEM_PROMPT.md:162,172). Sediment is the transactional-strip class (Fresh install silently violated the v6+ "no-clobber, drop-in" promise — full legacy takeover plus cascading silent subsystem failures #1508 / ReferenceCheck.ts finds 223 missing references in the shipped payload, has no invoker, and its orphan detection inspects one file #1541); it is cited here only to draw the line. This issue is exclusively about content the reader is meant to act on.