Work System: on a public install nothing moves or closes an issue after it is created, and nothing tells the DA when to

### Version

LifeOS 7.40.4, and `main` @ 5e2f2e8 (2026-09-03). `LIFEOS/TOOLS/WorkSweep.ts` is identical in both.

### What is broken

The Work System creates issues but has no path that advances or closes one. `WorkSystem.md:14` names the repo "the system of record". The component that sets `Status:*` from the ISA phase, `hooks/ULWorkSync.hook.ts` (`WorkSystem.md:81`), is private and not in the payload (`WorkSystem.md:69`, settled in #1423). What a public install is left with:

- **No code path.** Every shipped `Status:*` literal is written once, at creation (`Status:queued` in WorkSweep and ReminderRouter, `Status:ready` in CommitmentLog). The only shipped `gh issue edit` calls add `stale` (WorkSweep) or reclassify types (RetagSweepTypes). The only shipped code that closes an issue, `PULSE/checks/github-work.ts:240`, is registered only by `PULSE/setup.ts:220-223`, and it polls lowercase `status:ready` (`:124`), a label the Work System no longer emits.
- **A duty with no trigger.** `LIFEOS_SYSTEM_PROMPT.md:143` makes "keeping the principal's designated work repo's issues current — open, label, comment, close" standing work. `WorkSystem.md:161-170` gives the manual claim flow (`gh issue edit … Status:in-progress`, then `gh issue close`). Nothing tells the DA *when* to do it. The Algorithm spec has no reference to issues, no hook surfaces open issues whose ISA has finished, and the claim flow says it is "documented in the repo README", which does not ship (`WorkSystem.md:180`).

The result: an issue stays in the Status it was born with until the principal closes it by hand. Two knock-on defects:

- `sweepStaleIssues` (`WorkSweep.ts:322`) only acts on `Status:in-progress`. No shipped code writes that label, so the stale sweep cannot fire from anything the system does.
- Issues that are never session-bound (`[Goal]`, `[Reminder]`, the BPE reminder, commitments) have no closer of any kind.

This is broader than #2063, point 2. That one closes a session that is *already* complete when the sweep first sees it. It does not cover a session that finishes after its issue exists, and it does not cover non-session issues.

### Where (file:line)

`LIFEOS/TOOLS/WorkSweep.ts:322` (reader with no writer) · `LIFEOS/LIFEOS_SYSTEM_PROMPT.md:143` (duty with no trigger) · `LIFEOS/DOCUMENTATION/Work/WorkSystem.md:161-170` (manual flow, no invoker) · `LIFEOS/PULSE/checks/github-work.ts:124,240` (the only closer, unregistered)

### Repro on a clean tree

```shell
git clone --depth 1 https://github.com/danielmiessler/LifeOS && cd LifeOS/LifeOS/install

# 1. Who writes Status:in-progress?
rg -n "Status:in-progress" --glob "!*.md" .

# 2. What edits or closes an issue after creation?
rg -n '"issue", "(close|edit)"|state: "closed"|--remove-label' --glob "!*.md" .

# 3. Which Status labels are ever written?
rg -n '"Status:[a-z-]+"' --glob "!*.md" --glob "!**/Observability/**" .

# 4. Does the Algorithm mention issues at all?
rg -n -i "issue" LIFEOS/ALGORITHM/ | wc -l

# 5. Is the only closer registered anywhere the Pulse actually loads?
rg -n "github-work" --glob "*.toml" --glob "*.ts" . | grep -v console.error
```

### Negative control

Output on unpatched `main` @ 5e2f2e8:

```text
# 1 — one reader, one setup hint, no writer
./LIFEOS/TOOLS/WorkSweep.ts:322: const inProgress = issue.labels.some((l) => /^Status:in-progress$/i.test(l) || /^in-progress$/i.test(l));
./LIFEOS/PULSE/modules/work.ts:337: `Ensure the repo has these labels: Type:feature, ... Status:in-progress, ...`

# 2 — stale label, type retag, and the unregistered worker
./LIFEOS/PULSE/checks/github-work.ts:240: body: JSON.stringify({ state: "closed" }),
./LIFEOS/TOOLS/WorkSweep.ts:188: ["gh", "issue", "edit", String(issueNumber), "--repo", repo, "--add-label", label],
./LIFEOS/TOOLS/RetagSweepTypes.ts:66: const args = ["gh", "issue", "edit", String(p.n), "--repo", repo];
./LIFEOS/TOOLS/RetagSweepTypes.ts:68: if (p.remove) args.push("--remove-label", p.remove);

# 3 — creation-time only
./hooks/ReminderRouter.hook.ts:183: "Status:queued",
./LIFEOS/TOOLS/WorkSweep.ts:269: "Status:queued",
./LIFEOS/TOOLS/WorkSweep.ts:392: "Status:queued",
./LIFEOS/TOOLS/WorkSweep.ts:457: "Status:queued",
./LIFEOS/TOOLS/WorkSweep.ts:528: "Status:queued",
./LIFEOS/TOOLS/CommitmentLog.ts:103: "Status:ready",

# 4
0

# 5 — setup wizard only, not PULSE.toml
./LIFEOS/PULSE/setup.ts:220:name = "github-work"
./LIFEOS/PULSE/setup.ts:223:command = "bun run checks/github-work.ts"
```

### Suggested fix

The shape only; untested.

1. **A lifecycle pass in WorkSweep.** For each ISA with `github_issue` (the write-back from #1936), map phase to `Status:*` and close the issue with a comment naming the ISA when the phase is complete. That gives the stale sweep its writer.
2. **A nudge for everything else.** A SessionStart or Pulse surface listing open issues whose linked ISA is complete, or that have not changed in N days. It would give the standing duty in `LIFEOS_SYSTEM_PROMPT.md:143` a trigger.
3. **Remove or realign `github-work.ts`.** Either delete it, or switch it to `Status:*` and register it in `PULSE.toml`.

### Before submitting

- [x] I searched open and closed issues for this defect (#2063, #1423, #1936, #1955 read).
- [x] The repro runs against a clean tree of the version above.
- [x] I removed personal data from the pasted output.

Start by running the five ripgrep checks in the issue on a clean tree, then read LIFEOS/TOOLS/WorkSweep.ts, LIFEOS/PULSE/checks/github-work.ts, PULSE/setup.ts, and PULSE.toml. Trace how ISA-linked and non-session issues are created and whether any shipped worker updates them. Done means the public install has a defined lifecycle trigger, aligned status handling, and a registered or removed closer, with coverage for the affected paths.

Written by the indexing model from the issue text.