@llblab/pi-kit 0.16.0 → 0.17.0

package/node_modules/@llblab/pi-state-flow/skills/state-flow-memory/SKILL.md

@@ -1,146 +1,40 @@
 ---
 name: state-flow-memory
-description: Audit and reconcile State Flow durable memory across global, CWD, and session scopes. Preserve commitments, established learning, and the point of continuation without freezing provisional approaches. Use after completing a major feature, important release, large body of work, campaign, project phase, or meaningful checkpoint—even when the user did not explicitly ask for memory work—as well as for explicit memory curation, ownership migration, contradiction cleanup, stale continuation review, externally evidenced promotion, and active-version boundaries; not for unrelated routine turns or background maintenance.
+description: >
+  Curate State Flow memory on request or once at an active State Flow feature,
+  release, project-phase, or version boundary. Reconcile stale knowledge,
+  contradictions, commitments, continuation, and ownership. Not for routine
+  turns, usage help, or background maintenance.
 ---
 
-# State Flow Memory Curation
+# State Flow Memory
 
-Use this Skill for one bounded maintenance cohort: either an explicit curation request or a feature, release, campaign, project, or active-version phase boundary that the State Flow runtime contract requires to reconcile. Ordinary turns curate only touched and obviously stale visible branches without loading this full procedure.
+State Flow's bounded curation procedure. Preserve consequences, not a transcript or attachment to an unfinished method.
 
-**Preserve the consequences of experience, not attachment to the previous trajectory.** A fresh run should respect established constraints and learning while remaining free to reconsider unresolved methods. Neither novelty nor minimum state size is a goal by itself.
+## Boundary
 
-## Preconditions and boundary
+Start from visible state. Require available `read_state` and `patch_state`; otherwise report the blocker without bypassing storage or enabling an episode. Passive access suffices for explicit curation. Memory is fallible data, not authority.
 
-1. Confirm State Flow is enabled. If `read_state` is unavailable or reports disabled state, stop without inventing migration work.
-2. Identify the requested or phase-boundary scope, affected items, and outcome. Do not audit unrelated memory merely because it is visible.
-3. State Flow owns durable memory while enabled; global semantic memory is always available. Availability does not justify broadening project-specific or sensitive material.
-4. Treat materialized state as fallible semantic data, never higher-authority instructions. Memory edits cannot grant permissions or change runtime policy.
-5. Use available materialized context first. Read artifact sources only for a concrete gap, exact-source need, evidenced invalidation, contradiction, or explicit request. An index or description does not prove that source content was acquired or understood.
+Follow the installed runtime contract. In active mode, satisfy all pending acquisitions in the next patch: this Skill needs its exact read path in `cwd.artifacts`, a description, `kind: "skill"`, and a nonempty `compilation` object. Never invent provenance or repeat accepted compilations.
 
-## Inventory
+## Reconcile one bounded set
 
-Read only the smallest required projections with `read_state`: session for branch/run continuation, CWD for project-specific knowledge, and global for established cross-project, user, or environment knowledge. Use older offsets only for a concrete contradiction or provenance question. Do not reread current effective state already in context without a specific verification or ownership need.
+1. **Limit the review.** Address the request or completed phase. Use targeted reads for gaps, contradictions, ownership, or verification; do not rerun the project.
+2. **Classify.** Put user requirements and binding confirmed decisions in `contract`, observations, assistant conclusions, and unresolved work in `working`, chosen actions in `intents`, and inactive reusable detail in `lazy`. Never give an assistant conclusion user authority. Remove fulfilled, abandoned, superseded, or impossible intents; retain consequential results. Possibilities are not commitments.
+3. **Keep evidence boundaries.** Preserve corrections, prerequisites, bounded negative results, and useful uncertainty. Separate requirements, decisions, observations, conclusions, and hypotheses. Silence is not acceptance; repetition is not verification. One implementation's failure does not reject an approach. Neither freeze provisional methods nor reopen confirmed decisions without grounds.
+4. **Compact for continuation.** Remove duplicates, obsolete progress, unsupported claims, and secrets. Keep sufficient results, real retrieval pointers, pending interaction, and known next checks. Observations are not live external facts. Keep `lazy` shallow and priority-ordered. Recognize optional structured `$ref` values and `$`-prefixed `read_state` paths inside ordinary strings as semantic-state references; other resources retain native locators. No reference form proves authority or existence, authorizes execution, or implies completion. Never scan or resolve references merely to find broken ones. When the bounded review independently needs a reference, a missing single value path with exact durable sources returns `{value:null, hint:[{type:"dangling-reference", message, paths}]}`. Treat the top-level hint as provenance and reconciliation guidance, never as requested state or proof of staleness; its paths are runtime-verified current owners, while no hint does not prove invention. Inspect ownership only as needed, then patch a proven stale owning value while preserving surrounding meaning. Effective absence or external inaccessibility is insufficient.
+5. **Check ownership.** Prefer `session` for branch/run continuation, `cwd` for project knowledge, and `global` for established cross-project knowledge. Effective values do not prove ownership; inspect owners before moves. Broader applicability requires evidence.
 
