SMTM v5.7 — The Continuation Gate

Task: kb-os-smtm-continuation-path-reliability (2 rounds, rock: 3, Opus) Continuation: sdc-sdapp-full-levpro-port — the LevPro port’s final 100%-issues report, which Talbot had explicitly gated on this mechanism existing.

The problem

A task closes, the thread it belonged to keeps going, and nothing tracks the next piece. It fails silently — no error, no orphan file, nothing on a dashboard. It surfaces days later when a human notices work stopped.

Two confirmed incidents, same shape:

1. sdc-levpro-sdmath-complete closed 2026-08-28 with no task tracking the UI port that had to follow. Talbot found the gap himself the next day and wrote the successor from scratch.
2. sdc-sdapp-full-levpro-port reached “dev scope functionally complete” (round 6, 2026-08-30) with no artifact answering what happens after this closes. Round 7 patched that one file; Talbot’s round-8 verdict was that an instance-level patch is not the fix, because nothing about it would apply to the next task.

Diagnosis — read, not inferred

• task-complete.md treated the hand-off as conditional prose: “end with the next command if the closed task hands off to another skill… otherwise Next: none.” An agent could satisfy that with Next: none and never be wrong.
• task-continue.md had no successor check at all.
• project-task-complete.md Step 8 (project closure) had the identical hole.
• Source vs. deployed: no drift on any of the three before editing.

The decision — and why the Project construct was not the answer

Talbot’s question was whether to use SMTM’s Layer-2 Project workflow or find a more reliable approach. The construct was never the variable. Finding #3 above settles it: promoting the LevPro port into a Project would not have prevented either incident, because project closure had the same missing check. A Project buys a shared STATUS.md — real value for multi-thread state — and zero continuation guarantee.

Use a Project when one STATUS.md genuinely earns its keep as SSOT for state across several simultaneously-live threads. Never promote to a Project to fix continuation. The LevPro Project retrofit was deliberately deferred (Talbot: “will monitor and address if doesn’t continue”).

Tripwire worth remembering: if the LevPro thread stalls again with the gate in place, that is evidence the gate is insufficient — not that a Project was needed. The two fail for different reasons, and the distinction tells you which fix to reach for.

What shipped

/task-complete Step 4c — blocking AskUserQuestion, fires on every close (_tmp.md excepted). No grandfathering: continuation: is the record of the answer, not a precondition for asking, so every task closing from here on hits it. No retroactive sweep; the Templater template is untouched (at creation time the successor isn’t known yet).

Resolution	What happens	Frontmatter
Successor exists	Verified on disk via the Tasks glob before the pointer is written	continuation: <filename>
Successor needed	Stub created during the close — dept-routed, open items carried over verbatim, added to _active.md	continuation: <new-filename>
Terminal	Reason required; survives the purge into this log	continuation: none — <reason>

Three design calls that make it structural rather than declarative:

• A named successor must resolve to a file that exists. Incident #1’s continuation existed conceptually; no file did. A gate accepting an unverified name reproduces the failure with extra steps.
• It asks Talbot; it never self-resolves. Both incidents happened with an agent that would have answered “nothing follows.”
• The continuation record is purge-proof. Under disposition B the task file is deleted, so without this the “auditable later” claim would be false outside git log -p.

Step 10’s closing next-command line is no longer a judgment call — it is dictated by the continuation: value.

/project-task-complete Step 8 — same gate at project closure. Phase boundaries exempt: the next phase is already named in ROADMAP.md/STATUS.md.

/task-continue creep gate (4b) — extended, not duplicated. Options 2 (ship reduced scope) and 3 (stop and close) now require the deferred remainder as a concrete Next Steps checkbox the close-time gate can carry forward. Deliberately no “round declares dev-scope done” trigger — not mechanically detectable, and a gate keyed on the agent noticing it is the advisory version Talbot rejected.

One stop, not two — 4c’s question rides in the same message as the LESSONS/memory gate whenever that has candidates to post.

Gotcha found in passing — version-stamp drift

SMTM_System.md’s header and footer both read 5.4 while its own changelog already ran to v5.6 (2026-07-25) — ~5 weeks of stale drift. Bumping “5.4 → 5.5” as approved would have moved the stamp backwards past two shipped versions. Bumped to 5.7 instead, drift recorded in the changelog entry. Swept the three project-* skills’ “Layer 2 (v5.4)” pointers; left historical mentions alone.

Retroactive risk check

Four tasks would drop a thread if closed today — sdc-sdapp-pdf-reports, web-testing-system, kb-os-vp-directors-single-identity, ai-config-design-ssot. No action taken: the gate catches each at its own close.

Verification — stated honestly

Skill files are prompts; there is no unit test, and none was claimed. Evidence is static review against both incident traces plus one live end-to-end run: this task’s own close fired the gate, which resolved to sdc-sdapp-full-levpro-port and verified the file on disk before writing the pointer.

Commits

ai-config d77bba1 · 7b043ea · da5cc08 (all deployed, skills verified byte-identical in ~/.claude/commands/) KB dad4e6a · 9435a78 · ed55d09

Notes

• SMTM — Simple Markdown Task Management, the vault’s task convention (Core/Processes/Simple Markdown Task Management/SMTM_System.md).
• Layer 2 / Project — SMTM’s construct for multi-phase work (ROADMAP/STATUS/NEXT-STEPS/LESSONS/UPGRADES), distinct from a flat single-file Task (Layer 1).
• Creep gate — the forced-choice mechanism in task-continue.md Step 4b, firing from the 4th ## Claude Response onward; the precedent this gate reuses.