code-anchored-context 0.1.0 → 0.2.0

package/{Development → context}/_templates/planned-initiative/README.md

@@ -2,8 +2,8 @@
 
 Status: Planned
 Target release: vNEXT
-Program: `Development/programs/<program-slug>/`
-Promotion target: `Development/releases/vNEXT/initiatives/<initiative-slug>/`
+Program: `context/programs/<program-slug>/`
+Promotion target: `context/releases/vNEXT/initiatives/<initiative-slug>/`
 Promoted to: None
 Promoted on: None
 
@@ -14,11 +14,15 @@ and what outcome it should produce.
 
 ## Touched Areas
 
-- `src/<area>/...`
-- `deploy/...`
-- `automation/...`
+- Product or runtime code: `path/to/...`
+- Interfaces, APIs, or contracts: `path/to/...`
+- Tests or verification: `path/to/...`
+- Delivery, CI/CD, build, or artifacts: `path/to/...`
+- Infrastructure, IaC, or environment config: `path/to/...`
+- Docs or release notes: `path/to/...`
 
-Remove entries that do not apply and add the real paths.
+Remove entries that do not apply and add the real paths. Prefer naming the
+delivery concern over assuming a specific folder layout.
 
 ## Current Source Of Truth
 

package/{Development → context}/_templates/planned-initiative/release-doc-notes.md

@@ -1,20 +1,20 @@
-# Release Documentation Notes
+# Release Doc Notes
 
 Use this file to capture expected product-documentation impact while future
 work is being planned. When the planned initiative is promoted and later
 implemented, compare these notes against the final shipped behavior.
 
-Do not edit `Documentation/` from normal development work unless a human
+Do not edit `docs/` from normal development work unless a human
 explicitly asks for a documentation refresh or a specific documentation fix.
 
 ## Expected Product Behavior Changes
 
 - None yet.
 
-## Candidate Documentation Areas
+## Candidate Docs Areas
 
-- `Documentation/<Area>/README.md`
-- `Documentation/<Area>/features/<feature>.md`
+- `docs/<Area>/README.md`
+- `docs/<Area>/features/<feature>.md`
 
 ## QA Or Support Notes
 

package/{Development → context}/_templates/program/README.md

@@ -59,5 +59,5 @@ this program but are not in the current release yet.
   a scoped delivery slice before the target release becomes current.
 - Keep release-scoped implementation history in the relevant release
   initiative.
-- Use `Development/backlog/items/` for isolated deferred items that do not
+- Use `context/backlog/items/` for isolated deferred items that do not
   need a program.

package/{Development → context}/_templates/program/backlog.md

@@ -3,7 +3,7 @@
 This backlog holds future work that belongs to the program as a durable
 multi-release effort.
 
-Use `Development/backlog/items/` instead for isolated deferred work that does
+Use `context/backlog/items/` instead for isolated deferred work that does
 not need program-level context.
 
 Use `planned-initiatives/` instead when future work is already clear enough

package/{Development → context}/_templates/program/releases/v0_1_0.md

@@ -5,7 +5,7 @@
 Link to the release-scoped initiative when one exists:
 
 ```text
-Development/releases/v0_1_0/initiatives/<initiative-slug>/
+context/releases/v0_1_0/initiatives/<initiative-slug>/
 ```
 
 ## Scope

package/{Development → context}/_templates/release-context/README.md

@@ -1,6 +1,6 @@
-# vNEXT Development Context
+# vNEXT Context
 
-This folder contains development context for the `vNEXT` release.
+This folder contains working context for the `vNEXT` release.
 
 ## Navigation
 
@@ -14,20 +14,20 @@ Create an initiative when work is non-trivial, behavior-changing,
 cross-project, release-significant, or likely to need future product
 documentation.
 
-Use `Development/_templates/initiative/` as the starting point.
+Use `context/_templates/initiative/` as the starting point.
 
 ## Carry-Forward Rule
 
 If an initiative is part of a larger phased effort, link it to a program
-under `Development/programs/`.
+under `context/programs/`.
 
 If isolated work is cut from scope but should be kept for later, create a
-backlog item under `Development/backlog/items/` and link it back to the
+backlog item under `context/backlog/items/` and link it back to the
 originating initiative.
 
 ## Planned Initiative Promotion
 
 When this release becomes current, promote matching planned initiatives from
-`Development/programs/*/planned-initiatives/` into this release's
+`context/programs/*/planned-initiatives/` into this release's
 `initiatives/` folder. Leave the planned initiative in place as historical
 planning context and update its status to `Promoted`.

package/{Development → context}/_templates/release-context/backlog.md

@@ -1,6 +1,6 @@
 # vNEXT Backlog
 
-This file tracks release-level development context that is not yet captured
+This file tracks release-level working context that is not yet captured
 by an initiative, plus a short summary of initiative progress once
 initiatives exist.
 