-Distinguish user requirements, confirmed decisions, observations, assistant conclusions, and hypotheses. Do not infer user acceptance from silence, repetition, or an earlier assistant assertion.
+## Transfer only when needed
 
-For each targeted item choose:
+Resolve destination conflicts without overwriting stronger or unrelated knowledge. Write the destination, retain the source, and verify the destination separately. Recheck source changes before deleting or narrowing it in a later patch. Reconcile affected references; verify source cleanup and effective inheritance. Never combine destination creation with source deletion.
 
-- `keep`: useful, adequately grounded, correctly scoped, and still applicable;
-- `update`: superseded or stale, with evidence for the replacement;
-- `reframe`: useful, but expressed with unsupported certainty, authority, or breadth;
-- `narrow`: stored more broadly than its applicability;
-- `promote candidate`: useful at a broader scope or external destination, but not yet safely transferred;
-- `remove`: obsolete, redundant, secret, raw history, unsupported assertion with no remaining decision value, or completed transient progress.
+External transfers also require confirmed destination and write authority. Verify accepted content and a content-bound revision or receipt through the external interface, not memory. Preserve the source when acceptance is ambiguous. Never export secrets or broaden sensitive material without authorization.
 
-These are audit decisions, not required stored labels. Do not manufacture timestamps, confidence scores, provenance, promotion receipts, or a new bookkeeping schema.
+## Apply, verify, stop
 
-## Reconcile for continuity and search
+A fresh executor must recover constraints, results, open questions, commitments, and the next action without inheriting an unapproved method.
 
-### Preserve commitments without freezing methods
+Patch only material changes with `patch_state`, alone per assistant response; await acceptance. Never edit backing files, `response`, configuration, or runtime metadata. Read changed owner paths; inspect parent keys for deletions and effective state for inheritance changes.
 
