peaks-loop 4.0.51 → 4.0.52

package/skills/bee/peaks-txt/SKILL.md

@@ -69,7 +69,7 @@ Read persistent project memory via CLI (durable, LLM-authored memories):
 peaks project memories --project <repo> --json
 ```
 
-This returns durable memories from `.peaks/memory` — decisions, conventions, modules, and rules captured in past sessions. Filter with `--kind <decision|convention|module|rule|reference|project>`. (`.peaks/PROJECT.md` is a human-readable session timeline only.)
+This returns durable memories from `.peaks/memory` — decisions, conventions, modules, and rules captured in past sessions. Filter with `--kind <project|decision|convention|rule|reference|feedback|module|lesson|bug|investigation|technical-pattern|project-rule|design|handoff|session-handoff|project-todo|publish-closure|project-closure|slice-closure|slice-pilot-findings|sediment>`. (`.peaks/PROJECT.md` is a human-readable session timeline only.)
 Then display: `Peaks-Loop Skill: peaks-txt | Peaks-Loop Gate: startup | Next: <one short action>`. Update with `peaks skill presence:set peaks-txt --project <repo> --mode <mode> --gate <gate>` when gates change. When the role's work ends, run `peaks skill presence:clear --project <repo>`.
 
 ## Responsibilities
@@ -158,7 +158,7 @@ When a skill artifact contains reusable project facts, decisions, rules, constra
 ```markdown
 <!-- peaks-memory:start -->
 title: Short project memory title
-kind: project | decision | convention | rule | reference | module | lesson
+kind: project | decision | convention | rule | reference | feedback | module | lesson | bug | investigation | technical-pattern | project-rule | design | handoff | session-handoff | project-todo | publish-closure | project-closure | slice-closure | slice-pilot-findings | sediment
 ---
 Stable memory body.
 <!-- peaks-memory:end -->
@@ -263,7 +263,7 @@ peaks capabilities --json
 #
 #    <!-- peaks-memory:start -->
 #    title: Short project memory title
-#    kind: project | decision | convention | rule | reference | module | lesson
+#    kind: project | decision | convention | rule | reference | feedback | module | lesson | bug | investigation | technical-pattern | project-rule | design | handoff | session-handoff | project-todo | publish-closure | project-closure | slice-closure | slice-pilot-findings | sediment
 #    ---
 #    Stable memory body. Concrete facts only — no secrets, no transient state.
 #    <!-- peaks-memory:end -->

package/skills/peaks-code/SKILL.md

@@ -231,7 +231,7 @@ See also: references/session-overload-signal-index.md for the 7-signal lookup ta
 | **D-001** | 0.8 | `peaks code detect-job --is-job ...` rejected with `error: unknown option '--is-job'` | Use `peaks job init --job-id <jid> --slice-list <list> --main-loop-strategy <single\|rotating>` | §Step 0.8 first paragraph |
 | **D-002** | 2.5 | `peaks session title --session-id <sid> ...` rejected with `error: unknown option '--session-id'` (this is the bare `<sid>` anti-pattern) | sid is positional: `peaks session title <sessionId> "<title>" --json` | §Step 2.5a |
 | **D-003** | 0.8 | `JOB_SHAPE_NOT_DECIDED` exception expected but never thrown | Current behavior is `peaks job status` reports `done: 0` passively — treat as recoverable miss, not hard error | §Step 0.8 third paragraph |
-| **D-010** | 11c | `peaks memory extract` returns `extractedCount: 0` despite `<!-- peaks-memory:start -->` existing | Block requires YAML frontmatter (`title:` + `kind:` + `---`) + closing `<!-- peaks-memory:end -->`. Bare `peaks-memory:start` is parsed silently but produces no writes | §Step 11c + 11d |
+| **D-010** | 11c | `peaks memory extract` returns `extractedCount: 0` despite `<!-- peaks-memory:start -->` existing | Block requires YAML frontmatter (`title:` + `kind:` + `---`) + closing `<!-- peaks-memory:end -->`. A marker without those fields, and a marker that is not the exact literal (e.g. with a `kind=…` written inside it), produce no writes and are both named in the envelope's `warnings[]` — read it before concluding there was no block | §Step 11c + 11d |
 
 > **Sediment lesson (master record):** `.peaks/memory/peaks-code-runbook-4-0-0-beta-6-skill-md-cli-d-001-d-002-d-003-d-010.md`
 

