LifeOS 7.40.4 — The Receipts Release

[danielmiessler]

Release page: https://github.com/danielmiessler/LifeOS/releases/tag/v7.40.4

LifeOS 7.40.4 — The Receipts Release

Thirteen days, 61 substantive changes, 30 community fixes, and one theme: the system now proves what it claims.

The oldest complaint about AI systems, this one included, is that they say "done" when they aren't. A run reports success and the test never ran. A dashboard glows green over data that doesn't exist. An installer corrupts the thing it installs and exits zero. Since 7.28.3, most of what we shipped attacks that gap from a different angle, and the community found more of it than we did. This release is where a lot of that work lands at once.

The Algorithm: the hill-climb you can see, and can't fake

The Algorithm went from 8.17.3 to 8.20.2, and the thread through every change is honesty about where a run actually is.

• The phase strip. Long runs now show their climb in the response itself, and the strip is computed by a hook from the run's real state; the model just echoes it. This exists because we caught a run claiming it was ascending while the board derived from the same data said it was still traversing. The model can no longer say one thing while the state says another; both read from one source.
• Euphoric surprise is now the meta-ideal-state of every ISA. Each ISA names the specific ideal state of one piece of work. Above every one sits the same universal goal: the person using the system gets exactly what they wanted, at the right speed, for the right spend. The doctrine now says this out loud, and the specific climb and the general one are one motion.
• Delegate briefs sized by blast radius. When the Algorithm hands work to a subagent, the brief's depth now scales with what the work can break, so trivial legs stop carrying ceremony and dangerous legs stop going out underspecified.
• ISA verifier classes and execution tiers. Claims now declare what kind of evidence closes them, and the machinery routes each claim to a verifier that can actually produce that evidence. "Should work" was already banned; the ban now has enforcement machinery behind it.

Everything ships with receipts: the release pipeline grew teeth

Users kept finding things in the public payload that our gates missed: dead template tokens, files that reference machinery that never ships, a maintainer's runtime state where a template belonged. Every one of those reports became a permanent, deterministic gate. The cut pipeline now runs 23 build gates plus a set of emit gates, and this cycle alone added checks for unrendered placeholders in live code, references to per-instance state files that never ship, retired capabilities still described as live, incident identifiers in shipped prose, hardcoded voice IDs in templates, and maintainer-only instructions presented to fresh installs as things they can run.

On top of the gates, every cut now ends with two independent read-only audits: a cross-vendor model reviewing the payload from outside our model family, and a fresh-context in-family pass attacking with insider knowledge. Findings from either block the release. The rule that makes this compound: every finding must also become a deterministic catch, so the same class can never need an audit again.

The community wave: 30 fixes from the people running this thing

Two triage rounds in this span ported 30 community contributions, and the reports were unusually good: reproduction tables, traced root causes, proposed diffs that survived review nearly unchanged.

Highlights, with the people who found them:

• Install no longer corrupts its own payload. The identity-substitution pass walked into the redistribution copy and baked one user's name into ~121 template files. Found by @Piroshki, root-caused by @DRAZY, fixed at the walk. Related: file modes now survive substitution, so hooks stop silently losing their execute bit (@alloutflo, @mark-219).
• Session names stop being word salad. The last-resort naming strategy planted a verb that let any four words pass validation, which turned non-English prompts into nonsense titles. Deleted; an unnamed session now just retries. Task verbs like "complete" and "finish" are also no longer banned from leading a name (@xmasyx).
• Voice lines survive a misnamed DA. If your assistant's configured name didn't match what it wrote, the system silently spoke a CHANGE bullet instead of the closer, for days. Extraction is now anchored to your configured name first with a safe fallback, and the fallback logs itself (@MatiasBarboza).
• Dashboards read the data that's actually there. The life hero rendered "Unknown, Unknown energy" while populated data sat one parser away; the check-in invented two of its three numbers; ISA progress mismatches were detected and then logged to nowhere. All fixed (@jacobo-ortiz, who filed seven forensic reports in one day).
• Forked subagents are now detected (@DRAZY), the proposal parser stops eating ordinary messages that start with "no" (@xmasyx), iMessage sending works on current macOS (@J0UH), the memory reviewer can no longer resolve a conflict it cannot source and stamp it as your stated fact (@Chuckos), and the DA identity template ships the schema its own docs define (@justinkatz94-glitch).

Pulse: a dashboard that ships working

The Pulse dashboard's static export is now actually in the release. Every prior release silently dropped it: 181 files swallowed by a gitignore rule, so fresh installs got a dashboard they had to build themselves. Now localhost:31337 works out of the box. Alongside it: scheduled jobs never voice-notify anymore (your cron jobs stop talking at 3am), a new guard blocks headless sessions from reaching the speaker at all, and the statusline gained a privacy overlay for security-engagement work.

Cortex, and the rest of the new machinery