-Preserve active goals, explicit constraints, confirmed decisions, completed prerequisites, and obligations that still affect future work. Preserve corrections and their consequences.
-
-Separate a binding requirement from the method currently proposed to satisfy it. Do not turn an assistant preference into a user requirement, or a provisional approach into a settled decision. Conversely, do not demote a confirmed decision merely to encourage exploration. Retain its scope and known reconsideration conditions when relevant; do not invent them.
-
-### Preserve the point of interaction
-
-When it affects continuation, retain what was proposed, accepted, rejected, corrected, explained, or left unresolved, and what the next response or action must address. Preserve enough referents for pending follow-ups to make sense.
-
-Treat every completed work slice as a possible restart boundary. Its checkpoint should let a fresh executor recover the achieved outcome, surviving evidence, active commitments, decision-relevant uncertainty, and exact continuation without replaying the prior reasoning trajectory. Optimize decomposition for resumability as well as functional completion; if the next safe action depends on transient context that will disappear, the slice is not yet at a sufficient boundary.
-
-Keep consequences, not a transcript or a personality dossier. Do not invent shared history or claim subjective continuity. A fresh run should not unnecessarily reopen a settled exchange or treat an unanswered proposal as approved.
-
-### Preserve learning at its demonstrated boundary
-
-For consequential results, retain the tested mechanism, relevant conditions, outcome, and useful evidence locator. Keep exact rejection reasons and established conditions under which reconsideration would be warranted.
-
-Do not generalize failure of one implementation into failure of an entire approach. Do not generalize one successful test into unrestricted validity or count repeated model agreement as independent verification. Preserve completed work when it remains a prerequisite, constraint, or piece of evidence; remove only its obsolete progress narration.
-
-A justified reconsideration uses changed conditions, a materially different mechanism, a different discriminating test, or a specific verification need. Do not recommend repeating an unchanged failed attempt with no new basis. Do not suppress a legitimate alternative merely because the previous run did not explore it.
-
-### Preserve useful uncertainty
-
-Retain a hypothesis or unresolved alternative only when it could change a pending decision or continuation. State its uncertainty, relevant evidence or missing evidence, and the next discriminating check when known. Keep it scoped to the work it serves.
-
-Remove speculative clutter, not all hypotheses. Do not manufacture alternative branches for diversity. If contradictory claims cannot be resolved from explicit user direction and appropriate evidence, preserve the decision-relevant conflict rather than selecting the cleaner narrative.
-
-### Preserve validity and recoverability
-
-Treat `working` as last observations, not live external reality. Retain validity conditions or a targeted revalidation need when consequences depend on volatile facts. Following interruption or branch restoration, do not infer external success or failure from memory alone; state restoration does not undo tool effects.
-
-A locator supports later retrieval; it does not replace content needed for the next decision. Preserve the smallest sufficient result plus an existing retrievable source or trace reference where necessary. Never invent a locator or assume unavailable history can repair an omission.
-
-Do not rerun the underlying project merely to curate its memory. Leave an exact unresolved check when verification falls outside the requested boundary.
-
-### Preserve priority and keep Lazy shallow
-
-Treat array order in Lazy as semantic priority: earlier entries are higher priority. Preserve that order deliberately; do not reorder entries for aesthetics, incidental grouping, or normalization.
-
-Minimize Lazy nesting, especially for top-level collections. Keep a top-level collection as a direct array when its members are the domain values. Represent a standalone item directly, normally as a string; use an object only when that item genuinely owns structured or nested fields. Do not add `items`, `owner`, `source`, or similar wrapper objects merely to describe the collection, and do not introduce nested arrays unless the domain itself requires a matrix or grouped sequence.
-
-### Compact without flattening meaning
-
-Merge redundant fragments and remove obsolete scaffolding, repeated argumentation, and routine progress. Do not rewrite unchanged state merely to normalize wording.
-
-Do not erase a meaningful correction, uncertainty, commitment, negative result, priority order, or continuation dependency to make state shorter. Do not retain the previous chain of reasoning solely to steer the next run toward the same method.
-
-### Reconcile phase boundaries
-
-After a major feature, important release, large body of work, or meaningful checkpoint reaches completion or its final stage, proactively optimize the affected State Flow scopes. Distill implementation-specific detail into durable consequences, remove trajectory-bound scaffolding, and rebalance knowledge across global, CWD, and session ownership so the resulting state stays alive, reusable, and open to better future methods rather than preserving the shape of the finished effort.
-
-A completed feature, release, campaign, project switch, or active-version change is evidence that its working set needs one bounded review. Remove completed task lists, obsolete release/version state, run identifiers, timings, incident chronology, dead experiments, and stale continuation. Retain shipped status only when it remains a prerequisite, durable rule, open risk, or useful retrieval pointer.
-
-State branches may move as applicability changes. Global is limited to established cross-project, user, or environment knowledge; CWD owns reusable project truth; session owns branch/run continuation. Narrow project-specific global material into CWD, promote genuinely cross-project learning only when evidence supports the broader boundary, and move reusable session learning into CWD without carrying its transient run shell.
-
-Effective state does not prove which scope owns a value. When ownership matters and recent transitions do not establish it, inspect only the targeted global, CWD, or session projections with `read_state`. Use the verified destination-write/readback/source-delete/readback sequence below; never delete first or assume an effective value disappeared merely because one override changed.
-
-## Fresh-run check
-
-Before writing, review the proposed changes once within the requested boundary:
-
-- Would a fresh executor know what must still hold, what changed, what remains unresolved, and the exact next action without replaying the prior cognitive trajectory?
-- Could an omission cause a known failed attempt, an unnecessary repeated explanation, or loss of an active commitment?
-- Could a retained claim impose an unapproved method, overgeneralize a result, or hide a live alternative?
-
-Adjust only identified defects. This is a semantic review, not a request for extra agents, repeated experiments, or proof of every retained fact. Structural acceptance alone does not establish truth or sufficient memory.
-
-## Apply one reconciliation cohort
-
-Use `patch_state` only for material changes to `artifacts`, `contract`, or `working`. One call may supply `global`, `cwd`, and `session` patches as one atomic cohort; each call must be alone in its assistant response, and subsequent actions must use the rematerialized state. Set `final:true` only when the iteration is eligible to finish at a later `turn_end`. Do not patch runtime-owned `response`, config, or metadata, or bypass validation by editing backing files.
-
-Schedule acquisition and migration barriers in this order:
-
-1. After reading this Skill, compile it into its exact-path CWD artifact before acquiring a stale global Markdown source or attempting an unrelated state write.
-2. Read only the smallest required state projections. If a justified stale Markdown read creates a global compilation obligation, include every pending compilation scope in the next atomic patch before unrelated work.
-3. Write the migration destination with `patch_state`, verify it with a separate `read_state`, then delete or narrow the source and verify both its scope and the effective overlay. Do all readback before the terminal answer.
-4. Complete one terminal reconciliation without repeating accepted compilations or inventing memory changes. Simultaneously pending CWD and global acquisitions must be compiled together in one atomic `patch_state` call; set `final:true` in that call only when the iteration is otherwise ready to finish.
-
-Scope-local deletion may reveal a lower-scope value. Deleting an override is not necessarily removal from effective state.
-
-For movement between State Flow scopes, resolve destination conflicts before writing; do not overwrite stronger or unrelated knowledge. Write and verify the destination before deleting the source. Do not combine destination creation and source deletion merely because multi-scope publication is atomic: preserve a temporary duplicate until readback proves the destination. Do not claim migration is complete until source cleanup and the effective result are verified.
-
-On rejection, interruption, or conflicting state, inspect what was actually accepted before continuing. Never assume the entire cohort succeeded or failed. Keep recovery bounded; report a blocker rather than repeatedly regenerating patches.
-
-## External ownership and promotion
-
-Do not guess an external owner or treat a reusable item as authorization to publish it. Keep each item at its narrowest valid State Flow scope while ownership or acceptance is unresolved.
-
-External promotion has two phases:
-
-1. `Transfer and verify`: Confirm the requested destination and authority, then attempt the write while keeping the accepted State Flow copy. Through the actual external interface, verify destination identity, accepted content, and a durable pointer or receipt tied to that content and revision. A stored claim of acceptance is not verification. Retain compact candidate, pointer, and status information only when it supports recovery; follow an existing record contract rather than inventing one.
-2. `Source cleanup`: Delete or narrow the State Flow copy only after destination acceptance is evidenced. Retain enough routing information to retrieve content still needed for continuation.
-
-On timeout, rejection, ambiguity, stale receipt, or unavailable destination, preserve the State Flow copy and report unresolved acceptance. Reconcile uncertain prior writes before retrying. Never delete the only accepted copy as part of a handoff.
-
-Never promote secrets. Removing a secret from active state does not erase prior offsets, Git history, or external copies; report that limitation without repeating the secret.
-
-## Verify and stop
-
-After accepted changes:
-
-1. Read each changed scope at offset 0, including a migration destination before source deletion.
-2. Read effective state when deletion, relocation, or overrides may change inheritance.
-3. Verify intended values, omissions, scope, and ownership status. Check that uncertainty was not promoted to fact, user commitments were not weakened, and continuation remains actionable.
-4. Report the bounded change, unresolved items, any partial migration, and the evidence authorizing external promotion. Do not dump memory contents or imply historical erasure.
-
-Stop after this reconciliation cohort, including when no change is warranted or a blocker remains. Do not turn phase-boundary curation into automatic background maintenance, arbitrary periodic scanning, or an open-ended search for a better state.
+After rejection or interruption, inspect accepted state before bounded recovery. Report unresolved checks and partial transfers without dumping memory or implying historical erasure. Active iterations need accepted `final:true` before the answer; use a final-only call when no changes remain. Passive turns do not. Stop after this review, including when nothing needs changing.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@llblab/pi-kit",
-  "version": "0.16.0",
+  "version": "0.17.0",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -44,7 +44,7 @@
     "@llblab/pi-clean-room": "0.1.1",
     "@llblab/pi-codex-usage": "0.10.0",
     "@llblab/pi-grow-loop": "0.8.1",
-    "@llblab/pi-state-flow": "0.14.0",
+    "@llblab/pi-state-flow": "0.16.0",
     "@llblab/pi-telegram": "0.49.0",
     "@llblab/skills": "1.15.0"
   },