code-anchored-context 0.2.2 → 0.2.4

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

@@ -37,4 +37,4 @@ Describe the current agreed future direction.
 - [ ] Move actionable runtime/support concerns into `operations.md`
 - [ ] Move executable future work into `backlog.md`
 - [ ] Move durable program decisions into the parent program's `decisions/`
-- [ ] Move product-documentation impact into `release-doc-notes.md`
+- [ ] Move reference impact into `release-doc-notes.md`

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

@@ -1,20 +1,20 @@
 # Release Doc Notes
 
-Use this file to capture expected product-documentation impact while future
+Use this file to capture expected reference 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 `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.
 
 ## Expected 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
 

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

@@ -3,6 +3,10 @@
 Use this file for future verification strategy that is already clear enough to
 preserve before the target release becomes current.
 
+Start from `context/project-profile.md` for repo-wide default commands and
+test tooling. Capture only planned initiative-specific additions, exceptions,
+data needs, or release gates here.
+
 ## Test Strategy
 
 Describe what the future release initiative will need to prove.

package/context/current.md

@@ -8,6 +8,10 @@ Start here:
 - `releases/v0_1_0/backlog.md`
 - `releases/v0_1_0/initiatives/`
 
+Project-wide operating profile:
+
+- `project-profile.md`
+
 Durable or deferred context:
 
 - `programs/`

package/context/project-profile.md

@@ -0,0 +1,130 @@
+# Project Profile
+
+Project: PROJECT_NAME
+Baseline status: Not populated yet.
+Last reviewed: Not recorded.
+
+This file captures repo-wide operating facts that agents should know before
+changing behavior. It is for stable project facts such as stack, source roots,
+commands, verification layers, delivery flow, infrastructure, observability,
+and generated artifacts.
+
+Do not put initiative-specific planning here. Use release initiatives under
+`context/releases/` for work-specific behavior, testing, delivery,
+infrastructure, and operations context.
+
+## When To Populate Or Refresh
+
+Populate or refresh this file when a human explicitly asks for a project
+profile, tech-stack baseline, or repository operating baseline, or when a
+concrete repo-wide fact is discovered during work and would help future
+agents.
+
+Record facts that can be traced to source files. Do not guess. If something is
+not known yet, mark it as `Unknown` and include the source paths that still
+need review.
+
+## Source Scan Checklist
+
+Use this checklist during a baseline pass:
+
+- package manifests, lockfiles, language/runtime version files, and build
+  config
+- source roots, application boundaries, libraries, services, APIs, jobs, and
+  generated artifacts
+- test configuration, e2e tooling, fixtures, seeded data, and test
+  environments
+- CI/CD workflows, deployment scripts, release toggles, artifact publishing,
+  and environment promotion
+- infrastructure as code, service configuration, secrets references, and
+  environment dependencies
+- observability, logs, metrics, traces, alerts, dashboards, support tools,
+  rollback, and repair procedures
+
+## Repository Shape
+
+| Concern | Location | Notes |
+| --- | --- | --- |
+| Application or package code | Unknown | TBD |
+| Tests | Unknown | TBD |
+| CI/CD and delivery | Unknown | TBD |
+| Infrastructure and config | Unknown | TBD |
+| Generated artifacts | Unknown | TBD |
+| Reference material | `reference/` | Release-anchored or baseline behavior. |
+| Working context | `context/` | Plans, initiatives, programs, ADRs, backlog, and release notes. |
+
+## Stack And Runtime
+
+| Layer | Technology | Source | Notes |
+| --- | --- | --- | --- |
+| Runtime or language | Unknown | TBD | TBD |
+| Package manager | Unknown | TBD | TBD |
+| Frameworks | Unknown | TBD | TBD |
+| Data stores or services | Unknown | TBD | TBD |
+| Hosting or runtime platform | Unknown | TBD | TBD |
+
+## Commands
+
+| Concern | Command | Source | Notes |
+| --- | --- | --- | --- |
+| Install dependencies | Unknown | TBD | TBD |
+| Run locally | Unknown | TBD | TBD |
+| Build | Unknown | TBD | TBD |
+| Lint, format, or typecheck | Unknown | TBD | TBD |
+| Unit or integration tests | Unknown | TBD | TBD |
+| E2E or smoke tests | Unknown | TBD | TBD |
+| Package or release | Unknown | TBD | TBD |
+
+## Verification Profile
+
+- Default test expectation: Unknown.
+- Required release gates: Unknown.
+- Manual checks: Unknown.
+- Test data and environment dependencies: Unknown.
+- Known verification gaps: Unknown.
+
+Use initiative `testing.md` files for work-specific additions, exceptions, and
+release gates.
+
+## Delivery Profile
+
+- CI/CD workflow files: Unknown.
+- Deployment entry points: Unknown.
+- Environments and promotion flow: Unknown.
+- Release approvals or gates: Unknown.
+- Artifacts and publishing flow: Unknown.
+- Delivery automation CLIs or scripts: Unknown.
+
+Use initiative `delivery.md` files for work-specific pipeline, build,
+deployment, or release changes.
+
+## Infrastructure And Configuration
+
+- IaC, manifests, or config roots: Unknown.
+- Managed services and resources: Unknown.
+- Secrets and configuration references: Unknown.
+- Environment dependencies: Unknown.
+- Compatibility or migration constraints: Unknown.
+
+Use initiative `infrastructure.md` files for work-specific environment or IaC
+changes.
+
+## Operations Profile
+
+- Logs: Unknown.
+- Metrics, traces, or dashboards: Unknown.
+- Alerts and health checks: Unknown.
+- Support tooling: Unknown.
+- Rollback, recovery, and repair tooling: Unknown.
+
+Use initiative `operations.md` files only for actionable runtime, support,
+observability, rollback, or repair concerns tied to a specific change.
+
+## Agent Notes
+
+- Keep this file factual and source-backed.
+- Prefer commands already defined by the repo over ad hoc alternatives.
+- Mention specific tools only when they affect how agents should verify,
+  ship, deploy, observe, or support the project.
+- If a generated file or managed artifact should not be edited directly,
+  record that here with the owning source location.

package/context/terminology.md

@@ -9,8 +9,9 @@ backlog items, ADRs, agent summaries, and release-transition work.
 | Term | Meaning |
 | --- | --- |
 | `context/` | Working context: plans, specs, ADRs, implementation notes, delivery-surface context, future scope, and release-documentation notes. |
-| `product-docs/` | Released product documentation. It describes shipped behavior for a release/tag and is not edited during normal development work. |
+| `reference/` | Accepted reference. It describes shipped or baseline behavior for a release/tag and is not edited during normal development work. |
 | `context/current.md` | Pointer to the current active release context. Updating this is a release transition. |
+| `context/project-profile.md` | Optional repo-wide operating profile for stack, commands, source roots, verification, delivery, infrastructure, observability, and generated artifacts. |
 | `context/releases/<version>/` | Release-scoped working context for one version. |
 | `context/programs/` | Durable multi-release working context. |
 | `context/backlog/items/` | Deferred isolated work cut from initiatives but worth preserving. |
@@ -44,6 +45,8 @@ scope and should be preserved, but it does not need program-level context.
 The structure follows delivery concerns, not technologies. Use concern names
 such as `testing.md`, `delivery.md`, and `infrastructure.md`; name specific
 tools inside those files only when the tools matter.
+Use `project-profile.md` for repo-wide defaults and toolchain facts, then use
+initiative files for work-specific changes and exceptions.
 
 Mermaid is the preferred diagram syntax for working context because it is
 both readable Markdown for agents and renderable visual context for humans.
@@ -51,6 +54,7 @@ both readable Markdown for agents and renderable visual context for humans.
 | Term | Meaning |
 | --- | --- |
 | `README.md` | Entry point for a folder. It should explain status, scope, links, and where to start. |
+| `project-profile.md` | Repo-wide operating profile. Populate it on human request or when source-backed facts are discovered during work. |
 | `plan.md` | Working alignment space for humans and agents. It may be messy, but settled truth must move into stable files. |
 | `spec.md` | Stable description of what the system should do. |
 | `interface.md` | Stable description of how humans, clients, APIs, config, reports, or tools interact with the work. |
@@ -60,7 +64,7 @@ both readable Markdown for agents and renderable visual context for humans.
 | `infrastructure.md` | Stable description of environment shape, IaC, resources, networking, identity, storage, secrets, and environment dependencies. |
 | `operations.md` | Optional actionable runtime support context: observability, failure modes, rollback, repair, support procedures, and tooling. |
 | `backlog.md` | Trackable work items for the containing initiative or program. |
-| `release-doc-notes.md` | Notes for future product documentation refresh work. This is the bridge to `product-docs/`. |
+| `release-doc-notes.md` | Notes for future reference refresh work. This is the bridge to `reference/`. |
 | ADR | Architecture Decision Record. Use for durable decisions and tradeoffs. |
 | `brief.html` | Optional human-friendly presentation layer. |
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "code-anchored-context",
-  "version": "0.2.2",
-  "description": "Install repo-local agent context, release initiatives, and release-anchored product-docs scaffolding into an existing project.",
+  "version": "0.2.4",
+  "description": "Install repo-local agent context, release initiatives, and release-anchored reference scaffolding into an existing project.",
   "license": "MIT",
   "type": "module",
   "bin": {
@@ -15,12 +15,13 @@
     "context/_templates/",
     "context/backlog/",
     "context/current.md",
+    "context/project-profile.md",
     "context/programs/",
     "context/releases/v0_1_0/README.md",
     "context/releases/v0_1_0/backlog.md",
     "context/releases/v0_1_0/initiatives/.gitkeep",
     "context/terminology.md",
-    "product-docs/",
+    "reference/",
     "bin/",
     "README.md",
     "LICENSE"
@@ -37,6 +38,6 @@
     "ai",
     "documentation",
     "working-context",
-    "product-docs"
+    "reference"
   ]
 }

package/{product-docs → reference}/README.md

@@ -1,24 +1,25 @@
-# Product Docs
+# Reference
 
-This folder holds release-anchored product documentation for PROJECT_NAME.
+This folder holds release-anchored reference material for PROJECT_NAME.
 
-Product docs describe shipped behavior for a known release, tag, or explicit
-baseline. They are not the place for in-progress planning, implementation
-notes, or draft architecture decisions. Put that work in `context/`.
+Reference describes accepted system behavior for a known release, tag, or
+explicit baseline. It is not the place for in-progress planning,
+implementation notes, or draft architecture decisions. Put that work in
+`context/`.
 
 ## Start Here
 
-- `releases/index.md` records release or baseline documentation refreshes.
-- `_authoring/README.md` explains how humans and agents should author product
-  docs.
-- `_authoring/workflow.md` defines when product docs are refreshed and what
+- `releases/index.md` records release or baseline reference refreshes.
+- `_authoring/README.md` explains how humans and agents should author
+  reference material.
+- `_authoring/workflow.md` defines when reference material is refreshed and what
   belongs here.
 - `_authoring/areas/` contains per-area authoring guidance.
 
 ## Standard Layout
 
 ```text