• Cortex consolidation. The memory system's skills merged into one, with a weekly Distill pass that compresses accumulated knowledge before it silts up.
• Helm ships self-contained. The LifeOS terminal (kitty config layer, installer, app wrapper) now lives inside the release, with its installer hardened through three rounds of destructive-edge review.
• New skills: Novelty (evolutionary explanation-discovery for hard problems), SecurityMarketData (curated cybersecurity market intelligence), Vitals (macOS performance diagnostics), Share (self-hosted file sharing), and DetectAI grew deterministic statistical signals plus keyless watermark and steganography scanning.
• Hermes gained a zero-token heartbeat: calendar, mail, and queue ticks every ten minutes as pre-run scripts, so the sidecar stays current without burning a single model call.
• Vulnerability management now cross-references CISA KEV with a page-now override, and a new advisory ComplexityRatchet meter flags complexity drift on every edit without ever blocking one.
• Bunker joined the core component roster: the universal application harness's concept docs ship, with the reference implementation staying private by design.

For the people who asked "should I upgrade?"

A few discussion threads this cycle asked whether 7.x is worth it from 4.x or 5.x, and one user's DA even flagged our own installer as suspicious before recommending against upgrading. Fair. The honest answer is that this line of releases is specifically about making the system prove itself: commit-pinned downloads with printed checksums, an installer that backs up before it touches anything and restores itself if interrupted, gates that block us from shipping our own private data, and a dashboard that works on first boot. That is also why these notes walk through the work in detail: the receipts are the point.

---

Every contributor named above is also credited at the fix site in source and in the README. If you filed something that isn't here, it's tracked, and the next release's notes will say where it landed.

[garthsch]

@danielmiessler given the amount of Issue and Pull threads that have opened up on the new release, do you have any preferred format for LifeOS feedback? Maybe a new Skill or something for standardisation?

[danielmiessler]

For standardization of what?

[garthsch]

I've been reading through the Issues and PRs and I've got a nagging feeling that we could be doing it better. It's really obvious that some of the problems are issue based, some are logic based and some are just user based opinions. I have the intuition that there's a "best" method for submitting feedback, but as a technical though non-developer user, I'm loathe to dictate a process by parroting a formal software development lifecycle document back at someone who already knows it better than I do.

Many repos are having AI slop problems where the amount of code being submitted is overwhelming maintainers. I don't know your process, but would a standardised format or LifeOS Skill be useful in supporting the feedback loops back into LifeOS?

Separately: you've asked for testing against clean vs older installs in a few threads, but that's not really feasible for most users without significant work and token burn. Is there anything that could make that cheaper for contributors? I have a "LifeOS Refactor" project permanamently open for testing new features, could that sort of pattern be standardised for that sort of A-B testing?

Additionally, the vast majority of Issues and PRs have no labels and are simply accepted or closed. There's not a strong feedback mechanism to users on fix / won't-fix / future roadmap outcomes, things just show up or don't.

I'm not dictating a method, just wondering how we as users can feed back in a way that supports your workflow and token spend.

[danielmiessler]

Yeah, let me know what you're thinking here. I'd love to explore it.

[garthsch]

Thinking this through, I think the honest starting point is that my "permanent project open for testing" pattern doesn't generalize the way I implied. A standing sandbox stops being clean the day after you create it — it ages and drifts just like the live install does. What it actually gives me is the discipline: changes land there first, and nothing reaches my live install without an explicit review-and-promote step. That's a social contract you could put in CONTRIBUTING.md in three sentences, but it isn't tooling.

What I think could be tooling is the clean side, and turns out it already works today: checked install.sh and InstallEngine.ts just now, and both resolve everything off $HOME/homedir() — no hardcoded paths anywhere. HOME=/tmp/cleanroom-test bash install.sh already gives you a fully isolated clean install, and existingInstall keys off <configRoot>/LIFEOS/VERSION so it can't confuse a fresh tmpdir with a real one. So "a clean install at a pinned version" is already disposable — clone the tag, run with HOME redirected, probe, delete. Seconds, zero tokens, no upstream change needed.

The shape I'd propose is a probe ladder: deterministic first (hooks piped fixture JSON, tools as CLIs with exit codes, installer output asserted with file checks) covers most of the surface with no model in the loop at all. A single headless run with a human-judged diff would be the opt-in tier for prompt-file changes — and I'd say plainly that "the model behaves the same" isn't something you can assert deterministically, only eyeball cheaply.

The part I like most: run the probe on the clean tree unpatched (expect red), clean tree patched (expect green), and optionally the contributor's own aged install patched (expect green). The first cell is literally the negative-control field in the new bug template, the second is the repro-on-a-clean-tree field — the harness generates the exact evidence the template now requires instead of contributors hand-assembling it. And if a probe only goes red on the aged install, that's local drift, not an upstream bug, before it ever becomes a bad issue.

Happy to prototype the wrapper and come back with real numbers if that's useful.

[danielmiessler]

The recent wave IS the preferred format—version + file:line + a repro that runs against a clean tree + a suggested fix, exactly what the last three days of reports did. We'll encode it as a GitHub issue template so it's structural rather than tribal. A skill for it is an interesting idea—several reporters clearly had their own DA write the report against their install, and those were among the best submissions.