@@ -11,4 +11,3 @@ No backlog items recorded yet.
 ## Initiative Summary
 
 No initiatives registered yet.
-

package/{Development → context}/_templates/release-transition.md

@@ -1,23 +1,23 @@
 # Release Transition Checklist
 
-Use this checklist when changing `Development/current.md` to a new current
+Use this checklist when changing `context/current.md` to a new current
 release.
 
 Target release: vNEXT
 
 ## Steps
 
-- [ ] Update `Development/current.md` to the target release.
-- [ ] Create `Development/releases/<target-release>/` from
-      `Development/_templates/release-context/` if it does not exist.
+- [ ] Update `context/current.md` to the target release.
+- [ ] Create `context/releases/<target-release>/` from
+      `context/_templates/release-context/` if it does not exist.
 - [ ] Create `README.md`, `backlog.md`, and `initiatives/` for the target
       release if missing.
-- [ ] Scan `Development/programs/*/planned-initiatives/*/README.md` for
+- [ ] Scan `context/programs/*/planned-initiatives/*/README.md` for
       `Target release: <target-release>`.
 - [ ] For each matching planned initiative, materialize it into:
 
 ```text
-Development/releases/<target-release>/initiatives/<initiative-slug>/
+context/releases/<target-release>/initiatives/<initiative-slug>/
 ```
 
 - [ ] Update the promoted release initiative so it links back to the parent
@@ -26,7 +26,7 @@ Development/releases/<target-release>/initiatives/<initiative-slug>/
 
 ```md
 Status: Promoted
-Promoted to: `Development/releases/<target-release>/initiatives/<initiative-slug>/`
+Promoted to: `context/releases/<target-release>/initiatives/<initiative-slug>/`
 Promoted on: YYYY-MM-DD
 ```
 

package/{Development → context}/backlog/README.md

@@ -1,4 +1,4 @@
-# Development Backlog
+# Context Backlog
 
 This folder stores isolated deferred work that was cut from a release
 initiative but should remain discoverable.
@@ -10,8 +10,8 @@ Use a backlog item when:
 - it does not need durable program-level context
 - it is not active in the current release
 
-Create items from `Development/_templates/backlog-item.md` and place them in
-`Development/backlog/items/`.
+Create items from `context/_templates/backlog-item.md` and place them in
+`context/backlog/items/`.
 
 When a backlog item is picked up later, do not move or rewrite the original
 item. Mark it as `Promoted` and link to the new release initiative.

package/{Development → context}/code-anchored-context-structure.md

@@ -1,37 +1,38 @@
 # Code-Anchored Context: The Structure
 
 This is the companion to the
-[reasoning article](code-anchored-context-why.md). It covers how development
+[reasoning article](code-anchored-context-why.md). It covers how working
 context is laid out so both humans and agents can navigate it.
 
 ## Denormalize Navigation, Not Knowledge
 
-Agents and IDEs do not always open from the repo root — they may start in
-`src/`, `deploy/`, or a nested app. If all guidance lives at the top, it gets
-missed. If each area keeps its own plans, cross-project work fragments.
+Agents and IDEs do not always open from the repo root. They may start in
+product code, CI/CD config, infrastructure code, generated artifacts, or a
+nested app. If all guidance lives at the top, it gets missed. If each area
+keeps its own plans, cross-project work fragments.
 
 > Denormalize navigation, not knowledge.
 
 Local `AGENTS.md` files point agents toward the right place. But plans, specs,
 ADRs, release context, testing strategy, delivery notes, and infrastructure
-context live centrally under `Development/`.
+context live centrally under `context/`.
 
 ## The Core Model
 
-Vocabulary is captured in `Development/terminology.md`. The main containers:
+Vocabulary is captured in `context/terminology.md`. The main containers:
 
 ```text
 Program                  Long-lived multi-release effort.
 Planned initiative       A scoped future slice inside a program.
 Release initiative       Active or historical work for a specific release.
-Development backlog item Isolated work cut from scope but worth preserving.
+Context backlog item     Isolated work cut from scope but worth preserving.
 Program release slice    What a release contributes to a program.
 ```
 
 Each kind of context gets a home:
 
 ```text
-Development/
+context/
   terminology.md
   current.md
   programs/
@@ -48,7 +49,7 @@ knowledge it preserves, not the tool that produced it.
 The main unit of active delivery:
 
 ```text
-Development/releases/<version>/initiatives/<initiative>/
+context/releases/<version>/initiatives/<initiative>/
   README.md   plan.md   spec.md   interface.md   architecture.md
   testing.md  delivery.md  infrastructure.md  operations.md
   backlog.md  decisions/  release-doc-notes.md
