@prismer/runtime 2.0.8 → 2.2.55

package/built-in-skills/memory-dream/SKILL.md

@@ -0,0 +1,339 @@
+---
+name: memory-dream
+scope: common
+role_scope: orchestrator-only
+description: |
+  Actively curate the workspace memory wiki as the appointed orchestrator: READ the
+  Dream candidates (`memory_curate(op="candidates")` → orphan leaves, near-duplicate
+  clusters, stale pages, remote-conflict pages, oversized hubs), BROWSE the current
+  structure (`memory_browse`), CLUSTER scattered leaves by topic with your OWN LLM,
+  CONVERGE the flat star into an INDEX→hub→leaf hierarchy with
+  `memory_curate(op="promote_to_hub", childPaths=[…])` + `rebuild_index`, MAINTAIN
+  hub `#overview` prose and the INDEX's authored semantic sections (hub `#toc` stays
+  machine-generated; INDEX Contents is graph-derived), SPLIT oversized hubs, then
+  VERIFY via candidates again and
+  REPORT the changes. The periodic tidy that merges duplicates and prunes stale —
+  the enacting counterpart to write-time placement. Cloud-triggered and
+  orchestrator-enacted: the Cloud scheduler evaluates authoritative wiki health and
+  dispatches one internal task; the appointed workspace orchestrator runs this skill.
+  A user may also request curation directly. Orchestrator-only — write verbs reject
+  any non-orchestrator actor (403).
+applies_to: [hermes, claude-code, codex]
+version: 4
+---
+
+# Memory Dream — orchestrator-driven consolidation
+
+> **Memory pages are PKF (`.pkf`).** When you fold or merge page bodies, the body syntax
+> (sections, typed links, frontmatter) comes from the **`pkf-writing`** skill — load it
+> when you author body content, and validate the result before persisting. This skill
+> only governs the graph: what to merge, where to attach, and how to keep INDEX/hub
+> ownership straight.
+
+> **Candidate boundary.** Dream sees authoritative **Memory Pages**, not “all PKF.” A
+> message-inline PKF or Library `.pkf` Asset remains outside this loop. Runtime
+> automatically classifies durable claims from validated inline PKF; Asset handling
+> still uses the `memory` skill. Explicitly materialize authoritative inline bytes only
+> when the user requests exact preservation. Only a resulting Memory Page participates
+> in candidates, revisions, merges and hub TOCs.
+
+You are (when appointed) the **workspace memory orchestrator**. Your job is the "Dream
+phase": periodically reorganize the memory wiki so it stays coherent as it grows — merge
+duplicate hubs, attach satellite pages under the right hub, supersede stale/contradicted
+pages, keep the top-level INDEX lean, maintain every hub's `#overview` plus the INDEX's
+authored semantic sections, and split hubs that have grown oversized.
+
+There is one automatic trigger authority: the **Cloud SchedulerService** sweeps every
+six hours, applies the 24-hour cadence gate plus authoritative wiki-health signals
+(orphan ratio, oversized INDEX, frontier duplicate cluster, or page-growth burst),
+deduplicates in-flight work, and dispatches one hidden `memory-dream` task to the bound
+workspace orchestrator. The Cloud performs no Memory LLM reasoning. The appointed
+orchestrator executes this skill in its own Runtime and is the sole automatic write
+actor. A user can also ask that orchestrator to curate immediately; ordinary per-page
+queries do not trigger Dream. The retired daemon `FF_MEMORY_DREAM_ENABLED` scheduler is
+not an active trigger path.
+
+> **Authority gate.** The curation write verbs only work for the **appointed workspace
+> orchestrator** (the workspace owner, or the agent set as `orchestratorAgentId`).
+> If you are not the orchestrator, every write verb returns `403 orchestrator_only` —
+> that is expected, not a bug. Do not retry; write-time placement discipline (the
+> **memory** skill's browse-first flow) is what every agent does, and it is enough.
+
+**Owner vs orchestrator vs deputy (product209/16 MA-2):**
+
+- The **owner** (human) and the **appointed orchestrator**
+  (`orchestratorAgentId`) are the only Dream write actors. The owner speaking
+  through an agent does NOT grant it Dream rights — the agent itself must hold
+  the orchestrator binding. Dream never back-derives authority from "the owner
+  is talking to me".
+- A **deputy** does NOT inherit Dream from its bound member — not even when
+  the bound member is the owner. A deputy runs Dream write verbs only if the
+  deputy agent itself is the appointed `orchestratorAgentId`.
+- `candidates` is the READ half and works for any agent in scope; the write
+  verbs (`promote_to_hub` / `supersede` / `rebuild_index` and the section-level
+  `section_merge` / `section_supersede` / `rewire`) are the gated half.
+- `403 orchestrator_only` and `202 approval deferred` are final per-request
+  verdicts — do not retry, and do not route around them through another agent.
+
+## The verbs
+
+```
+memory_curate(op="candidates")                        # READ what needs work (any agent)
+memory_curate(op="candidates", kind="orphans")        # one surface; limit caps per kind
+memory_browse(query="<topic>")                        # READ the structure: {index, hubs[+snippet], nearest}
+memory_curate(op="promote_to_hub", pageId="<id>",
+              childPaths=["<path>", …])               # leaf → hub AND attach children (orchestrator only)
+memory_curate(op="supersede", pageId="<id>",
+              reason="merged into <path>")            # archive + mark stale (orchestrator only)
+memory_curate(op="rebuild_index")                     # regenerate hub TOCs; INDEX Contents stays graph-derived (orchestrator only)
+memory_curate(op="section_merge", pageId="<winnerPageId>",
+              targetSection="<winnerSlug>", sourcePageId="<loserPageId>",
+              sourceSection="<loserSlug>",
+              mergedContent="<merged body>")          # fold ONE near-duplicate section (memory211 W5)
+memory_curate(op="section_supersede", pageId="<pageId>",
+              section="<slug>")                       # retire ONE section in place (memory211 W5)
+memory_curate(op="rewire", linkId="<linkId>",
+              toPageId="<id>")                        # re-point a broken/wrong link (memory211 W5)
+```
+
+- `candidates` is the READ half: `{candidates:{orphans,duplicates,stale,conflicts,oversized}}`
+  — unplaced leaves (no outgoing `child-of`/`parent` edge to a live hub; an INDEX
+  `index-anchor` only guarantees reachability and therefore still counts as flat), near-duplicate clusters
+  (`duplicate_cluster:<peerIds>`), stale pages, remote-conflict pages, and oversized
+  hub/INDEX advisories (`kind="oversized"` — size is recorded, never machine-enforced;
+  splitting is YOUR call). It does NOT cluster or decide; that is YOUR LLM's job.
+- **`promote_to_hub` takes `childPaths[]`** — pass the member pages' paths (exactly as
+  candidates/browse returned them) and the cloud attaches them under the new hub as
+  `child-of` children **in the same call**. Do not promote a hollow hub and re-anchor
+  members one by one afterwards.
+- `rebuild_index` is the ONLY **hub** `#toc` writer. It emits a complete strict PKF
+  `<section>` with stable `data-sid`, one navigation entry per graph child and the
+  child's frontmatter `description`. Structural `child-of` remains child→hub in the
+  graph; downward TOC links are navigation, never inverted placement edges. Hub
+  `<h2 id="overview">` prose is agent territory and survives rebuild.
+- Top INDEX is different: its Contents is derived live from the graph and there is no
+  stored machine `#toc` to rebuild or edit. Its authored semantic sections are the
+  orchestrator's editorial territory.
+- **Section verbs (memory211 W5)** — the granularity drift happens at SECTION level, so
+  curation does too. `section_merge` rewrites the winner's section with `mergedContent`,
+  splices the loser section out of its page, and the CLOUD writes the
+  `supersedes` + `derived-from` provenance edges for you — a merge with no edge trail is
+  an unfinished merge. `section_supersede` retires one section (optionally pointing at the
+  surviving one). `rewire` fixes a single broken/wrong link without a page rewrite.
+- There is no `run_dream` cloud-LLM op — `candidates` (read) + the write ops are
+  the whole surface (memory203/13 §0.5: all memory LLM runs in your runtime, never the
+  cloud's).
+
+Enactment is the native `memory_curate` TOOL (the same tool surface every agent already
+holds, alongside `memory_search` / `memory_load` / `memory_browse` / `memory_write`). Do
+NOT look for a separate "memory-dream tool" or shell — `memory_curate` IS the enactment
+surface. (A `prismer memory curate …` CLI exists for shell contexts; the TOOL is primary.)
+If a curate response is `degraded:true`, no authoritative Cloud mutation occurred;
+report the degraded state and never describe the requested convergence as completed.
+
+## The convergence loop (keep it tight)
+
+Run the loop end-to-end in a handful of calls — `memory_browse` gives you the whole
+structure in ONE call, so you never need long exploratory search/load spelunking:
+
+**STEP 1 — READ the candidates.**
+
+```
+memory_curate(op="candidates")
+# → { ok:true, candidates: {
+#      orphans:    { items:[ {pageId, path, reason:"orphan"}, … ], total },
+#      duplicates: { items:[ {pageId, path, reason:"duplicate_cluster:<peerIds>"}, … ], total },
+#      stale:      { items:[ {pageId, path, reason}, … ], total },
+#      conflicts:  { items:[ {pageId, path, reason:"remote-conflict",
+#                             metadata:{…, latestTwoVersionSummaries}}, … ], total },
+#      oversized:  { items:[ {pageId, path, reason:"oversized:toc_entries,body_chars",
+#                             metadata:{bodyChars, tocEntries, softThresholds, advisory:true}}, … ], total } } }
+```
+
+**STEP 1b — REVIEW the conflicts.** `memory_curate(op="candidates", kind="conflicts")`
+lists pages whose current head landed via a remote-conflict LWW merge (two devices
+diverged); each item carries the latest two version summaries (changeSummary /
+authoredBy / createdAt) so you can judge which side won. For each one, confirm the
+head is correct — `memory_load` it and check the LWW winner didn't clobber the better
+content; if it did, `memory_write` the corrected body. Conflict is a STATE, not a
+brand: a curation touch or clean rewrite of the page clears it (an identical-content
+rewrite is a no-op and does NOT), so a reviewed page drops off this list on the next
+`candidates` read.
+
+**STEP 1c — REVIEW the oversized hubs.** `memory_curate(op="candidates",
+kind="oversized")` lists hubs whose body chars or stored TOC entry count exceeds the
+advisory soft thresholds, plus INDEX advisories based on its authored body size (its
+Contents is graph-derived). These are **split suggestions, never enforcement** — a
+lean hub (overview + TOC) keeps every multi-hop recall fast. For a hub with too many
+children, split by sub-topic: pick the natural anchor leaf of each sub-cluster,
+`promote_to_hub` it WITH its `childPaths`, and the moved children drop out of the
+parent's TOC on the next rebuild. A hub that is oversized because its overview prose
+grew into an essay: move the essay's durable content into a leaf under the hub and
+shrink the overview back to a summary. Use your judgment — an advisory you deliberately
+leave alone (and say so in the report) is a valid outcome.
+
+**STEP 2 — BROWSE the structure.**
+
+```
+memory_browse(query="<dominant candidate topic>")
+# → { index, hubs:[{path,title,pageType,snippet}], nearest:[…] }
+```
+
+One call shows you which hubs already exist and what each is about — decide whether a
+candidate cluster belongs under an EXISTING hub (attach, don't mint a duplicate hub) or
+needs a new one. Spot-check individual members with `memory_load` only where the title
+is ambiguous; do not load every page.
+
+**STEP 3 — DECIDE clusters (your LLM — this is the point).** Group the orphan leaves by
+topic. A cluster is a set of leaves that genuinely share one topic and deserve a single
+hub above them. For duplicate clusters, decide:
+
+- Same topic, one is a clear superset → **merge** (fold content, supersede the loser).
+- Adjacent but distinct → **link, don't merge** (write with `relation="related"` or a
+  typed `<a rel="related">` with a canonical href) — merging distinct facts loses recall
+  precision.
+- Ambiguous / high-stakes → **do not enact**; leave it for human review. When unsure,
+  prefer leaving two pages over deleting one.
+
+**STEP 4 — ENACT per cluster: promote WITH children.**
+
+```
+memory_curate(op="promote_to_hub",
+              pageId="<id of the cluster's natural anchor page>",
+              childPaths=["project/helios-billing.pkf",
+                          "project/helios-db-choice.pkf",
+                          "project/helios-deploy.pkf", …])
+```
+
+One call: the anchor becomes a hub AND every member is attached under it as a child.
+For a cluster that belongs under an EXISTING hub (found in STEP 2), don't promote —
+attach the members to that hub (`memory_write` the member with
+`parentHubPath="<existing hub path>"`; use `op="append-section"` rather than a
+full-page rewrite when touching someone else's page). For merge losers and garbage:
+`memory_curate(op="supersede", pageId="…", reason="…")`.
+
+**STEP 5 — REBUILD hub navigation once per batch.**
+
+```
+memory_curate(op="rebuild_index")
+```
+
+Each touched hub's strict PKF `#toc` regenerates with child descriptions. The top INDEX
+Contents changes automatically because it is a live graph projection—no INDEX body
+revision is minted. Leaves that now have a hub parent drop out of the flat top level.
+
+**STEP 6 — MAINTAIN authored prose (your editorial duty).** After the structure settles,
+read the INDEX and touched hubs. Refresh each hub's `<h2 id="overview">` and any stale
+authored INDEX semantic section. Reuse the loaded section's existing `data-sid`; for a
+new section, run `pkf_mint_sids`, then `pkf_validate` on the complete resulting page
+before persisting. Section-operation content is a complete `<section>…</section>`:
+
+```
+memory_write(
+  path="project/helios.pkf",
+  op="rewrite-section",
+  section="overview",
+  content="<section><h2 id=\"overview\" data-sid=\"<reuse-or-minted-sec-id>\">Overview</h2><p>Helios is the Q3 billing replatform —
+  auth, billing and deploy decisions live here; the postmortems under it record why
+  rate limits were re-tuned twice. Start at <a href=\"<canonical href from browse>\"
+  rel=\"references\">the API spec</a>.</p></section>")
+```
+
+A hub you just promoted has no overview yet — `op="append-section", section="overview"`
+seeds it. Never touch the `#toc` section while you are in there.
+
+**STEP 7 — VERIFY and REPORT.** Call `memory_curate(op="candidates")` again — the
+orphans you clustered should be gone. Then **report the structural changes in your
+reply**: which hubs you created/promoted, how many children each absorbed, what you
+superseded and why, which overviews you wrote/refreshed, which oversized advisories you
+split or deliberately left, and the before→after orphan count. A convergence run that
+ends without a structural report is unverifiable.
+
+### Worked example — 8 scattered `project/helios-*` leaves → one hub
+
+`candidates` returns 8 orphan leaves hanging off INDEX directly (`project/helios-auth.pkf`,
+`project/helios-billing.pkf`, `project/helios-db-choice.pkf`, `project/helios-deploy.pkf`,
+`project/helios-api-spec.pkf`, `project/helios-rate-limits.pkf`, `project/helios-oncall.pkf`,
+`project/helios-postmortem-0420.pkf`).
+
+```
+# 1-2. read candidates + browse — no existing helios hub, all 8 are one topic
+memory_curate(op="candidates", kind="orphans")
+memory_browse(query="helios project")
+
+# 3. decide: ONE cluster; helios-auth is the natural anchor
+
+# 4. promote the anchor WITH the other 7 attached in the same call
+memory_curate(op="promote_to_hub", pageId="<id-of-helios-auth>",
+              childPaths=["project/helios-billing.pkf", "project/helios-db-choice.pkf",
+                          "project/helios-deploy.pkf", "project/helios-api-spec.pkf",
+                          "project/helios-rate-limits.pkf", "project/helios-oncall.pkf",
+                          "project/helios-postmortem-0420.pkf"])
+
+#    the 0420 postmortem is superseded by a newer incident page → archive it
+memory_curate(op="supersede", pageId="<id-of-helios-postmortem-0420>",
+              reason="merged into project/helios-auth#incidents")
+
+# 5. rebuild once — hub #toc regenerates; INDEX Contents follows the graph live
+memory_curate(op="rebuild_index")
+
+# 6. seed the new hub's overview (the machine never writes this prose)
+memory_write(path="project/helios-auth.pkf", op="append-section", section="overview",
+             content="<section><h2 id=\"overview\" data-sid=\"<minted-sec-id>\">Overview</h2><p>Helios project knowledge —
+             auth is the anchor; billing/db/deploy/api-spec/rate-limits/oncall hang
+             under it. The 0420 postmortem is archived into #incidents.</p></section>")
+
+# 7. verify: orphans 8 → 0 for this topic; REPORT the delta in your reply
+memory_curate(op="candidates", kind="orphans")
+```
+
+Result: the derived INDEX Contents shows one described hub entry instead of 8 bare leaves; the facts
+are reachable `INDEX → hub → leaf`, and the hub opens with prose that says what lives
+there. The flat star collapsed into a readable tree — in ~7 tool calls.
+
+## Folding content on a merge
+
+When one page absorbs a true duplicate: copy any durable fact the survivor lacks into
+the survivor's matching section (`memory_write` with `op="append-section"` /
+`op="rewrite-section"` — never a whole-page rewrite of a page another agent authored;
+the section body follows `pkf-writing`), then `supersede` the loser with a reason naming
+the survivor's path. The loser is archived, not hard-deleted — it stays for audit and
+redirect.
+
+## Stop conditions
+
+- Enact only **clear** merges; one ambiguous call left un-enacted is better than one
+  wrong merge that destroys recall.
+- Batch a handful of clusters, `rebuild_index` ONCE, verify, report, stop. Do not loop
+  the whole graph every tick — Dream is incremental.
+- Never hand-write a hub `#toc`; `rebuild_index` is its only writer. Never store an
+  INDEX TOC copy—the reader derives Contents. Hub overviews and authored INDEX semantic
+  sections are your editorial territory.
+
+## Anti-patterns
+
+- ❌ Promoting a hollow hub (no `childPaths`) and then re-anchoring members one at a
+  time — pass the children in the promote call.
+- ❌ Hand-writing `child-of` links inside a HUB pointing down at leaves — `child-of`
+  edges point FROM the child TO the hub; the structural params get this right for you.
+- ❌ Hand-editing a hub `#toc`, or creating a stored INDEX `#toc`; declare edges +
+  `rebuild_index`. Leaving hubs with no overview prose is its own anti-pattern.
+- ❌ Treating message-inline/Asset PKF as a Dream candidate before it becomes an
+  authoritative Memory Page.
+- ❌ Whole-page-rewriting another agent's page to fold in one fact — append a section
+  (`op="append-section"`).
+- ❌ Treating an `oversized` advisory as an order — it is a split *suggestion*; splitting
+  a coherent hub just to satisfy a threshold destroys navigability. Judge, then report.
+- ❌ Merging two pages because they share a topic word — they may carry distinct facts.
+  Read them first; merge only clear duplicates.
+- ❌ Hard-deleting. You `supersede` (reversible archive), never destroy.
+- ❌ Running the whole graph every tick. Dream is incremental: a handful of clear
+  merges, one rebuild_index, verify, stop.
+- ❌ Enacting an ambiguous/high-stakes merge. Leave it for human review; Dream cannot
+  reconstruct a wrongly-merged page.
+- ❌ Retrying a `403 orchestrator_only` — you are not the appointed orchestrator; that
+  is correct, not an error.
+- ❌ A deputy assuming Dream rights because its bound member is the owner — the
+  deputy agent itself must be the appointed `orchestratorAgentId`.
+- ❌ Ending a convergence run without reporting the structural delta (hubs created,
+  children attached, pages superseded, orphan count before→after).

package/built-in-skills/office-artifacts/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: office-artifacts
+scope: persistence
 description: Generate real DOCX, PPTX, XLSX, PDF, CSV files using python-docx / python-pptx / openpyxl / reportlab by writing them into the dispatch artifacts dir, then explicitly deliver each one with `cloud deliver <abs-path>`. Use whenever the user asks for documents, slides, spreadsheets, reports, or PDFs.
 ---
 
@@ -76,7 +77,7 @@ every file you want the user to receive.
 
 Lie-guard (`src/im/ws/handler.ts`) **as of release201/30 §8 is
 warn-only telemetry**, not a destructive interceptor — the audit
-banner ("CEO 声明已生成文件但未真正落盘") that used to render in
+banner ("Team Manager 声明已生成文件但未真正落盘") that used to render in
 red is removed. The detector still logs a `[warn] claim/asset
 disagreement (warn-only, see release201/30 §8)` for ops dashboards
 when text claims a file but `assetIds` is empty. That signal helps
@@ -102,9 +103,21 @@ If (1)-(3) fail, your reply must start with `无法生成文件
 ## Runtime baseline (release 201)
 
 Sandbox image bakes `python-docx`, `python-pptx`, `openpyxl`,
-`reportlab`, `pandas`, `pillow`, `numpy`, `imageio`, apt `file`. If an
-import fails at task time, fail with `module 'X' missing — rebuild
-sandbox image`. Do not `pip install` on the fly.
+`reportlab`, `pandas`, `pillow`, `numpy`, `imageio`, apt `file` — all of
+them inside the image venv interpreter **`/home/user/.venv/bin/python3`**
+(NOT the system `/usr/bin/python3`, which has NONE of these libraries).
+Always run generator scripts with that interpreter, e.g.
+
+```bash
+/home/user/.venv/bin/python3 generate_report.py
+```
+
+If an `import docx` (or `pptx` / `openpyxl` / `reportlab`) probe fails, DO
+NOT conclude the dependency is missing until you have retried under
+`/home/user/.venv/bin/python3` — a failure under the system python only
+means you probed the wrong interpreter. Only when the import ALSO fails
+under the venv interpreter, fail the task with `module 'X' missing —
+rebuild sandbox image`. Do not `pip install` on the fly.
 
 ## Resolving the output directory
 

package/built-in-skills/okr/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: okr
+scope: persistence
+description: Draft and track a strategic OKR charter — turn a human's plain-language goal into ONE Objective + 2-5 measurable Key Results, link existing tasks, and route the commit to a human sponsor. Use whenever the user wants to set a strategic goal / OKR / objective, "立个 OKR", or "把 X 推到 GA". Executes via the `cloud okr` CLI.
+---
+
+# OKR
+
+Use this skill to **draft an OKR charter** from a human's goal: one Objective, 2-5 Key Results, each with a baseline→target and a *real* evidence source, plus links to the tasks that move them. Every operation goes through the `cloud okr` CLI — never tell the user an objective was created / committed / scored unless the command actually returned an id and state.
+
+You **draft and propose**. The human **commits**. That split is the whole point of this skill (see ⛔ hard rules).
+
+## When to use
+
+- The user wants to **set a strategic goal**: "let's set an OKR for Q3", "立个 OKR", "make reliability our objective this cycle", "把搜索推到 GA".
+- A long-running objective should become a tracked **Objective + Key Results**, not a loose `kind=goal` card. (When the user says "make this a goal", draft an objective charter here, not a plain task.)
+- You need to **link** existing tactical tasks to the Key Result they serve.
+- The user wants to **see OKR health** — the objective tree with KR progress.
+
+If the request is a single tactical deliverable ("review this PR", "write the report"), that's the `tasks` skill, not this one. Strategic outcome → here; tactical card under an existing objective → `tasks` with the KR link.
+
+## Charter drafting methodology
+
+From a human's plain-language goal, draft **ONE Objective + 2-5 Key Results**. Before drafting, ask for whatever is missing:
+
+- **Outcome** — what observable end-state defines success? (the Objective title)
+- **Deadline / cycle** — which cycle does this belong to? (`--cycle 2026-Q3`)
+- **Owner** — which agent/human drives it? (`--owner <imUserId>`)
+- **Sponsor** — which **human/admin** stands behind it? (`--sponsor <human imUserId>`) — **required for a committed objective.**
+- **Per KR**: a baseline → target, and a **measurable source**. Today's KNOWN sources are ONLY:
+  - **task acceptance** — a `task`/`milestone` KR whose progress is the count of linked tasks that pass acceptance.
+  - **IMMetricEvent metric binding** — a `metric` KR bound to an existing metric stream (`--metric-namespace --metric-name --metric-agg`).
+  - **human-confirm** — a `qualitative` KR a human scores explicitly with a value + evidence.
+
+Then:
+
+1. **Draft the objective** (agent proposes — it is NOT yet committed):
+
+   ```bash
+   cloud okr objective create \
+     --workspace "$PRISMER_WORKSPACE_ID" \
+     --title "Search is GA-ready" \
+     --type committed \
+     --narrative "Definition of done: search ships to all users with p95 < 300ms and zero P0s." \
+     --cycle 2026-Q3 \
+     --owner <imUserId> \
+     --sponsor <human imUserId>
+   ```
+
+2. **Propose each KR** with baseline/target/unit/direction/weight + an evidence policy:
+
+   ```bash
+   # metric-backed KR (bound to a real IMMetricEvent stream)
+   cloud okr kr add <objectiveId> \
+     --title "p95 search latency under 300ms" \
+     --type metric --baseline 480 --target 300 --unit ms --direction decrease --weight 2 \
+     --metric-namespace search.latency --metric-name p95 --metric-agg last \
+     --evidence "IMMetricEvent search.latency:p95, last value per cycle"
+
+   # task-backed KR (progress = linked tasks that pass acceptance)
+   cloud okr kr add <objectiveId> \
+     --title "Ship 4 launch-blocker fixes" \
+     --type task --baseline 0 --target 4 --direction increase \
+     --evidence "count of linked tasks with passing acceptance"
+   ```
+
+3. **Link existing tasks** to the KR they serve (don't create unscoped strategic tasks):
+
+   ```bash
+   cloud okr link <objectiveId> <keyResultId> <taskId>
+   ```
+
+4. **STOP and hand the commit to the human sponsor.** Print the objective id + KR ids and say: *"Charter drafted. @<sponsor> (human) — review and `cloud okr objective commit <id>` when you approve."* Do **not** commit it yourself.
+
+## ⛔ Hard rules
+
+These are enforced server-side; violating them returns a `403` you cannot work around.
+
+1. **NEVER commit an objective yourself.** `cloud okr objective commit` requires a **human sponsor**; an agent caller gets `AGENT_CANNOT_COMMIT`. Your job ends at *draft + propose*. Surface the objective and ask the human sponsor to commit.
+2. **A `committed`-type objective REQUIRES a human/admin sponsor** (`--sponsor <human imUserId>`). Without one, commit returns `SPONSOR_MUST_BE_HUMAN`. An `aspirational` objective may skip the sponsor.
+3. **NEVER score a `qualitative` KR without an explicit, human-confirmed value + evidence.** Use `cloud okr kr recompute <krId> --value <n> --evidence <ref>` and only with a value the human actually gave you. Metric/task KRs recompute from their real source automatically — don't hand-feed numbers there.
+4. **Bind KRs ONLY to today's sources** — task acceptance, IMMetricEvent metric binding, or human-confirm. Do **NOT** invent token/spend/credit targets, CRM pipelines, or analytics metrics — those data sources do not exist (FROZEN). A KR whose evidence you can't name is not a KR; ask the human how it will be measured.
+5. **Do NOT create unscoped strategic tasks.** Tactical work for an objective is an existing task **linked to a KR** via `cloud okr link`. If strategic work has no task yet, draft the objective/KR first, then create the task (via the `tasks` skill) and link it.
+
+## Lifecycle back-half
+
+After an objective is committed it runs through `committed → graded → archived`:
+
+- **Check-ins** — you (an agent) MAY draft a check-in. It snapshots the score + each KR's current/status. `cloud okr objective checkin <objectiveId> [--note "<t>"] [--confidence 0.6] [--decision continue|rescope|add-resource|pause|cancel]`.
+- **Grade and archive are HUMAN decisions.** `cloud okr objective grade <id>` and `cloud okr objective archive <id>` return `AGENT_CANNOT_GRADE` (403) for an agent caller — surface the objective and ask the human to grade. Grade freezes the score (it stops moving even if a KR's evidence changes). An archived objective is read-only.
+
+Check-in `--decision`, `--confidence`, and the reward/resource shapes carry **no token/credit meaning** — there is no compensation here.
+
+## FROZEN / out of scope
+
+This skill draws ONE Objective + its KRs and links tasks. It does **NOT** propose, create, or mutate any of the following — they are explicitly out of scope for release203 and have no endpoints here:
+
+- **Guardrails** — no guardrail proposals or activations.
+- **Resource / budget allocation** — no credit/budget/resource grants.
+- **Scenario packs** — none.
+- **Proactive / recurring check-ins** — you record a check-in only when asked; there is no auto-scheduler.
+- **Compensation** — no reward/bonus economics (the grade carries no payout).
+
+If the user asks for any of these, say it's not part of the OKR charter flow yet rather than improvising one.
+
+## CLI Reference
+
+### Objectives
+
+```bash
+# Draft (agent proposes — NOT committed)
+cloud okr objective create --workspace <id> --title "<outcome>" \
+  [--type committed|aspirational] [--narrative "<DoD>"] [--cycle 2026-Q3] \
+  [--owner <imUserId>] [--sponsor <human imUserId>] [--parent <objectiveId>] [--confidence 0.7]
+
+cloud okr objective list --workspace <id> [--state <state>]
+cloud okr objective get <objectiveId>
+
+# HUMAN/SPONSOR ONLY — an agent caller gets AGENT_CANNOT_COMMIT
+cloud okr objective commit <objectiveId>
+cloud okr objective close <objectiveId> [--score 0.8]
+```
+
+### Key Results
+
+```bash
+cloud okr kr add <objectiveId> --title "<measurable result>" \
+  [--type metric|task|milestone|qualitative] \
+  [--baseline <n>] [--target <n>] [--unit <u>] \
+  [--direction increase|decrease|maintain|binary] [--weight <n>] \
+  [--metric-namespace <ns> --metric-name <name> --metric-agg avg|sum|last|count] \
+  [--evidence "<policy>"] [--source assigned|agent-proposed]
+
+# Qualitative KR scoring — human-confirmed value + evidence ONLY
+cloud okr kr recompute <keyResultId> [--value <n>] [--evidence <ref>]
+```
+
+> `--source` defaults to `agent-proposed` (you, the agent, are drafting). Pass `--source assigned` only when the human explicitly assigned the KR.
+> `--metric-namespace` and `--metric-name` must be given together to bind a metric source.
+
+### Linking + reading
+
+```bash
+cloud okr link <objectiveId> <keyResultId> <taskId>   # scope a task to a KR
+cloud okr insights --workspace <id>                    # the OKR tree + KR progress (never fabricated)
+```
+
+## Output reporting
+
+After any state-changing command, **echo back** the id and the **state the service returned** (not the state you expected). Example:
+
+> Drafted objective `cmobj...` (state `draft`) with 3 KRs. @<sponsor> — `cloud okr objective commit cmobj...` to commit.
+
+If a command exits non-zero, surface the error code verbatim — especially `AGENT_CANNOT_COMMIT` / `SPONSOR_MUST_BE_HUMAN`, which mean a human must act. **Never fabricate an objective/KR id or a KR value** — if you didn't run the command or it failed, say so.

package/built-in-skills/persona/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: persona
+scope: common
+description: >
+  The discussion-only playbook for a Persona — a council participant
+  instantiated as a real agent from the `persona` role template (SS-02). Use
+  this when you have been convened into an expert roundtable as a distilled
+  public-record perspective. It defines HOW to participate: speak in-voice,
+  reason, and cite public materials — and declares the hard capability boundary
+  (no task.create / no skill.install / no spend / no publish). The boundary is
+  ENFORCED by the role's toolsetScope + mcpAllowlist + service authz, not by
+  this text; this skill is the behavioral norm that matches the gate.
+license: MIT
+compatibility:
+  - prismer-sdk
+  - hermes
+metadata:
+  category: council
+  personaPolicy: public_distillation
+  disclaimerRequired: true
+  allowedUse: [analysis, debate, ideation]
+  forbiddenUse:
+    - impersonation
+    - private_claim
+    - task_create
+    - skill_install
+    - spend
+    - publish
+  capabilityBoundary:
+    intent: discussion-only
+    allowed: [speak, reason, cite_materials, recall_memory]
+    denied:
+      - capability: task.create
+        enforcedBy: [toolsetScope.deny(kanban,delegation,terminal,code_execution), mcpAllowlist.omit(prismer.task.*)]
+      - capability: skill.install
+        enforcedBy: [toolsetScope.deny(skills,terminal,code_execution), mcpAllowlist.omit(prismer.skill.install)]
+      - capability: spend
+        enforcedBy: [toolsetScope.deny(terminal,code_execution), skill_not_granted(wechat-pay), service_authz(payment_mandate)]
+      - capability: publish
+        enforcedBy: [mcpAllowlist.omit(prismer.evolve.publish,prismer.community.post), service_authz(owner_approval_gate)]
+---
+
+# Persona — discussion-only council participant
+
+You have been convened into an expert roundtable as a **Persona**: a lens distilled
+from the **public record** of a real, publicly-verifiable person. You are a real
+agent with your own identity and session — but your capability surface is
+deliberately **narrowed to discussion**.
+
+## What you do
+
+1. **Speak in-voice.** Hold one consistent vantage and voice across turns. You occupy
+   a distinct stakeholder position — surface what you can see that others cannot.
+2. **Reason.** Weigh trade-offs, disagree substantively, name risks the room is missing.
+3. **Cite materials.** Ground claims in the Council Brief and public record. Use
+   `memory_recall` / asset reads to pull evidence. When you cannot ground a point,
+   **say so** (honest degradation) — never fabricate a quote or a private fact.
+
+## What you must NOT do (hard boundary)
+
+You participate by **speaking, reasoning, and citing** — nothing else. The following
+are **removed from you at the config layer** (they are not available tools, not a
+matter of you choosing to abstain):
+
+| Capability | Why it's off | Enforced by |
+| --- | --- | --- |
+| **Create / dispatch tasks** | You are a voice, not an executor | role `toolsetScope` deny `kanban`/`delegation`/`terminal`/`code_execution` + MCP allowlist omits `prismer.task.*` |
+| **Install / manage skills** | You don't reshape the workspace | `toolsetScope` deny `skills`/`terminal` + MCP allowlist omits `prismer.skill.install` |
+| **Spend / collect money** | No fiscal authority | `terminal`/`code_execution` denied (no `cloud pay` CLI), `wechat-pay` skill not granted, and the payment service requires a mandate |
+| **Publish** (catalog / community / marketplace) | No outward-facing authority | MCP allowlist omits `prismer.evolve.publish` / `prismer.community.post`, and publishing already requires **owner approval** at the service layer |
+
+If a discussion outcome genuinely needs a task, a purchase, or a publication:
+**name that need in your reply and hand it to the workspace orchestrator**
+(the Team Manager / council facilitator). Do not attempt it — the attempt would fail at the
+capability gate anyway; naming it cleanly is the correct move.
+
+## Disclaimer (compliance floor)
+
+You are a **distilled public-record perspective, not the real person**. Keep that
+framing visible. Never assert private facts, never impersonate, never let the room
+treat your words as the person's private, authoritative statement.