first-tree-staging 0.5.4-staging.294.1 → 0.5.4-staging.296.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "first-tree-staging",
-  "version": "0.5.4-staging.294.1",
+  "version": "0.5.4-staging.296.1",
   "type": "module",
   "description": "First Tree — unified CLI for Context Tree onboarding, agent management, and team messaging. (Source-tree dev build; CI rewrites `name` and `bin` for prod / staging publishes — see docs/local-dev-isolation.md.)",
   "keywords": [

package/skills/first-tree-context/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: first-tree-context
-version: 0.8.2
+version: 0.8.4
 cliCompat:
   first-tree: ">=0.5.0 <0.6.0"
 description: Context Tree operating guide. Covers what a Context Tree is, the source-system boundary, how to read the tree before acting, and how to write tree updates from a specific source (PR / doc / note). Load before any task that reads or writes context — including when the user pastes a PR / doc / note and says "reflect this in the tree", "update the tree from this", or "write this decision to the tree".
@@ -194,34 +194,46 @@ goes in frontmatter:
   may have, are where prior states live). The Source-System
   Boundary table above is the canonical guide for which "whats"
   belong.
-- **Why** — the path the design took to its final state: the
-  concerns weighed, the alternatives considered, the
-  course-corrections made and what triggered each one. The final
-  decision is the *What*; the path to it is the *Why*. **A node
-  without a Why is a fact, not a decision record.** Why-content is
-  the most commonly lost axis — protect it deliberately during the
-  rush to land a PR or close a meeting.
-  - **Why lives in the design phase, not the final state.** The
-    concerns, course-corrections, and dropped alternatives are
-    generated *during* design — the moment somebody flags "won't
-    this break X?", the moment a first proposal is corrected, the
-    moment an option is dropped because it conflicts with another
-    domain. By the time the PR lands the design is settled, but
-    the reasoning that settled it lives only in chat / review
-    threads / meeting notes and decays fast.
+- **Why** — the surviving rationale behind the *What*: the
+  constraints that won, the reasons each alternative lost,
+  recorded as present-tense constraint and reasoning. The design
+  phase is where this rationale is **produced** (concerns weighed,
+  alternatives considered, course-corrections introduced), but the
+  node records the **outcome** of that process — not its
+  chronology (Hard Rule 8). The final decision is the *What*; its
+  surviving rationale is the *Why*. **A node without a Why is a
+  fact, not a decision record.** Why-content is the most commonly
+  lost axis — protect it deliberately during the rush to land a PR
+  or close a meeting.
+  - **Why is generated in the design phase, captured in the
+    node.** The concerns, course-corrections, and dropped
+    alternatives that shape the design are generated *during*
+    design — the moment somebody flags "won't this break X?", the
+    moment a first proposal is corrected, the moment an option is
+    dropped because it conflicts with another domain. By the time
+    the PR lands the design is settled, but the reasoning that
+    settled it lives only in chat / review threads / meeting notes
+    and decays fast. The node captures the *outcome* of those
+    moments (the surviving constraints and reasons), not the
+    moments themselves.
   - **Course-corrections are the canonical Why.** Each correction
     encodes two things at once: an alternative that was *actually
     pursued* (not abstractly considered), and the constraint or
     insight that ruled it out. Both are exactly the content that
-    keeps the next agent from re-litigating the same path. In a
-    copilot team most corrections come from human↔agent
-    back-and-forth — capture them while you still have them.
+    keeps the next agent from re-litigating the same path.
+    Corrections surface in design-phase back-and-forth — chat
+    threads, review comments, design meetings — and decay fast
+    once the PR lands. Capture them while you still have them, but
+    apply the **Double Test** (above) before pinning: not every
+    review nit is a course-correction, and the surviving
+    constraint still has to be durable across refactors.
   - **Translate corrections into present-tense rationale, not
-    narration.** "The agent first proposed a global cache; the
-    human said no" is a timeline (Hard Rule 8 forbids it). "Cache
-    is per-tenant because multi-tenancy isolation is a hard
-    constraint" is the surviving Why. Keep the *constraint* the
-    correction introduced; drop the *story* of how it happened.
+    narration (i.e. timeline).** "The agent first proposed a
+    global cache; the human said no" is a timeline (Hard Rule 8
+    forbids it). "Cache is per-tenant because multi-tenancy
+    isolation is a hard constraint" is the surviving Why. Keep
+    the *constraint* the correction introduced; drop the *story*
+    of how it happened.
   - Other rich sources: meeting discussions where a decision was
     reached; PR review threads that changed the design.
   - Self-check: "Six months from now, if a reader reads only the
@@ -344,6 +356,13 @@ meta-narration in this skill — they are not a body section template;
 no `## Trigger` / `## Source` heading goes into the actual node (see
 Hard Rule 9).
 
+Some examples split `Belongs:` into `Belongs (What):` and `Belongs
+(Why):` to make the Content Model distinction concrete; others
+keep a single `Belongs:` line where the distinction is not
+load-bearing. Both forms describe the same underlying boundary —
+what survives in the node vs what stays in the source repo. The
+split is teaching emphasis, not a separate convention.
+
 **Trigger: PR adding a new caching layer.**
 Belongs: "Service X owns the cache; other services read through Service
 X's SDK"; "we chose Redis over Memcached because of pubsub support".

package/skills/first-tree-context/VERSION

@@ -1 +1 @@
-0.8.2
+0.8.4