-product-docs/
+reference/
   README.md
   releases/
     index.md
@@ -43,13 +44,13 @@ Every documented area should have:
 
 - a high-level `README.md` that explains the area's purpose and architecture
 - one page per feature under `features/`
-- an authoring guide under `product-docs/_authoring/areas/`
+- an authoring guide under `reference/_authoring/areas/`
 
 ## Contributing
 
-- Refresh product docs only when explicitly asked.
-- For existing projects with little or no product documentation, create
-  baseline product docs only when explicitly asked; otherwise document touched
+- Refresh reference material only when explicitly asked.
+- For existing projects with little or no reference material, create
+  baseline reference only when explicitly asked; otherwise document touched
   behavior during future release refreshes.
 - Write for non-developer technical readers unless the project states
   otherwise.
@@ -58,4 +59,4 @@ Every documented area should have:
 - Describe behavior, inputs, outputs, permissions, errors, business rules, and
   operational expectations in domain language.
 - Prefer Mermaid diagrams for flows, architecture, and relationships.
-- Add release refreshes to `product-docs/releases/index.md`.
+- Add release refreshes to `reference/releases/index.md`.

package/{product-docs → reference}/_authoring/README.md

@@ -1,13 +1,13 @@
-# Product Docs Authoring Guide
+# Reference Authoring Guide
 
-This subtree owns all guidance for authoring and refreshing the documentation
-under `product-docs/`. Humans and agents both read from here to know how
-documentation is structured, when it is refreshed, what belongs in each area,
+This subtree owns all guidance for authoring and refreshing the reference
+under `reference/`. Humans and agents both read from here to know how
+reference is structured, when it is refreshed, what belongs in each area,
 and which domain terminology to use.
 
 ## Start Here
 
-- [`workflow.md`](workflow.md) explains how product docs are versioned,
+- [`workflow.md`](workflow.md) explains how reference is versioned,
   refreshed, and structured.
 - [`terminology.md`](terminology.md) holds project-specific domain language.
 - [`areas/`](areas/) contains one file per documented area, covering feature
@@ -18,14 +18,14 @@ and which domain terminology to use.
 Create one authoring guide per documented area:
 
 ```text
-product-docs/_authoring/areas/<area-slug>.md
+reference/_authoring/areas/<area-slug>.md
 ```
 
 Each area guide should identify:
 
 - the source locations that own the behavior, such as product code,
   interfaces, tests, CI/CD, generated artifacts, infrastructure, or config
-- the product docs root under `product-docs/`
+- the reference root under `reference/`
 - feature pages that should exist
 - behavior that matters at release time
 - changes to ignore, such as pure refactors or test-only edits
@@ -36,7 +36,7 @@ Use [`areas/_template.md`](areas/_template.md) when adding a new area guide.
 ## Relationship To `AGENTS.md`
 
 Area `AGENTS.md` files may point here, but they should not copy the detailed
-documentation workflow. Keep authoring rules in this subtree so the guidance
+reference workflow. Keep authoring rules in this subtree so the guidance
 has one source of truth.
 
 ## Contributing

package/{product-docs → reference}/_authoring/areas/README.md

@@ -5,10 +5,10 @@ This folder contains one authoring guide per documented area.
 Create a guide from `_template.md` when adding a documentation area:
 
 ```text
-product-docs/_authoring/areas/<area-slug>.md
+reference/_authoring/areas/<area-slug>.md
 ```
 
-Each guide should help a human or agent refresh product docs from a release diff
+Each guide should help a human or agent refresh reference from a release diff
 without rediscovering the area's structure from scratch.
 
 ## Current Area Guides

package/{product-docs → reference}/_authoring/areas/_template.md

@@ -4,7 +4,7 @@
 
 - Source orientation: `path/to/runtime-or-product-code`, `path/to/contracts`,
   `path/to/tests`, `path/to/ci-or-delivery`, `path/to/infra-or-config`
-- Product docs root: `product-docs/<Area>/`
+- Reference root: `reference/<Area>/`
 - Owner or reviewer: TBD
 
 Describe what this area owns and what it intentionally does not own.
@@ -18,9 +18,9 @@ operational expectations without private implementation detail.
 
 ## Feature Inventory
 
-| Feature | Product docs page | Notes |
+| Feature | Reference page | Notes |
 | --- | --- | --- |
-| TBD | `product-docs/<Area>/features/<feature>.md` | TBD |
+| TBD | `reference/<Area>/features/<feature>.md` | TBD |
 
 ## What Matters At Release Time
 
@@ -57,9 +57,9 @@ known gaps, and questions that should not yet appear in product-facing docs.
 
 ## Terminology
 
-List area-specific terms or link to `product-docs/_authoring/terminology.md`.
+List area-specific terms or link to `reference/_authoring/terminology.md`.
 
 ## Cross-Links
 
-List related areas and when product docs should cross-link instead of duplicating
+List related areas and when reference should cross-link instead of duplicating
 behavior.

package/{product-docs → reference}/_authoring/terminology.md

@@ -2,7 +2,7 @@
 
 Use this file to define the domain language that documentation should use.
 
-Product docs should translate code-level names into reader-facing domain
+Reference should translate code-level names into reader-facing domain
 terms when those differ. The goal is consistency for QA, product, support,
 operators, and future agents.
 

package/{product-docs → reference}/_authoring/workflow.md

@@ -1,86 +1,90 @@
-# Product Docs Workflow
+# Reference Workflow
 
-This file defines how documentation is versioned, refreshed, and structured
+This file defines how reference material is versioned, refreshed, and structured
 across the repo. It applies to all documented areas; area-specific guidance
 lives in [`areas/`](areas/).
 
-## When Product Docs Get Edited
+## When Reference Gets Edited
 
-Doc refresh is an explicit, on-request activity, not a side effect of code
-work. Humans or agents touch `product-docs/` only when:
+Reference refresh is an explicit, on-request activity, not a side effect of
+code work. Humans or agents touch `reference/` only when:
 
 - A human explicitly asks for a release-time refresh, typically after the
   release tag is cut and QA has signed off.
-- A human explicitly asks for baseline documentation for an existing project,
-  such as "document this repo baseline" or "create initial docs for the current
+- A human explicitly asks for baseline reference for an existing project, such
+  as "document this repo baseline" or "create initial reference for the current
   system."
 - A human explicitly asks to update a specific page.
 - A human asks to fix a demonstrable error in an existing page, such as a
   broken link or factual inaccuracy.
 
-Do not update product docs as part of a feature PR, bug fix, refactor, or
+Do not update reference as part of a feature PR, bug fix, refactor, or
 dependency bump. Mid-stream commits are partial work; "feature complete" is only
 well-defined once the release is accepted.
 
-Agents: if you are working on a code change and notice a doc that looks
+Agents: if you are working on a code change and notice reference material that looks
 outdated, leave it alone. Flag the staleness in your summary or add it to the
-initiative's `release-doc-notes.md`, but do not edit the doc as part of the
-current change unless explicitly asked.
+initiative's `release-doc-notes.md`, but do not edit the reference material as
+part of the current change unless explicitly asked.
 
-## Product Docs Modes
+## Reference Modes
 
-There are two valid ways to introduce or maintain `product-docs/`.
+There are two valid ways to introduce or maintain `reference/`.
 
-### Baseline Product Docs
+### Baseline Reference
 
 Use this mode only when a human explicitly asks to document the current system
 as a starting point. This is common when adopting the template in an existing
-project that has little or no product documentation.
+project that has little or no reference material.
 
 When creating a baseline:
 
 1. Confirm the scope: whole repo, one product area, one feature family, or one
    operational surface.
 2. Create or update the matching area guide under
-   `product-docs/_authoring/areas/` before writing product-facing pages.
+   `reference/_authoring/areas/` before writing reference pages.
 3. Document stable, currently accepted behavior from the current branch,
    current tag, or explicit reference point named by the human.
 4. Prefer broad, accurate coverage over exhaustive implementation detail.
-5. Record the baseline reference in `product-docs/releases/index.md`. If
+5. Record the baseline reference in `reference/releases/index.md`. If
    there is no release tag yet, use the commit, branch, date, or human-named
    baseline label that was used as the source.
-6. Leave uncertain or future behavior out of `product-docs/`. Capture open
+6. Leave uncertain or future behavior out of `reference/`. Capture open
    questions in `context/` or in the area authoring guide.
 
-Baseline product docs are a snapshot of the system as adopted; they are not a
+Baseline reference is a snapshot of the system as adopted; it is not a
 promise that every undocumented behavior is unimportant.
 
-### Release-Forward Product Docs
+This is different from `context/project-profile.md`, which captures the
+repo-wide operating profile: stack, commands, verification, delivery,
+infrastructure, observability, and generated-artifact facts.
+
+### Release-Forward Reference
 
 Use this mode when the team chooses not to create a full baseline. In this
-mode, `product-docs/` may start sparse. Agents capture documentation impact
-in initiative `release-doc-notes.md` during development, then update product
-product docs only at explicit release-refresh time.
+mode, `reference/` may start sparse. Agents capture reference impact in
+initiative `release-doc-notes.md` during development, then update reference
+only at explicit release-refresh time.
 
-This is valid when a full baseline would be too expensive. The documentation
+This is valid when a full baseline would be too expensive. The reference
 becomes complete incrementally around behavior the team changes and releases.
 
 ## Cadence And Versioning
 
-Product docs live under `product-docs/`. After any explicit baseline pass,
-they are refreshed once per release, at git-tag time, after release acceptance.
-Product docs are anchored to the release tag; product docs at tag
-`release/v1_2_3` describe the behavior of that release.
+Reference lives under `reference/`. After any explicit baseline pass, it is
+refreshed once per release, at git-tag time, after release acceptance.
+Reference is anchored to the release tag; reference at tag `release/v1_2_3`
+describes the behavior of that release.
 
 Default tag names follow the convention `release/vMAJOR_MINOR_PATCH` and match
 the release branch name. If a project uses a different release convention,
 document it here before the first refresh. If the first documentation pass is
 a baseline without a tag, record the baseline reference in
-`product-docs/releases/index.md`.
+`reference/releases/index.md`.
 
 ## Audience
 
-Product docs are written for non-developer technical readers by default: QA,
+Reference is written for non-developer technical readers by default: QA,
 product owners, solution owners, support engineers, customer engineers, or
 operators. Adjust this only when the project explicitly defines a different
 audience.
@@ -89,7 +93,7 @@ audience.
   business rules in domain language.
 - Avoid code snippets, private type names, SQL, and framework jargon unless
   the concept has no plain-language equivalent.
-- For readers who need more depth than the product docs provide, link to the
+- For readers who need more depth than the reference provides, link to the
   source rather than replicating the implementation in prose.
 
 ## Writing Focus
@@ -101,10 +105,10 @@ or business process can observe. Add technical detail only when it affects
 released behavior, configuration, permissions, data, integrations, errors,
 support, operations, or auditability.
 
-Product docs should be product-readable first and technically anchored
-second. They can feed release notes, but they are more durable than release
-notes: release notes summarize what changed, while `product-docs/` describes
-what the accepted system does as of a release or baseline.
+Reference should be product-readable first and technically anchored second. It
+can feed release notes, but it is more durable than release notes: release
+notes summarize what changed, while `reference/` describes what the accepted
+system does as of a release or baseline.
 
 Use progressive depth:
 
@@ -128,7 +132,7 @@ Every documented area has two layers:
 Standard per-area layout:
 
 ```text
-product-docs/<Area>/
+reference/<Area>/
   README.md
   features/
     <feature>.md
@@ -159,29 +163,29 @@ Preferred diagram types:
 Keep diagrams small enough to read. If a diagram needs more than about 15 nodes
 or steps, simplify it or split it.
 
-## Feature Docs Cover The Full Vertical
+## Feature Reference Covers The Full Vertical
 
-A feature doc should describe the full behavior path the feature touches:
+A feature reference page should describe the full behavior path the feature touches:
 entry point, important services or processes, data stored or read, external
 systems, permissions, validation, errors, and operational expectations.
 
-If a feature spans multiple areas, place the doc in the area that owns the
+If a feature spans multiple areas, place the page in the area that owns the
 user-facing or operator-facing entry point. Cross-link from the other areas.
 
-## Release-Time Doc Refresh
+## Release-Time Reference Refresh
 
-When invoked to refresh product docs for a release:
+When invoked to refresh reference for a release:
 
 1. Work from the diff `<previous-release-tag>..HEAD`, scoped to one area at a
    time.
-2. Read the matching area guide in `product-docs/_authoring/areas/`.
+2. Read the matching area guide in `reference/_authoring/areas/`.
 3. Read relevant initiative `release-doc-notes.md` files under
    `context/releases/<release>/initiatives/`.
 4. Update the area's `README.md` if the high-level picture changed.
 5. Update feature pages for behavior that changed.
 6. Ignore pure refactors, internal renames, test-only changes, formatting,
    lint fixes, and dependency bumps with no behavior change.
-7. Append one row to `product-docs/releases/index.md`.
+7. Append one row to `reference/releases/index.md`.
 
 ## Source Order
 
@@ -190,12 +194,12 @@ source inspection:
 
 1. Previous release tag to current release diff.
 2. Relevant initiative `release-doc-notes.md` files.
-3. Matching area guide under `product-docs/_authoring/areas/`.
-4. Existing product documentation.
+3. Matching area guide under `reference/_authoring/areas/`.
+4. Existing reference.
 5. Source code, tests, config, CI/CD, infrastructure, and generated artifacts
    only as needed to verify shipped behavior.
 
-For baseline documentation, start from the explicit baseline scope and
+For baseline reference, start from the explicit baseline scope and
 reference point named by the human. If no reference is named, use the current
 working tree and say so in the release index row.
 

package/{product-docs → reference}/releases/index.md

@@ -1,9 +1,9 @@
-# Product Docs Release Index
+# Reference Release Index
 
 One row per tagged release. Tag names default to `release/vMAJOR_MINOR_PATCH`
 unless the project documents a different convention.
 
-Product docs at a given tag describe the behavior of that release.
+Reference at a given tag describes the behavior of that release.
 
 | Tag | Date | Areas refreshed | Owner | Summary |
 | --- | --- | --- | --- | --- |