[xmasyx]

@garthsch great idea, thanks for opening it. I'm putting the proposal here first; if it looks right, @danielmiessler, I'll wait for your confirmation before sending it as a PR.

Five fields, with the negative control required: version · what is broken · file:line · repro on a clean tree · negative control · suggested fix (optional). Plus three pre-submit boxes; the third is a redaction prompt, since DA-written reports tend to arrive carrying the reporter's home path and real name in the pasted output.

A config.yml next to it keeps blank issues enabled and points questions, ideas and "should I upgrade?" at Discussions, the class @garthsch called user-opinion.

.github/ISSUE_TEMPLATE/bug_report.yml

name: Bug report
description: A defect with a version, a location, a repro on a clean tree, and proof the check would have gone red.
labels: ["bug"]
body:
  - type: markdown
    attributes:
      value: |
        Five fields make a report cheap to accept. The first four say what is broken and where. The fifth, the negative control, is what turns a patch review into a bug reproduction: it states the defect without reference to any fix, so a maintainer can see the failure before reading a line of proposed code.

        Redact before you paste. DA output carries your home path, your name, and sometimes your own data. `/Users/you/.claude/...` reads fine.
  - type: input
    id: version
    attributes:
      label: Version
      description: LifeOS version, plus the component version when the defect lives in one.
      placeholder: LifeOS 7.40.4 / Cortex
    validations:
      required: true
  - type: textarea
    id: summary
    attributes:
      label: What is broken
      description: One paragraph on the behaviour, not the remedy.
    validations:
      required: true
  - type: input
    id: location
    attributes:
      label: Where (file:line)
      description: The line the defect lives on. Add the reader and the writer when the two disagree.
      placeholder: LIFEOS/TOOLS/CortexHealth.ts:206
    validations:
      required: true
  - type: textarea
    id: repro
    attributes:
      label: Repro on a clean tree
      description: Commands someone can run against a fresh install of the version above, and what they will see. No local patches, no personal config.
      render: shell
    validations:
      required: true
  - type: textarea
    id: negative-control
    attributes:
      label: Negative control
      description: >
        How you proved the check would have gone red. Run the probe against the unpatched version and paste the failing output, phrased without reference to any fix, e.g. "on unpatched 7.40.4 the retriever returns 5 ranked results and writes 0 evidence rows". A probe that has never been red is an assertion wearing the clothes of a verification.
    validations:
      required: true
  - type: textarea
    id: fix
    attributes:
      label: Suggested fix
      description: Optional. A diff, or the shape of one. Say plainly if it is untested.
    validations:
      required: false
  - type: checkboxes
    id: checks
    attributes:
      label: Before submitting
      options:
        - label: I searched open and closed issues for this defect.
          required: true
        - label: The repro runs against a clean tree of the version above, not against my modified install.
          required: true
        - label: "I removed personal data from the pasted output — real names, absolute home paths, tokens, my own content."
          required: true

.github/ISSUE_TEMPLATE/config.yml

blank_issues_enabled: true
contact_links:
  - name: Question, idea, or release feedback
    url: https://github.com/danielmiessler/LifeOS/discussions
    about: Discussions is the place for questions, feature ideas, and "should I upgrade?". Defects belong in issues.

Both files parse. Left out on purpose: a feature-request form, and any label or triage policy.

[Drizzt321]

@danielmiessler I suppose a bit also, do you prefer PRs where an issue was also created, or just a PR? I didn't even think I just put in 2 PRs without creating an issue for them.

[orangemaster-pai]

I tend to agree with there being some sort of standardization for this. Like, I'm watching a video on how omarchy works, and it has a built-in way to report issues. And this makes a lot of sense to me because you do not have to worry about what format you're going to get. You can set the standard of the type of PR issue or whatever you want to have in a way that works best with your agent, and that makes it so that the fire hose of people wanting to provide tokens to help out with this project have it a lot easier. More than a few times I've had something in here where I thought, you know what? I would love to help out with this, but I don't know the etiquette. I don't know the right way to do this. Putting in a standard as part of the Life OS skill so that people's agents automatically know how to both research the problem and report the problem, I think makes the whole pipeline go a little smoother and a little faster. You'll get less weird PRs full of more information that's actually useful to you for fixing it. The end result is that the project can move a little faster, and folks could easily pour little tokens into this. You could probably extend this line of thinking even a little bit further and say, hey, I've got this feature idea. Does anybody want to throw some tokens at it? And then we can feed back what an agent came up with based on requirement scaffolding, and then that way Daniel isn't the only one spending tokens on the whole project.

[Drizzt321]

Actually that's interesting for the future, having a Skill for "submit issue" and "submit PR". Could be useful I suppose.

[danielmiessler]

Yeah, I think this is a great idea, actually. Let me build something.

[danielmiessler]

Okay, this is really good stuff here. I'm adding a report workflow to the LifeOS skill itself, so now you'll be able to use that to send in issues and PRs and even discussion topics.