package/skills/peaks-code/references/project-memory-loading.md

@@ -12,6 +12,24 @@ This returns durable memories from `.peaks/memory`, grouped by kind:
 - **convention** — discovered project patterns (code style, naming, tooling)
 - **rule** / **reference** / **project** — standing constraints, external pointers, and project context
 
-Filter with `--kind <decision|convention|module|rule|reference|project|lesson>` when you only need one slice. Use this to understand what exists, what was decided, and what to avoid re-litigating. Memories are LLM-authored at approved checkpoints via `peaks memory extract`. The `lesson` kind is for LLM-discovered runtime lessons (e.g. "this project's antv6 Drawer uses `size` not `width`"); write them as `<!-- peaks-memory:start kind=lesson -->` blocks in the RD handoff or TXT handoff.
+Filter with `--kind <project|decision|convention|rule|reference|feedback|module|lesson|bug|investigation|technical-pattern|project-rule|design|handoff|session-handoff|project-todo|publish-closure|project-closure|slice-closure|slice-pilot-findings|sediment>` when you only need one slice. Use this to understand what exists, what was decided, and what to avoid re-litigating. Memories are LLM-authored at approved checkpoints via `peaks memory extract`. The `lesson` kind is for LLM-discovered runtime lessons (e.g. "this project's antv6 Drawer uses `size` not `width`"); write them as memory blocks in the RD handoff or TXT handoff.
+
+A memory block is a **bare** start marker, then a header carrying a line-anchored `title:` and `kind:`, then a `---` separator line, then the body, then the end marker:
+
+```markdown
+<!-- peaks-memory:start -->
+title: Short project memory title
+kind: lesson
+---
+Stable memory body.
+<!-- peaks-memory:end -->
+```
+
+Two ways a block can be lost — one silent, one reported:
+
+- The start marker carries **no attributes**. It is matched literally, so any text added inside it (e.g. a `kind=…` attribute between `start` and `-->`) makes it not a marker at all: the block is never found, and nothing is extracted from it. `warnings` does name it back at you ("… is not the exact marker …"), which is how you tell this apart from an artifact that simply had no blocks — but the memory itself is still lost, so fix the marker rather than reading past the warning. Put `kind:` on its own line in the header instead.
+- `title:` and `kind:` must each be on their own line, and the `---` separator must be present. A marker whose body has only prose is found but rejected, and says which precondition failed.
+
+Preview with `peaks memory extract --project <repo> --artifact <handoff> --dry-run`, then re-run with `--apply` to write.
 
 `.peaks/PROJECT.md` is a human-readable session timeline only — do NOT use it for LLM context.

package/skills/peaks-code/references/step-11-memory-sediment.md

@@ -41,7 +41,7 @@ peaks memory extract --project <repo> --artifact .peaks/_runtime/<sessionId>/txt
 
 `--apply` is REQUIRED (without it the command only previews — no files land).
 
-> **CLI reality check (D-010 sediment, 2026-07-09):** The `<!-- peaks-memory:start -->` block must be followed immediately by a **YAML frontmatter** (`title: ...`, `kind: lesson | decision | convention`) and a `---` separator. Each block must close with `<!-- peaks-memory:end -->`. A bare `peaks-memory:start` without the YAML fields is parsed but produces no `plannedWrites` — the CLI silently returns `extractedCount: 0`.
+> **CLI reality check (D-010 sediment, 2026-07-09; warnings added 2026-09-17):** The `<!-- peaks-memory:start -->` block must be followed immediately by a **YAML frontmatter** (`title: ...`, `kind: lesson | decision | convention`) and a `---` separator. Each block must close with `<!-- peaks-memory:end -->`. A marker whose body lacks those fields produces no `plannedWrites`, so `extractedCount` stays 0 — and the CLI now says why: the rejected block is named, with the failed precondition, in the envelope's `warnings[]`. The same channel catches a marker that is not the exact literal (e.g. a `kind=…` written inside it), which `warnings` reports as "… is not the exact marker …". Read `warnings` before treating `extractedCount: 0` as "there was no block" — but note the warning reports the loss, it does not recover it: fix the marker and re-run.
 
 ### 11d — Gate C (zero-write outcome)