@@ -84,7 +85,7 @@ Some work is bigger than one release. A program holds durable multi-release
 context:
 
 ```text
-Development/programs/<program>/
+context/programs/<program>/
   README.md  context.md  roadmap.md  backlog.md
   decisions/  planned-initiatives/  releases/
 ```
@@ -93,20 +94,20 @@ Future work that is clear enough to plan — but whose target release is not
 current yet — becomes a planned initiative:
 
 ```text
-Development/programs/<program>/planned-initiatives/<initiative>/
+context/programs/<program>/planned-initiatives/<initiative>/
 ```
 
 When the target release becomes current, it is promoted into
-`Development/releases/<version>/initiatives/<initiative>/`. Promotion is
+`context/releases/<version>/initiatives/<initiative>/`. Promotion is
 explicit; the original planned initiative stays as historical context.
 
-## Development Backlog
+## Context Backlog
 
 Work cut from scope but worth preserving — when it doesn't justify a program or
 planned initiative — lives in:
 
 ```text
-Development/backlog/items/<originating-initiative>--<item>.md
+context/backlog/items/<originating-initiative>--<item>.md
 ```
 
 Each item records where it came from, why it was deferred, future value, and
@@ -116,7 +117,7 @@ silently rewritten.
 ## Release Transitions
 
 Changing the current release is more than editing a pointer. When
-`Development/current.md` moves to a new release, agents should scan program
+`context/current.md` moves to a new release, agents should scan program
 planned initiatives, promote items targeting the new release into the release
 folder, update links both ways, and preserve the originals as history.
 

package/{Development → context}/code-anchored-context-why.md

@@ -13,19 +13,19 @@ That context usually exists — in chats, tickets, pull request comments,
 planning notes, and people's heads — but agents need it in a structured,
 discoverable form.
 
-## Documentation vs Development
+## Docs vs Working Context
 
-This is why I separate **released product documentation** from **development
+This is why I separate **released product documentation** from **working
 context**:
 
 ```text
-Documentation/   What shipped.
-Development/      What we are planning, building, deciding, testing,
+docs/   What shipped.
+context/      What we are planning, building, deciding, testing,
                   shipping, hosting, deferring, and learning.
 ```
 
 Product documentation stays stable and release-accurate: it describes a known
-release, not an unfinished branch. Development context is allowed to evolve —
+release, not an unfinished branch. Working context is allowed to evolve —
 it is where humans and agents work through ambiguity.
 
 ## The Principle
