What happens
7.40.4 ships the Bunker concept doc and the Pulse /bunker tab, with the reference implementation private by design (release notes, CoreComponents.md). On such an install:
PULSE/Observability/src/app/bunker/page.tsx (~L98) renders a pulsing green pill reading SYSTEMS ONLINE unconditionally. Nothing is online; there is no harness to be online. On a release whose theme is "the system now proves what it claims", this is the one page that claims without proof.
PULSE/modules/bunker.ts still runs its initial scan and its poll: each one spawns bun <path that does not exist> and logs a module-not-found. The tab shows "first scan pending" forever, which is indistinguishable from a slow first scan.
Proposed fix (diff attached, against v7.40.4, module side)
refresh() returns { ok:false, reason:"bunker harness not deployed on this install" } when bunkerAvailable() is false, before anything is spawned.
start() logs the absence once and returns without scheduling a scan or a poll.
GET /api/bunker with no cache answers available:false and a stale_reason that says "not deployed" rather than "first scan pending", so the page can tell the two apart.
Page side (not in the attached diff, small): render the pill from available: green "SYSTEMS ONLINE" only when a snapshot exists, a dim "NOT DEPLOYED" otherwise. I have the module change running on three nodes; the page change is straightforward and I did not want to guess at your styling tokens.
Reported from the 0bsolescence/LifeOS fork (patches 466aefb, aa00470, replayed on patches/v7.40.4). Drafted with AI assistance; observed and verified by hand.
Proposed diff (against v7.40.4)
diff --git a/LifeOS/install/LIFEOS/PULSE/modules/bunker.ts b/LifeOS/install/LIFEOS/PULSE/modules/bunker.ts
index 74654f2..3d4d669 100644
--- a/LifeOS/install/LIFEOS/PULSE/modules/bunker.ts
+++ b/LifeOS/install/LIFEOS/PULSE/modules/bunker.ts
@@ -45,6 +45,9 @@ let refreshInFlight = false;
const REFRESH_TIMEOUT_MS = 4 * 60_000;
async function refresh(): Promise<{ ok: boolean; reason?: string }> {
+ // No harness, no scan. Spawning `bun <missing file>` only produces a module-not-found
+ // on every poll and on every /refresh; absence is reported by health(), not by noise.
+ if (!bunkerAvailable()) return { ok: false, reason: "bunker harness not deployed on this install" };
if (refreshInFlight) return { ok: false, reason: "refresh already in flight" };
refreshInFlight = true;
try {
@@ -73,6 +76,12 @@ export async function start(): Promise<void> {
console.log(`[${MODULE}] Starting...`);
state.running = true;
state.startedAt = new Date();
+ // An absent harness is the normal state on an install that never deployed Bunker
+ // (see bunkerAvailable). Say it once, then stay inert: no initial scan, no poll.
+ if (!bunkerAvailable()) {
+ console.log(`[${MODULE}] Bunker harness not deployed on this install — /bunker tab inert`);
+ return;
+ }
// Fire-and-forget: a full scan can take minutes and module start gates the
// HTTP server coming up. The tab renders "first scan pending" until it lands.
refresh().then((r) => {
@@ -430,12 +439,18 @@ export async function handleRequest(req: Request, pathname: string): Promise<Res
if (req.method === "GET" && (sub === "/" || sub === "")) {
if (!state.cache) {
+ // "Never deployed" and "first scan still running" both produce an empty
+ // snapshot; only the former will never resolve, so name it on the wire.
+ const missing = !bunkerAvailable();
return Response.json({
apps: [],
summary: { apps: 0, green: 0, probesPass: 0, probesTotal: 0, manual: 0 },
lastFetch: null,
stale: true,
- stale_reason: "no snapshot yet — first scan pending",
+ available: !missing,
+ stale_reason: missing
+ ? "Bunker harness not deployed on this install"
+ : "no snapshot yet — first scan pending",
});
}
// Fold the cloud security grade into each app so every bay carries
What happens
7.40.4 ships the Bunker concept doc and the Pulse
/bunkertab, with the reference implementation private by design (release notes, CoreComponents.md). On such an install:PULSE/Observability/src/app/bunker/page.tsx(~L98) renders a pulsing green pill reading SYSTEMS ONLINE unconditionally. Nothing is online; there is no harness to be online. On a release whose theme is "the system now proves what it claims", this is the one page that claims without proof.PULSE/modules/bunker.tsstill runs its initial scan and its poll: each one spawnsbun <path that does not exist>and logs a module-not-found. The tab shows "first scan pending" forever, which is indistinguishable from a slow first scan.Proposed fix (diff attached, against v7.40.4, module side)
refresh()returns{ ok:false, reason:"bunker harness not deployed on this install" }whenbunkerAvailable()is false, before anything is spawned.start()logs the absence once and returns without scheduling a scan or a poll.GET /api/bunkerwith no cache answersavailable:falseand astale_reasonthat says "not deployed" rather than "first scan pending", so the page can tell the two apart.Page side (not in the attached diff, small): render the pill from
available: green "SYSTEMS ONLINE" only when a snapshot exists, a dim "NOT DEPLOYED" otherwise. I have the module change running on three nodes; the page change is straightforward and I did not want to guess at your styling tokens.Reported from the
0bsolescence/LifeOSfork (patches466aefb,aa00470, replayed onpatches/v7.40.4). Drafted with AI assistance; observed and verified by hand.Proposed diff (against v7.40.4)