code-anchored-context 0.2.2 → 0.2.4

package/.agents/skills/code-anchored-context/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-anchored-context
-description: Use central repository context for planning and implementation. Use when starting, changing, reviewing, or documenting behavior-changing work; when checking or updating context/current.md, context/releases/*/initiatives/*, context/programs/*, context/programs/*/planned-initiatives/*, context/backlog/items/*, specs, plans, interface notes, architecture notes, testing notes, delivery notes, infrastructure notes, actionable operations notes, ADRs, backlog, release-doc-notes.md; when promoting planned initiatives during release transitions; or when deciding whether product-docs/ should be left untouched.
+description: Use central repository context for planning and implementation. Use when starting, changing, reviewing, or documenting behavior-changing work; when checking or updating context/current.md, context/project-profile.md, context/releases/*/initiatives/*, context/programs/*, context/programs/*/planned-initiatives/*, context/backlog/items/*, specs, plans, interface notes, architecture notes, testing notes, delivery notes, infrastructure notes, actionable operations notes, ADRs, backlog, release-doc-notes.md; when promoting planned initiatives during release transitions; or when deciding whether reference/ should be left untouched.
 ---
 
 # Code-Anchored Context
@@ -16,6 +16,9 @@ Working context should also cover delivery concerns such as testing,
 delivery pipelines, and infrastructure when they affect how the work is
 verified, shipped, deployed, or hosted.
 
+Repo-specific stack and toolchain facts belong in
+`context/project-profile.md`, not in this reusable skill.
+
 ## Workflow
 
 ### 1) Read The Local Rules
@@ -32,6 +35,24 @@ Use `context/terminology.md` as the canonical vocabulary for programs,
 planned initiatives, release initiatives, backlog items, statuses, and
 promotion.
 
+Open `context/project-profile.md` when it exists. It is the repo-wide
+operating profile for stack, commands, source roots, verification layers,
+CI/CD, delivery automation, infrastructure, observability, and generated
+artifacts. Use it before inventing default commands or tooling assumptions.
+
+If a human explicitly asks for a project profile, tech-stack baseline, or
+repository operating baseline, create or refresh `context/project-profile.md`
+by inspecting source-backed local facts: manifests, lockfiles, runtime version
+files, build config, test config, CI/CD workflows, deployment scripts,
+infrastructure config, observability config, generated-artifact owners, and
+existing docs. Do not guess. Mark unknowns clearly and cite source paths where
+useful.
+
+If the human asks for a "baseline" without saying whether they mean an
+operating profile or accepted behavior reference, distinguish
+`context/project-profile.md` from baseline reference under `reference/` before
+editing.
+
 If the workspace starts inside a subfolder, navigate upward to the repository
 root when the environment allows it. If `context/` is not available in
 the workspace, mention that limitation in the task summary.
@@ -50,6 +71,9 @@ Search for:
 - the feature or bug name
 - affected concern names, such as product code, APIs, contracts, tests,
   delivery, CI/CD, infrastructure, config, generated artifacts, or automation
+- repo-wide toolchain facts from `context/project-profile.md`, such as test
+  commands, e2e tooling, observability tooling, deploy CLIs, source roots,
+  generated artifacts, or CI/CD files
 - related domain terms, APIs, jobs, entities, routes, config names, or tickets
 
 Use an existing initiative when the work belongs to it, even if the code
@@ -59,8 +83,8 @@ effort, link it to the relevant program.
 ### 4) Create An Initiative When Needed
 
 Create a new initiative for non-trivial behavior changes, cross-project
-work, release-significant work, or anything likely to need future product
-documentation.
+work, release-significant work, or anything likely to need future reference
+updates.
 
 Use `context/_templates/initiative/` as the source. Copy it to:
 
@@ -164,7 +188,10 @@ Use these files as the standard map:
   observability, failure modes, rollback, repair, and support tooling
 - `backlog.md`: work slices and implementation progress
 - `decisions/ADR-*.md`: meaningful choices and their consequences
-- `release-doc-notes.md`: product-documentation impact to review at release
+- `release-doc-notes.md`: reference impact to review at release
+- `context/project-profile.md`: repo-wide stack, command, testing, delivery,
+  infrastructure, observability, and generated-artifact facts; update it only
+  for stable source-backed discoveries or an explicit baseline request
 
 Not every initiative needs every file. Mark a file as not applicable or omit
 it after copying the template when it genuinely does not apply.
@@ -175,15 +202,14 @@ settled truth lives. Promote stable conclusions into `spec.md`,
 `infrastructure.md`, `operations.md` when actionable, `backlog.md`, ADRs, or
 `release-doc-notes.md` as appropriate.
 
-### 9) Preserve The Product Docs Boundary
+### 9) Preserve The Reference Boundary
 
-Do not edit `product-docs/` as part of normal feature work, bug fixes,
+Do not edit `reference/` as part of normal feature work, bug fixes,
 refactors, or planning. Instead, update the initiative's
 `release-doc-notes.md`.
 
-Only update `product-docs/` when a human explicitly asks for release
-documentation work, a specific page update, or a demonstrable documentation
-fix.
+Only update `reference/` when a human explicitly asks for release reference
+work, a specific page update, or a demonstrable reference fix.
 
 ## Knowledge Ownership
 
@@ -198,6 +224,9 @@ folder. Do not create area-local copies of initiative documents.
 Before finishing behavior-changing work:
 
 - The matching initiative was read or a reason was given for why none exists.
+- `context/project-profile.md` was read when present and relevant to
+  verification, delivery, infrastructure, operations, or generated artifacts;
+  if a human requested a baseline, it was populated from source-backed facts.
 - Matching programs or context backlog items were checked when the work
   appears phased, deferred, or multi-release.
 - Planned initiatives were checked or created when future program scope is
@@ -205,5 +234,5 @@ Before finishing behavior-changing work:
 - Any changed behavior, interface, architecture, testing, delivery,
   infrastructure, actionable operations, or backlog state was reflected in the
   initiative when appropriate.
-- Future product-documentation impact was captured in `release-doc-notes.md`.
-- `product-docs/` was left untouched unless explicitly requested.
+- Future reference impact was captured in `release-doc-notes.md`.
+- `reference/` was left untouched unless explicitly requested.

package/AGENTS.md

@@ -8,27 +8,30 @@ subfolders layer on top of it. Read those too when working in a given area.
 In-progress specs, plans, ADRs, backlog, implementation context, and
 release-documentation notes live under [`context/`](context/).
 Start with [`context/current.md`](context/current.md).
+Use [`context/project-profile.md`](context/project-profile.md) for
+repo-wide stack, command, testing, delivery, infrastructure, observability,
+and generated-artifact facts when it has been populated.
 
 For behavior-changing work, use the repo-wide skill at
 [`.agents/skills/code-anchored-context/SKILL.md`](.agents/skills/code-anchored-context/SKILL.md).
 Keep initiative knowledge centralized under `context/`; area
 `AGENTS.md` files should point there rather than copying active plans.
 
-## Product Docs Authoring
+## Reference Authoring
 
-### When To Edit `product-docs/`
+### When To Edit `reference/`
 
-Do not edit `product-docs/` as a side effect of feature work, bug fixes,
-refactors, or other code changes. Product docs in this model are
+Do not edit `reference/` as a side effect of feature work, bug fixes,
+refactors, or other code changes. Reference material in this model is
 release-anchored:
 they describe the behavior of a specific release tag, not the partial state of
 a working branch.
 
-Touch `product-docs/` only when:
+Touch `reference/` only when:
 
-- A human explicitly asks you to refresh product docs for a release, typically
+- A human explicitly asks you to refresh reference for a release, typically
   after a release tag is cut and QA has signed off.
-- A human explicitly asks you to create or refresh baseline documentation for
+- A human explicitly asks you to create or refresh baseline reference for
   an existing project.
 - A human explicitly asks you to update a specific page.
 - A human asks you to fix a demonstrable error in an existing page, such as a
@@ -36,20 +39,20 @@ Touch `product-docs/` only when:
 
 If you are unsure whether the request is one of these, ask before editing.
 
-If a project has documentation that intentionally follows a different cadence,
+If a project has reference material that intentionally follows a different cadence,
 document that exception in the area's README and in
-`product-docs/_authoring/areas/`.
+`reference/_authoring/areas/`.
 
 ### Where The Authoring Guidance Lives
 
-All documentation workflow, per-area authoring guides, and domain terminology
-live under [`product-docs/_authoring/`](product-docs/_authoring/). Start
-with [`product-docs/_authoring/README.md`](product-docs/_authoring/README.md).
+All reference workflow, per-area authoring guides, and domain terminology
+live under [`reference/_authoring/`](reference/_authoring/). Start
+with [`reference/_authoring/README.md`](reference/_authoring/README.md).
 
-If you are refreshing product docs, the per-area guides in
-[`product-docs/_authoring/areas/`](product-docs/_authoring/areas/) tell you
+If you are refreshing reference, the per-area guides in
+[`reference/_authoring/areas/`](reference/_authoring/areas/) tell you
 what matters and what to ignore for each area.
 
 `AGENTS.md` files stay lean. They are for coding conventions and agent
-restrictions, not detailed documentation guidance. If you have doc rules to
+restrictions, not detailed reference guidance. If you have reference rules to
 add, add them under `_authoring/`.

package/README.md

@@ -1,15 +1,15 @@
 # Code-Anchored Context Template
 
 This repository is a reusable starting point for keeping repository-local
-working context and release-anchored product documentation close to the
+working context and release-anchored reference close to the
 code they describe.
 
 It separates two kinds of truth:
 
 | Folder | Meaning | Updated when |
 | --- | --- | --- |
-| `context/` | What the team is planning, building, deciding, validating, shipping, hosting, deferring, and learning. | During normal development. |
-| `product-docs/` | What the product does as of a known release or tag. | Only during explicit documentation refresh work. |
+| `context/` | What the team is planning, building, deciding, validating, shipping, hosting, deferring, and learning, plus optional repo-wide operating facts in `project-profile.md`. | During normal development. |
+| `reference/` | What the system does as of a known release or explicit baseline. | Only during explicit reference refresh work. |
 
 The goal is to give humans and AI agents enough structured context to change a
 codebase without relying on chat history, tribal memory, or scattered planning
@@ -21,8 +21,9 @@ notes.
 - `.agents/skills/code-anchored-context/SKILL.md` for the recurring
   working-context workflow.
 - `context/` with terminology, release context, backlog/program structure,
-  initiative templates, and release-documentation notes.
-- `product-docs/` with a generic release-anchored documentation workflow,
+  a repo-wide project profile starter, initiative templates, and
+  release-documentation notes.
+- `reference/` with a generic release-anchored reference workflow,
   authoring guide structure, and area/page templates.
 
 ## Adopting This In A Project
@@ -39,7 +40,7 @@ Useful options:
 
 ```bash
 npx code-anchored-context init --dry-run
-npx code-anchored-context init --no-product-docs
+npx code-anchored-context init --no-reference
 npx code-anchored-context init --target ../existing-project
 ```
 
@@ -54,10 +55,13 @@ Manual adoption still works:
 2. Replace `PROJECT_NAME` placeholders with the project name.
 3. Set the first active release in `context/current.md`.
 4. Add or revise area-specific `AGENTS.md` files so they point back to
-   `context/` and `product-docs/_authoring/`.
-5. Create `product-docs/_authoring/areas/<area>.md` for each documented
+   `context/` and `reference/_authoring/`.
+5. If you want a repo operating profile, ask an agent to populate
+   `context/project-profile.md` from source files, manifests, CI/CD,
+   infrastructure, test config, and observability tooling.
+6. Create `reference/_authoring/areas/<area>.md` for each referenced
    product or code area.
-6. Keep product or domain-specific documentation out of this template repo.
+7. Keep product or domain-specific reference content out of this template repo.
 
 ## Publishing The Package
 
@@ -78,8 +82,8 @@ npx @your-scope/code-anchored-context init
 
 ## Working Rule
 
-Working context can evolve with the branch. Product docs should
+Working context can evolve with the branch. Reference material should
 stay stable and release-accurate. When behavior changes during development,
-record future documentation impact in the relevant initiative's
-`release-doc-notes.md`; refresh `product-docs/` only when that work is
+record future reference impact in the relevant initiative's
+`release-doc-notes.md`; refresh `reference/` only when that work is
 explicitly requested.

package/bin/code-anchored-context.js

@@ -54,7 +54,7 @@ async function main() {
     dryRun: args.dryRun
   });
 
-  await installer.init({ includeProductDocs: args.productDocs });
+  await installer.init({ includeReference: args.reference });
 }
 
 function parseArgs(argv) {
@@ -65,7 +65,7 @@ function parseArgs(argv) {
     release: defaultRelease,
     force: false,
     dryRun: false,
-    productDocs: true,
+    reference: true,
     help: false,
     version: false
   };
@@ -95,8 +95,8 @@ function parseArgs(argv) {
       continue;
     }
 
-    if (arg === '--no-product-docs' || arg === '--no-docs') {
-      options.productDocs = false;
+    if (arg === '--no-reference') {
+      options.reference = false;
       continue;
     }
 
@@ -170,8 +170,7 @@ Options:
   --target <path>          Project root to install into. Defaults to cwd.
   --project-name <name>   Name used to replace PROJECT_NAME placeholders.
   --release <slug>        Initial release slug. Defaults to ${defaultRelease}.
-  --no-product-docs       Skip the product-docs/ starter files.
-  --no-docs               Alias for --no-product-docs.
+  --no-reference          Skip the reference/ starter files.
   --force                 Replace existing generated directories.
   --dry-run               Show planned changes without writing files.
   -h, --help              Show help.
@@ -179,7 +178,7 @@ Options:
 
 Examples:
   npx code-anchored-context init --project-name "My App"
-  npx code-anchored-context init --release v1_0_0 --no-product-docs
+  npx code-anchored-context init --release v1_0_0 --no-reference
 `);
 }
 
@@ -216,7 +215,7 @@ class Installer {
     this.agentsFilePath = path.join(targetRoot, 'AGENTS.md');
   }
 
-  async init({ includeProductDocs }) {
+  async init({ includeReference }) {
     await this.ensureDirectory(this.targetRoot);
 
     await this.installAgentsFile();
@@ -224,10 +223,10 @@ class Installer {
     await this.copyTemplatePath('context', 'context');
     await this.renameReleasePaths();
 
-    if (includeProductDocs) {
-      await this.copyTemplatePath('product-docs', 'product-docs');
+    if (includeReference) {
+      await this.copyTemplatePath('reference', 'reference');
     } else {
-      this.note('skip product-docs/ (--no-product-docs)');
+      this.note('skip reference/ (--no-reference)');
     }
 
     this.printSummary();
@@ -305,6 +304,9 @@ class Installer {
 In-progress specs, plans, ADRs, backlog, implementation context, and
 release-documentation notes live under [\`context/\`](context/).
 Start with [\`context/current.md\`](context/current.md).
+Use [\`context/project-profile.md\`](context/project-profile.md) for
+repo-wide stack, command, testing, delivery, infrastructure, observability,
+and generated-artifact facts when it has been populated.
 
 For behavior-changing work, use the repo-wide skill at
 [\`.agents/skills/${skillName}/SKILL.md\`](.agents/skills/${skillName}/SKILL.md).
@@ -487,6 +489,10 @@ Start here:
 - \`releases/${this.release}/backlog.md\`
 - \`releases/${this.release}/initiatives/\`
 
+Project-wide operating profile:
+
+- \`project-profile.md\`
+
 Durable or deferred context:
 
 - \`programs/\`

package/context/AGENTS.md

@@ -7,6 +7,9 @@ Scope: everything under `/context`.
 This folder is the canonical home for in-progress working context: specs,
 interface notes, architecture notes, actionable operations notes, ADRs,
 backlogs, implementation plans, and release-documentation notes.
+`project-profile.md` is the canonical home for repo-wide operating facts such
+as stack, commands, test layers, CI/CD, infrastructure, observability, and
+generated artifacts when a baseline has been populated.
 
 Testing, delivery, and infrastructure notes belong here when they affect how
 work is verified, shipped, deployed, or hosted. Operational notes belong here
@@ -14,17 +17,20 @@ only when they are actionable runtime, support, observability, rollback, or
 repair context.
 
 `context/` describes what is being planned, built, debated, or validated.
-`product-docs/` describes what has shipped for a release.
+`reference/` describes what has shipped for a release.
 
 ## Editing Rules
 
 - Use `context/terminology.md` as the canonical vocabulary for programs,
   planned initiatives, release initiatives, backlog items, and promotion.
+- Use `context/project-profile.md` for stable repo-wide operating facts.
+  Populate it only from source-backed discovery or an explicit human request
+  for a repository baseline.
 - Keep initiative knowledge centralized here. Area `AGENTS.md` files may point
   here, but they should not duplicate initiative content.
-- Do not move in-progress plans into `product-docs/`.
+- Do not move in-progress plans into `reference/`.
 - Use `release-doc-notes.md` inside an initiative to capture what may need to
-  become product documentation later.
+  become reference later.
 - Create initiatives from `context/_templates/initiative/`.
 - Create durable multi-release programs from `context/_templates/program/`.
 - Create scoped future program work from

package/context/README.md

@@ -6,12 +6,18 @@ repository.
 Use it for specs, interface notes, architecture notes, testing notes, delivery
 notes, infrastructure notes, actionable operations notes, ADRs, backlog items,
 implementation plans, and release-documentation notes. Do not use
-`product-docs/` for in-progress development planning.
+`reference/` for in-progress development planning.
+
+Use `project-profile.md` for repo-wide operating facts such as stack,
+commands, verification layers, CI/CD, infrastructure, observability, and
+generated artifacts.
 
 ## Start Here
 
 - `terminology.md` defines the shared vocabulary.
 - `current.md` points to the active release context.
+- `project-profile.md` captures repo-wide stack, command, testing, delivery,
+  infrastructure, operations, and generated-artifact facts when populated.
 - `programs/` contains durable multi-release working context.
 - `backlog/` contains deferred isolated work cut from initiatives.
 - `releases/` contains release-scoped working context.
@@ -20,17 +26,17 @@ implementation plans, and release-documentation notes. Do not use
   shape for scoped program work outside the current release.
 - `_templates/release-context/` contains the standard release folder shell.
 
-## Relationship To product-docs/
+## Relationship To reference/
 
-`context/` and `product-docs/` serve different jobs:
+`context/` and `reference/` serve different jobs:
 
 | Folder | Meaning | Updated when |
 | --- | --- | --- |
 | `context/` | What we are planning, building, deciding, or validating. | During normal development. |
-| `product-docs/` | What the product does as of a release or tag. | Only during explicit documentation refresh work. |
+| `reference/` | What the system does as of a release, tag, or explicit baseline. | Only during explicit reference refresh work. |
 
-Working context can feed release documentation, but it is not product
-documentation. Capture that bridge in each initiative's
+Working context can feed release reference, but it is not accepted
+reference. Capture that bridge in each initiative's
 `release-doc-notes.md`.
 
 ## Core Model
@@ -63,6 +69,9 @@ The delivery-surface rule is:
 
 Use `testing.md`, `delivery.md`, and `infrastructure.md` for concern-based
 context. Mention specific tools inside those files only when the tools matter.
+Use `project-profile.md` for repo-wide defaults such as package manager,
+common commands, test tools, delivery automation, infrastructure tooling, and
+observability entry points.
 
 Mermaid diagrams are encouraged for flows, dependencies, and lifecycle maps
 because they stay readable as Markdown for agents while rendering as visible
@@ -80,6 +89,7 @@ not copy specs, plans, or ADRs into area-local documents.
 ```text
 context/
   current.md
+  project-profile.md
   programs/
     <program-slug>/
       README.md
@@ -120,6 +130,27 @@ context/
           brief.html
 ```
 
+## Project Profile
+
+`project-profile.md` is the optional repo-wide operating profile. It answers
+questions future agents routinely need before changing behavior:
+
+- where code, tests, config, infrastructure, generated artifacts, and
+  reference material live
+- which runtime, package manager, frameworks, services, and hosting platform
+  the project uses
+- which commands verify, build, package, run, deploy, or release the project
+- which CI/CD, IaC, observability, support, rollback, and repair tools matter
+
+Populate it when a human asks for a project profile, tech-stack baseline, or
+repository operating baseline, or when a concrete repo-wide fact is discovered
+during work. Do not guess. Mark unknowns explicitly and cite source paths
+where possible.
+
+Initiatives can rely on the project profile for stable defaults. Put only the
+initiative-specific changes, exceptions, and release gates in the initiative's
+`testing.md`, `delivery.md`, `infrastructure.md`, or `operations.md`.
+
 ## Programs
 
 Programs preserve durable context for work that spans releases or phases. Use a
@@ -190,7 +221,7 @@ Required for most initiatives:
 | `plan.md` | Working alignment space for humans and agents; rough notes, questions, options, and points to promote. |
 | `spec.md` | What the system should do and which behavior is in or out. |
 | `backlog.md` | What is changing now, sliced into trackable work. |
-| `release-doc-notes.md` | Product documentation impact to review at release time. |
+| `release-doc-notes.md` | Reference impact to review at release time. |
 
 Use when relevant:
 
@@ -246,8 +277,8 @@ When changing behavior, agents should:
    behavior changes that do not belong to an existing initiative.
 7. Create or update a program planned initiative when future scoped work is
    clear but belongs outside the current release.
-8. Record future product-doc impact in `release-doc-notes.md`, not in
-   `product-docs/`, unless a human explicitly asks for documentation refresh.
+8. Record future reference impact in `release-doc-notes.md`, not in
+   `reference/`, unless a human explicitly asks for reference refresh.
 
 The key rule for planning is:
 

package/context/_templates/initiative/README.md

@@ -17,7 +17,9 @@ produce.
 - Tests or verification: `path/to/...`
 - Delivery, CI/CD, build, or artifacts: `path/to/...`
 - Infrastructure, IaC, or environment config: `path/to/...`
-- Product docs or release notes: `path/to/...`
+- Repo-wide operating profile: `context/project-profile.md` if a stable
+  project fact changes
+- Reference or release notes: `path/to/...`
 
 Remove entries that do not apply and add the real paths. Prefer naming the
 delivery concern over assuming a specific folder layout.
@@ -59,5 +61,5 @@ support, observability, rollback, or repair context.
   Promote settled conclusions into the stable initiative files.
 - Update `release-doc-notes.md` when shipped behavior or product-facing
   behavior changes.
-- Do not update `product-docs/` from this initiative unless a human
-  explicitly asks for release documentation work.
+- Do not update `reference/` from this initiative unless a human
+  explicitly asks for release reference work.

package/context/_templates/initiative/delivery.md

@@ -5,6 +5,10 @@ Name the concern, not the tool. Pipeline definitions, workflow files,
 deployment scripts, release toggles, and gates can all appear here when
 relevant.
 
+Start from `context/project-profile.md` for repo-wide delivery defaults.
+Capture only initiative-specific pipeline, build, deployment, artifact, or
+release changes here.
+
 ## Pipeline Impact
 
 Describe pipeline, workflow, build, packaging, or artifact changes.

package/context/_templates/initiative/infrastructure.md

@@ -4,6 +4,10 @@ Use this file for environment shape and infrastructure dependencies. Name the
 concern, not the tool. Infrastructure modules, resource templates, manifests,
 or manual environment steps can all appear here when relevant.
 
+Start from `context/project-profile.md` for repo-wide infrastructure and
+configuration defaults. Capture only initiative-specific environment, IaC,
+resource, secret, or migration changes here.
+
 ## Environment Shape
 
 Describe new or changed resources, services, networks, identity boundaries,

package/context/_templates/initiative/operations.md

@@ -7,6 +7,10 @@ If there is nothing concrete for an agent or engineer to act on, omit this
 file after copying the template or mark it as not applicable. Delivery belongs
 in `delivery.md`; environment shape and IaC belong in `infrastructure.md`.
 
+Start from `context/project-profile.md` for repo-wide observability, support,
+rollback, and repair entry points. Capture only initiative-specific actionable
+runtime or support changes here.
+
 ## Runtime Behavior
 
 Describe how the live system behaves after the initiative ships, especially

package/context/_templates/initiative/plan.md

@@ -18,7 +18,7 @@ initiative files:
   repair notes
 - `backlog.md` for executable work items
 - `decisions/ADR-*.md` for durable decisions
-- `release-doc-notes.md` for future product-documentation impact
+- `release-doc-notes.md` for future reference impact
 
 ## Current Alignment
 
@@ -54,4 +54,4 @@ the canonical initiative files.
 - [ ] Move multi-release context into `context/programs/`
 - [ ] Move isolated deferred work into `context/backlog/items/`
 - [ ] Move durable decisions into `decisions/`
-- [ ] Move product-documentation impact into `release-doc-notes.md`
+- [ ] Move reference impact into `release-doc-notes.md`

package/context/_templates/initiative/release-doc-notes.md

@@ -1,20 +1,20 @@
 # Release Doc Notes
 
-Use this file to capture product-documentation impact while development is
-in progress. At release time, these notes help refresh `product-docs/`
+Use this file to capture reference impact while development is
+in progress. At release time, these notes help refresh `reference/`
 against the final shipped behavior.
 
-Do not edit `product-docs/` from normal development work unless a human
-explicitly asks for a documentation refresh or a specific documentation fix.
+Do not edit `reference/` from normal development work unless a human
+explicitly asks for a reference refresh or a specific reference fix.
 
 ## Product Behavior Changes
 
 - None yet.
 
-## Candidate Product Docs Areas
+## Candidate Reference Areas
 
-- `product-docs/<Area>/README.md`
-- `product-docs/<Area>/features/<feature>.md`
+- `reference/<Area>/README.md`
+- `reference/<Area>/features/<feature>.md`
 
 ## QA Or Support Notes
 
@@ -29,6 +29,6 @@ ship.
 ## Release-Time Checklist
 
 - [ ] Compare this initiative against the final shipped code.
-- [ ] Update the relevant product documentation only after release-doc work
+- [ ] Update the relevant reference only after release-doc work
       is explicitly requested.
-- [ ] Add the release row if the documentation workflow requires it.
+- [ ] Add the release row if the reference workflow requires it.

package/context/_templates/initiative/testing.md

@@ -4,6 +4,10 @@ Use this file for the initiative's verification strategy. Name the concern,
 not the tool. Specific test runners, unit test frameworks, contract tests, or
 manual scripts can all appear here when they are relevant.
 
+Start from `context/project-profile.md` for repo-wide default commands and
+test tooling. Capture only initiative-specific additions, exceptions, data
+needs, or release gates here.
+
 ## Test Strategy
 
 Describe what must be proven before this initiative can ship.

package/context/_templates/planned-initiative/README.md

@@ -19,7 +19,9 @@ and what outcome it should produce.
 - Tests or verification: `path/to/...`
 - Delivery, CI/CD, build, or artifacts: `path/to/...`
 - Infrastructure, IaC, or environment config: `path/to/...`
-- Product docs or release notes: `path/to/...`
+- Repo-wide operating profile: `context/project-profile.md` if a stable
+  project fact is expected to change
+- Reference or release notes: `path/to/...`
 
 Remove entries that do not apply and add the real paths. Prefer naming the
 delivery concern over assuming a specific folder layout.

package/context/_templates/planned-initiative/delivery.md

@@ -3,6 +3,10 @@
 Use this file for future CI/CD, build, release, and environment-promotion
 behavior that is already clear enough to preserve.
 
+Start from `context/project-profile.md` for repo-wide delivery defaults.
+Capture only planned initiative-specific pipeline, build, deployment,
+artifact, or release changes here.
+
 ## Pipeline Impact
 
 Describe expected pipeline, workflow, build, packaging, or artifact changes.

package/context/_templates/planned-initiative/infrastructure.md

@@ -3,6 +3,10 @@
 Use this file for future environment shape and infrastructure dependencies
 that are already clear enough to preserve.
 
+Start from `context/project-profile.md` for repo-wide infrastructure and
+configuration defaults. Capture only planned initiative-specific environment,
+IaC, resource, secret, or migration changes here.
+
 ## Environment Shape
 
 Describe expected resources, services, networks, identity boundaries, storage,

package/context/_templates/planned-initiative/operations.md

@@ -8,6 +8,10 @@ If there is nothing concrete for an agent or engineer to act on, omit this
 file after copying the template or mark it as not applicable. Delivery belongs
 in `delivery.md`; environment shape and IaC belong in `infrastructure.md`.
 
+Start from `context/project-profile.md` for repo-wide observability, support,
+rollback, and repair entry points. Capture only planned initiative-specific
+actionable runtime or support changes here.
+
 ## Runtime Behavior
 
 Describe expected live-system behavior, especially jobs, schedules, queues,