@@ -52,8 +52,8 @@ instead of reconstructing it from memory.
 ```mermaid
 flowchart LR
   Code["Codebase<br/>What exists"]
-  Dev["Development/<br/>What is being planned, built, decided, tested, shipped, deferred"]
-  Docs["Documentation/<br/>What shipped in a known release"]
+  Dev["context/<br/>What is being planned, built, decided, tested, shipped, deferred"]
+  Docs["docs/<br/>What shipped in a known release"]
   Agents["Agents and humans"]
 
   Agents --> Code
@@ -73,7 +73,7 @@ Code-Anchored Context is context continuity. It helps agents and humans answer:
 - What should become product documentation later?
 - What reasoning needs to survive a change of IDE, agent, or session?
 
-Code tells an agent *what exists*. Development context tells it *why* it
+Code tells an agent *what exists*. Working context tells it *why* it
 exists, where it is going, what has been decided, and what was left for later.
 
 For the concrete folder layout, see the companion article,

package/{Development → context}/code-anchored-context.html

@@ -490,7 +490,7 @@
           </div>
           <div class="connector">or defer to</div>
           <div class="node backlog">
-            <strong>Development backlog item</strong>
+            <strong>Context backlog item</strong>
             <span>Isolated cut scope saved for later</span>
           </div>
         </div>
@@ -515,23 +515,23 @@
     <section id="why">
       <h2>Why This Exists</h2>
       <p class="section-intro">
-        <code>Documentation/</code> is released product truth.
-        <code>Development/</code> is working development truth. Code-Anchored
+        <code>docs/</code> is released product truth.
+        <code>context/</code> is working development truth. Code-Anchored
         Context keeps agent context, planning, and decisions visible without
         mixing in-progress thinking into released product documentation.
       </p>
       <div class="grid two">
         <div class="tile accent-release">
-          <h3>Use <code>Development/</code> while work is forming</h3>
+          <h3>Use <code>context/</code> while work is forming</h3>
           <p>
             Put plans, specs, ADRs, backlog, implementation context, future
             phases, and release-doc notes here during normal development.
           </p>
         </div>
         <div class="tile accent-program">
-          <h3>Use <code>Documentation/</code> only for shipped product docs</h3>
+          <h3>Use <code>docs/</code> only for shipped product docs</h3>
           <p>
-            Product documentation remains release anchored. Development notes
+            Product documentation remains release anchored. Working context
             can feed it later through <code>release-doc-notes.md</code>.
           </p>
         </div>
@@ -548,7 +548,7 @@
         <div class="tile accent-program">
           <h3>Program</h3>
           <p>Cross-release parent effort with durable context, roadmap, phase history, and program-level ADRs.</p>
-          <code class="path">Development/programs/&lt;program&gt;/</code>
+          <code class="path">context/programs/&lt;program&gt;/</code>
         </div>
         <div class="tile accent-planned">
           <h3>Planned initiative</h3>
@@ -577,13 +577,13 @@
       <div class="decision">
         <div class="question">Is this active in the current release?</div>
         <div class="answer">Use a release initiative. It is the delivery surface for the current release.</div>
-        <div class="target"><code>Development/releases/&lt;current&gt;/initiatives/</code></div>
+        <div class="target"><code>context/releases/&lt;current&gt;/initiatives/</code></div>
       </div>
 
       <div class="decision">
         <div class="question">Does this span releases or phases?</div>
         <div class="answer">Use a program for durable context, roadmap, and program-level decisions.</div>
-        <div class="target"><code>Development/programs/</code></div>
+        <div class="target"><code>context/programs/</code></div>
       </div>
 
       <div class="decision">
@@ -594,8 +594,8 @@
 
       <div class="decision">
         <div class="question">Was isolated work cut from scope?</div>
-        <div class="answer">Use a development backlog item. Link it back to the originating initiative.</div>
-        <div class="target"><code>Development/backlog/items/</code></div>
+        <div class="answer">Use a context backlog item. Link it back to the originating initiative.</div>
+        <div class="target"><code>context/backlog/items/</code></div>
       </div>
     </section>
 
@@ -605,7 +605,7 @@
         The same work can move through several containers as it becomes more
         concrete. Promotion is explicit and traceable.
       </p>
-      <div class="timeline" aria-label="Development lifecycle">
+      <div class="timeline" aria-label="Context lifecycle">
         <div class="step">
           <span class="step-number">1</span>
           <h3>Plan the arc</h3>
@@ -637,7 +637,7 @@
     <section id="delivery-surface">
       <h2>Delivery Surface</h2>
       <p class="section-intro">
-        Development context describes the whole delivery system, not only the
+        Working context describes the whole delivery system, not only the
         product code. The structure follows delivery concerns, not specific
         technologies or vendors.
       </p>
@@ -757,7 +757,7 @@
     <section id="release-transition">
       <h2>Release Transition</h2>
       <p class="section-intro">
-        Changing <code>Development/current.md</code> is a workflow. The agent
+        Changing <code>context/current.md</code> is a workflow. The agent
         should materialize planned work for the new current release.
       </p>
       <table class="matrix">
@@ -801,19 +801,19 @@
       <div class="grid two">
         <div class="tile">
           <h3>For vocabulary</h3>
-          <p><a href="terminology.md">Development/terminology.md</a></p>
+          <p><a href="terminology.md">context/terminology.md</a></p>
         </div>
         <div class="tile">
           <h3>For active release context</h3>
-          <p><a href="current.md">Development/current.md</a></p>
+          <p><a href="current.md">context/current.md</a></p>
         </div>
         <div class="tile">
           <h3>For release transitions</h3>
-          <p><a href="_templates/release-transition.md">Development/_templates/release-transition.md</a></p>
+          <p><a href="_templates/release-transition.md">context/_templates/release-transition.md</a></p>
         </div>
         <div class="tile">
           <h3>For agent behavior</h3>
-          <p><a href="../.agents/skills/development-initiative-context/SKILL.md">development-initiative-context skill</a></p>
+          <p><a href="../.agents/skills/code-anchored-context/SKILL.md">code-anchored-context skill</a></p>
         </div>
       </div>
     </section>
@@ -821,8 +821,8 @@
 
   <footer>
     <div class="wrap">
-      Static brief for the repository <code>Development/</code> context model.
-      Product documentation still lives under <code>Documentation/</code> and
+      Static brief for the repository <code>context/</code> context model.
+      Product documentation still lives under <code>docs/</code> and
       follows its own release refresh rules.
     </div>
   </footer>

package/{Development → context}/current.md

@@ -1,4 +1,4 @@
-# Current Development Context
+# Current Context
 
 Current release: `v0_1_0`
 
@@ -26,7 +26,7 @@ Registered initiatives:
 - `releases/v0_1_0/initiatives/npm-installer-cli/` - npm initializer for
   installing this context template into existing projects.
 
-To start an initiative, copy `Development/_templates/initiative/` into
-`Development/releases/v0_1_0/initiatives/<initiative-slug>/`, then update the
+To start an initiative, copy `context/_templates/initiative/` into
+`context/releases/v0_1_0/initiatives/<initiative-slug>/`, then update the
 copied `README.md` first so agents have a clear entry point before editing the
 supporting files.