@onedotmint/charterleaf 0.2.0 → 0.2.1

package/AGENTS_SNIPPET.md

@@ -16,6 +16,14 @@ Keep specs compressed and evidence-based. Prefer durable contracts and pitfalls
 
 Do not create specs for temporary implementation details, current tasks, debugging notes, routine refactors, or trivial fixes with no durable implication. For a durable bug fix, use `Current` / `Expected` when useful and explicitly state what must `PRESERVE`.
 
+After non-trivial implementation or debugging, consider whether durable project knowledge was discovered. If so, record only the durable result:
+
+- observable behavior, contract, invariant, or non-goal → capability spec;
+- long-lived implementation constraint, boundary, recurring pitfall, or required verification practice → engineering spec;
+- important architectural choice, rationale, or revisit condition → decision.
+
+If nothing durable was learned, do not modify specs. Do not record current task status, implementation progress, temporary debugging notes, one-off commands, session history, Todo items, or transient observations. Specs accumulate durable project knowledge, not development activity.
+
 For meaningful durable behavior/contract changes, use one change file with only the needed `ADD`, `MODIFY`, `REMOVE`, and/or `PRESERVE` sections. After acceptance and implementation, merge durable results into living specs and delete the change file. Git is the history.
 
 Charterleaf is a knowledge layer, not a workflow layer. It must not manage tasks, planning, agents, execution, review, memory, compression, semantic search, code/spec verification, release lifecycle, or Git history.

package/README.md

@@ -78,6 +78,8 @@ Keep specs compressed and evidence-based. Prefer contracts over commentary and r
 
 For bug fixes with durable behavioral implications, clarify `Current`, `Expected`, and `PRESERVE` when that reduces accidental scope. Do not create a spec for trivial fixes with no durable implication.
 
+After non-trivial implementation or debugging, record only genuinely durable knowledge: behavior, contracts, invariants, and non-goals in capabilities; long-lived constraints, boundaries, pitfalls, or verification practices in engineering; and important architectural choices in decisions. If nothing durable was learned, do not modify specs. Specs accumulate durable project knowledge, not development activity.
+
 Load the smallest relevant set; do not read the whole tree by default. After an accepted change is implemented, merge the durable result into living specs and delete the change file. Git is the history.
 
 ## Other agents

package/lib/charterleaf.js

@@ -384,6 +384,12 @@ function lint(cwd = process.cwd(), streams = {}) {
           ids.set(specId, filePath);
         }
       }
+
+      if (!Object.hasOwn(frontmatter, 'applies_to')) {
+        errors.push([display, 'missing applies_to']);
+      } else if (Array.isArray(frontmatter.applies_to) && frontmatter.applies_to.length === 0) {
+        errors.push([display, 'applies_to must contain at least one path']);
+      }
     }
 
     for (const field of ['applies_to', 'tags']) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@onedotmint/charterleaf",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "A tiny specification layer for coding agents.",
   "license": "MIT",
   "repository": {

package/skills/charterleaf/SKILL.md

@@ -35,6 +35,14 @@ Keep specs compressed and evidence-based. Prefer contracts over commentary and d
 
 Do not touch specs for renames, lint cleanup, routine refactors, temporary debugging, Todo/status changes, or trivial fixes with no durable implication.
 
+After non-trivial implementation or debugging, consider whether durable project knowledge was discovered. If so, record only the durable result:
+
+- observable behavior, contract, invariant, or non-goal → capability spec;
+- long-lived implementation constraint, boundary, recurring pitfall, or required verification practice → engineering spec;
+- important architectural choice, rationale, or revisit condition → decision.
+
+If nothing durable was learned, do not modify specs. Do not record current task status, implementation progress, temporary debugging notes, one-off commands, session history, Todo items, or transient observations. Specs accumulate durable project knowledge, not development activity.
+
 For a durable bug fix, use `Current` and `Expected` when useful and state what must `PRESERVE`. For other durable behavior/contract changes, keep one `specs/changes/<name>.md` delta with only needed `ADD`, `MODIFY`, `REMOVE`, and/or `PRESERVE` sections.
 
 After editing specs, run: