docs(references): add sensitive write boundary for project-control surfaces

Add references/project-harness/sensitive-write-boundary.md, a pre-write
approval gate requiring explicit, current, scoped user confirmation
before an AI coding agent writes to project-control surfaces: repo root
files, config/, docs/, tools/, scripts/, hooks/, CI/CD, and
migration/schema paths. The boundary acts before a diff exists and
complements sensitive-code.md, which classifies risky content after.

Register the doc in the Project Harness domain README under Owns and
Read Next. Docs-only change; no scripts, fixtures, or graph
regeneration needed since the doc is outside the skill routing chain.

Validated with node --test test/doc-link-graph.test.mjs (6/6 pass) and
the docs-relevant suite subset (32/32 pass).

Author: 东夷

references/project-harness/README.md

@@ -31,6 +31,8 @@ acceptance, change safeguards, and recovery boundaries.
   applicability, and validation evidence.
 - `review-trigger.md`: recommendation and review-trigger policy.
 - `sensitive-code.md`: sensitive-code review and reporting boundaries.
+- `sensitive-write-boundary.md`: pre-write confirmation gate for
+  project-control surfaces.
 
 ## Does Not Own
 
@@ -52,4 +54,6 @@ acceptance, change safeguards, and recovery boundaries.
 - Use `friendly-cli.md` for command interface design.
 - Use `recovery-evidence.md` for rollback and recovery inspection.
 - Use `sensitive-code.md` for sensitive-code review boundaries.
+- Use `sensitive-write-boundary.md` for pre-write confirmation on
+  project-control surfaces.
 - Use `git-hooks.md` for Git hook lifecycle placement and evidence.

references/project-harness/sensitive-write-boundary.md

@@ -0,0 +1,86 @@
+# Sensitive Write Boundary
+
+## Purpose
+
+Sensitive Write Boundary defines the project-control surfaces an AI coding
+agent must not create, edit, move, or delete without explicit user confirmation
+in the current task.
+
+It is a pre-write approval gate, not a diff-review checklist:
+
+```text
+planned write -> protected-surface match -> explicit confirmation -> scoped write -> evidence
+```
+
+`sensitive-code.md` classifies risky content after a diff exists. This boundary
+acts earlier: it stops an unconfirmed write to a project-control surface before
+the diff is created.
+
+## Protected Surfaces
+
+Trigger before any write whose target path matches one of these surfaces:
+
+| Surface | Typical paths | Why it is protected |
+| --- | --- | --- |
+| Repository root files | `README.md`, `AGENTS.md`, `LICENSE`, `package.json`, lockfiles, dotfiles such as `.gitignore` or `.editorconfig` | They define project identity, agent behavior, and dependency contracts for every consumer. |
+| Configuration | `config/`, linter and compiler configs, environment templates | One edit silently changes behavior for all builds, tools, and agents. |
+| Documentation contracts | `docs/`, ADRs, specs, published architecture | They are the reviewed source of truth other work is validated against. |
+| Shared automation | `tools/`, `scripts/` | Other workflows, hooks, and CI jobs execute these paths. |
+| Hook lifecycle | `hooks/`, Git hook wiring, agent hook definitions | Hooks run automatically and can block or bypass safeguards. |
+| CI/CD and release | `.github/workflows/`, pipelines, release and install scripts | Supply-chain and release paths execute with elevated trust. |
+| Migration and schema | database migrations, schema definitions, seed data | Effects persist in data and are hard or impossible to roll back. |
+
+Projects may extend this table with their own control surfaces. Keep the
+project-specific path list in project policy or analyzer config; this document
+owns the boundary rule, not the path inventory.
+
+## Confirmation Rules
+
+1. Match the target path against the protected surfaces before writing, not
+   after the diff exists.
+2. Confirmation must be explicit, current, and scoped: the user names the
+   surface or file, the intended change, and the expected effect. Silence,
+   topic similarity, or a generic "go ahead" from an earlier task does not
+   qualify.
+3. Approval does not carry over. One confirmation covers one described write
+   set; a new task, session, or additional surface needs fresh confirmation.
+4. A task instruction authorizes a protected write only when it names the
+   surface. "Fix the failing tests" does not authorize editing a CI workflow;
+   "update `.github/workflows/ci.yml` to fix the failing job" does.
+5. Without confirmation, the agent proposes instead of writing: target paths,
+   a change summary, the reason, and the expected effect, then waits. If the
+   change can live outside a protected surface, route it there instead.
+6. Never batch a protected write silently inside a broader change. Surface it
+   as its own confirmation item even when the rest of the change is approved.
+
+## Required Evidence
+
+For every write to a protected surface, record:
+
+- target path and matched surface category
+- confirmation source: the user message or instruction that named the surface
+- change summary and expected effect
+- validation command or test run after the write
+- rollback route if the write must be undone
+
+## Escalation
+
+If a protected write already happened without confirmation:
+
+1. Report it immediately; do not fold it into an unrelated summary.
+2. Show the diff and offer to revert.
+3. Route the diff through `review-trigger.md` and `sensitive-code.md` for
+   review classification before any further work builds on it.
+
+## Non-Goals
+
+This file does not:
+
+- implement permission enforcement, sandboxing, or filesystem ACLs
+- replace code review or the diff classification in `sensitive-code.md`
+- restrict reads, analysis, or drafting proposals about protected surfaces
+- own Git or agent hook mechanics; use `git-hooks.md` for hook lifecycle
+  placement
+
+It defines when a write needs explicit user confirmation and what evidence the
+confirmation and the write must leave behind.