/init Skill — Harness Scaffold Initializer

Implements R-4-4 from (internal research note, if your project maintains one). Prerequisite: harness plugin installed (plugin.json present, marketplace registered). Constraint: F5 — CLAUDE.md at plugin root is NOT loaded as project context. This skill generates files directly in the target repo.

When to Use

• Bootstrapping a new repository with the patrick-work-harness
• Setting up Gate A–E workflow + session document structure from scratch
• Re-initializing after a harness version bump (when .claude/harness-answers.yml is absent)

Prerequisites

• Claude Code with patrick-work-harness plugin enabled
• Write access to the target repository root
• Know: repo name, primary stack, whether MVP Phase model applies, archive/worklog paths

Procedure

Step 1 — Codebase analysis

1-a. Code scan

Scan the target repo to detect:

• Primary language/framework (look for build.gradle.kts / package.json / requirements.txt / go.mod)
• Existing CLAUDE.md (if present, warn before overwriting the HARNESS zone)
• Existing .claude/harness-answers.yml (if present, load existing answers as defaults)

1-b. Context document discovery (project intent the code scan cannot reveal)

Code scan reveals structure; it cannot reveal why the project exists. Discover existing planning / business / discussion documents already in the repo so the generated baseline docs carry product intent — not just code facts. This context_summary is consumed downstream by Step 4 (CLAUDE.md Project Overview) and Step 8-b (ARCHITECTURE / DATA_FLOW). Ordering 1 → 4 → 8 guarantees it exists before consumption.

Search locations: repo root + docs/ + planning dirs (docs/planning/ · docs/spec/ · docs/product/ · 기획/ · docs/기획/).

Filename patterns (case-insensitive, English + Korean): PRD · PRODUCT · REQUIREMENT(S) · ROADMAP · VISION · PROPOSAL · BUSINESS · SPEC · 기획 · 사업계획 · 제안 · 요구사항 · 논의 · 회의 · plus README.md.

Bound (token-blowup guard): read at most ~5 most-relevant files (prefer explicit product/business docs over README.md); bound the per-file read. Never read the whole repo.

Extract: project goal/purpose · target users · key domain entities · business constraints · scope boundaries.

Output: context_summary = discovered source paths + a 3–6 line synthesized summary. If nothing is found → context_summary = none.

Hallucination guard (DOCBASE spec constraint #6): synthesize only from facts actually read; cite the source paths; mark anything uncertain with <!-- verify -->. Never invent goals not present in the sources.

Failure-safe (DOCBASE spec constraint #5): if a candidate file is unreadable, skip it and continue — never abort /init or silently produce nothing. Worst case degrades to context_summary = none.

1-c. Plan-tier auto-detection

Detect whether the repo already has (or is heading toward) a 2-tier plan structure — a separate index doc plus a sub-platform detail-plan doc with its own session table (§7-style) — versus a 1-tier structure where a single plan doc carries both index and session-table roles.

Detection heuristic (best-effort hint, not authoritative — Step 2 always asks the user to confirm):

• Look for a file matching *MODERNIZATION*MASTER_PLAN*.md or **/00_*MASTER_PLAN*.md in a subdirectory distinct from the repo root, or a §7 / ## 7. session-table heading inside any root-level plan doc.
• Found → propose plan_tier: "2", pre-fill master_plan_file/detail_plan_file from the discovered names.
• Not found → propose plan_tier: "1" (the simpler default for a new repo).

Step 2 — Answers interview

Ask the user (or infer from Step 1 scan) for the following fields:

Step 3 — Write .claude/harness-answers.yml (D-2 provenance sidecar)

Create .claude/harness-answers.yml in the target repo root:

# Harness provenance sidecar (D-2 — HARNESS_PLUGINIZATION_DESIGN_V1.md §3)
# Written by /init · Updated by /harness-update
# DO NOT edit _engine_version manually — managed by /harness-update
_engine_version: "<plugin version from plugin.json>"
_engine_commit: ""
project_repo: "<answers.project_repo>"
stack: "<answers.stack>"
phase_model: <answers.phase_model>
session_docs: <answers.session_docs>
archive_path: "<answers.archive_path>"
worklog_path: "<answers.worklog_path>"
learning_path: "<answers.learning_path>"
process_evolution_path: "<answers.process_evolution_path>"
error_topics_path: "<answers.error_topics_path>"   # omit this line when code_repos is used
# code_repos:                                       # multi-repo workspace only
#   - "<sibling repo directory>"
plan_tier: "<answers.plan_tier>"
master_plan_file: "<answers.master_plan_file>"
detail_plan_file: "<answers.detail_plan_file>"
single_plan_file: "<answers.single_plan_file>"
single_plan_threshold: <answers.single_plan_threshold>
# autonomous_lane: gate-a §0-Lane · SKILL_DETAIL.md §Lane Routing (keep this comment off the key line)
autonomous_lane:
  enabled: <answers.autonomous_lane>   # false = every plan takes the review lane
  max_files: 5
  max_lines: 200
  hard_max_lines: 400
  protected_paths: []            # added to the default list; never replaces it

Write the autonomous_lane: block even when it is false, so the setting is visible. Turning it on takes effect only once this file is committed — the lane reads it at the plan's base commit, so a session cannot switch its own lane on.

_engine_version must match plugin.json → version at init time. archive_path / worklog_path here are the SSOT — do NOT duplicate these values as prose in CLAUDE.md (SSOT-in-prose violation, [SSOT 서술에 값 금지] policy).

Step 4 — Write CLAUDE.md with D-1 sentinel zones

Generate CLAUDE.md in the target repo root using the 2-zone structure (D-1 decision):

<!-- HARNESS:START v<_engine_version> -->
# <project_repo> — Claude Code Harness Instructions

## Language · Persona
- Rule files (CLAUDE.md · skills · hooks) = English. User-facing output = Korean.
- Unfamiliar tech → Spring Boot / JPA / AWS analogies

## Gate A → E (mandatory for all projects)
Each Gate is performed via /gate-a ~ /gate-e Skill commands.

| Gate | Skill | Deliverable | Stop point |
|------|-------|-------------|------------|
| A | /gate-a | Per-file detailed change plan | Await user approval |
| B | /gate-b | Comprehension check | Await the answer when a question fires |
| C | /gate-c | Code implementation | Await user confirmation |
| D | /gate-d | Verification (plan + execution) | Await user confirmation |
| E | /gate-e | WORKLOG · archive | — |

## Archive Canonical Paths
See `.claude/harness-answers.yml` → `archive_path` / `worklog_path` (SSOT).
<!-- HARNESS:END -->
<!-- PROJECT-OWNED below -->

## Build · Test
[Fill in per-repo test commands after /init]

## Project Overview
[Fill in: project goal, stack, team context]

## MVP Demo Roadmap Guardrail
[Fill in if phase_model: true — Phase 1–4 table and per-Phase completion criteria]

## Prohibited (project-specific)
[Fill in per-repo prohibitions]

Zone rules:

• <!-- HARNESS:START --> … <!-- HARNESS:END -->: engine-owned. /harness-update overwrites this zone wholesale (Axis A).
• <!-- PROJECT-OWNED below -->: project-owned. /harness-update never touches below this marker.

Step 4-b — Create the lesson store

Gate E writes error cases here and the Gate A lesson lookup reads them back; without the folder both stay silent.

• error_topics_path set → create <error_topics_path>/README.md if absent.
• code_repos set instead → for each repo, show the user the <parent>/<repo>/docs/rules/error_topics/README.md paths and create them only after they confirm (these are other repositories).

README.md content — the topic index gate-e Step 3 points to:

# 오류·교훈 주제 색인

Gate E Step 3 이 아래 주제 파일 끝에 항목을 덧붙인다. 형식은 gate-e Step 3(적용 조건·근거 칸 필수).
Gate A 는 시작할 때 `lessons_lookup.py` 로 이 폴더에서 맞는 교훈을 최대 2건 꺼낸다.

| 파일 | 태그 | 대상 오류 |
|------|------|-----------|
| `gate_process.md` | `PROC` | Gate 승인·절차·「구현」 해석·사후 소급 |
| `runtime_env.md` | `ENV` | Docker/컨테이너/패키지 관리자/권한/경로 |
| `git_commit.md` | `PROC` | 커밋 메시지·git 조작 |
| `testing.md` | `TYPE` `VERIFY` `LOGIC` | 타입·빌드·시험 실패·CI 검증 |
| `security_schema.md` | `SEC` `API` | 보안·토큰·API 계약·DB 스키마 |

Verify the file exists after writing ([ -f <error_topics_path>/README.md ]); retry once if absent.

Step 5 — Write session document stubs (if session_docs: true)

Generate minimal ${SESSION_INDEX_FILE} and ${CURRENT_SESSION_FILE} in the target repo root.

Plan-doc stub (tier-aware): additionally generate the plan document itself:

• plan_tier: "1" → generate <single_plan_file> (default WORK_PLAN.md) with a ## Phase 1 skeleton section (title + empty session table) — this single file carries both index and session-table roles.
• plan_tier: "2" → generate <master_plan_file> (index stub: priority §2 / active tracks §3 / next action §4 / handoff notes §5, all empty) only. Do not auto-generate <detail_plan_file> — the sub-platform detail plan is created later, at the first Gate A that needs it (per gate-a's Plan-Doc Update Pattern, see SKILL_DETAIL.md).

${SESSION_INDEX_FILE} stub:

---
project: "<project_repo>"
last_updated: "<today>"
gate: "⏸ (no active session)"
sessions_since_audit: 0
last_audit_date: ""
priority_note: ""
---

# 세션 인덱스

## 현재 세션

| 세션 ID | 제목 | 저장소 | 상태 |
|---------|------|--------|------|

## 최근 완료 세션

| 세션 ID | 제목 | 저장소 | 상태 |
|---------|------|--------|------|

${CURRENT_SESSION_FILE} stub:

# 현재 세션 상태

> **세션 ID**: (미정 — /gate-a로 시작)
> **현재 상태**: 세션 없음

## 대시보드

| 항목 | 값 |
|------|-----|
| 현재 Gate | — |
| Gate 진행 | — |
| 착수일 | — |

Labels are a contract: keep these Korean labels as written — the guards and the dashboard parse **세션 ID**·**현재 상태**·현재 Gate·Gate 진행·착수일 literally, whatever language the project writes in. A translated label makes the guards fail open and the dashboard lose the session.

Stub creation must be verified (do not silently skip): after writing each stub, confirm the file exists ([ -f <repo>/${SESSION_INDEX_FILE} ] / [ -f <repo>/${CURRENT_SESSION_FILE} ]). If either is absent, the Write step failed — retry it before proceeding. (Recurrence guard: a prior /init left a repo with harness-answers.yml present but both session stubs missing — session_docs: true was set yet Step 5 did not produce the files.)

Step 6 — Hook wiring: check first, wire only a source copy

The guards are usually wired already. Check before adding anything to the project's .claude/settings.json:

ls "${CLAUDE_PLUGIN_ROOT}/hooks/session-dashboard-sync.py"

• The file exists → skip this step. The harness came from the plugin (its hooks/hooks.json wires every guard) or from install.sh (which registered them in ~/.claude/settings.json). Adding them to the project settings again either never runs — Claude Code refuses ${CLAUDE_PLUGIN_ROOT} in settings.json ("only available in hooks defined in a plugin's hooks/hooks.json file"; verified on 2.1.307, the hook is logged as a failed hook at every response) — or runs every guard twice.
• The file is missing → a source copy (skills copied by hand, neither plugin nor install.sh). Wire the 3 guards into the target repo's .claude/settings.json with the absolute path of that copy's hooks/ folder (create the file if absent; merge into an existing hooks object — do not clobber other events):

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "python3 \"<absolute hooks folder>/session-dashboard-sync.py\"", "timeout": 10 },
          { "type": "command", "command": "python3 \"<absolute hooks folder>/gate-e-sync-guard.py\"", "timeout": 10 },
          { "type": "command", "command": "python3 \"<absolute hooks folder>/error-topics-guard.py\"", "timeout": 10 }
        ]
      }
    ]
  }
}

Never write ${CLAUDE_PLUGIN_ROOT} into a settings file — the engine lint (rule 19) rejects it in skill examples. All 3 guards resolve their target repo via CLAUDE_PROJECT_DIR, so they operate on this repo. Keep session-dashboard-sync.py as the first Stop entry (HARNESS-STALE-GUARD-3 ordering — it is fail-open and regenerates the HTML before the guards run).

6-b. Recommend two user settings (print them — do not write them)

These live in the user's ~/.claude/settings.json, outside the target repo, so /init only shows them and asks. Never edit user settings without an explicit yes.

{
  "cleanupPeriodDays": 3650,
  "permissions": { "ask": ["Bash(git push *)", "Bash(gh pr create *)"] }
}

• cleanupPeriodDays — Claude Code deletes conversation transcripts after 30 days by default. hooks/skill_usage_aggregator.py reads them for the monthly usage review, so the default leaves at most one month to review. Any value ≥ 1 works (0 is rejected).
• permissions.ask — pushing and opening a PR always ask first, even inside an authorized CE·DE batch run. ask rules win over allow rules. Merge into an existing permissions.ask array; do not replace it.

Step 7 — Generate the initial session-dashboard.html

After hook wiring, run session-dashboard-sync.py once manually so the dashboard exists immediately (subsequent Stop events auto-refresh it):

CLAUDE_PROJECT_DIR=<target repo root> python3 "${CLAUDE_PLUGIN_ROOT}/hooks/session-dashboard-sync.py"

Confirm session-dashboard.html was created at the repo root. If CLAUDE_PLUGIN_ROOT is unavailable (source-relative use), call the script at its source plans/hooks/ path with the same CLAUDE_PROJECT_DIR env.

Step 8 — Generate document baseline (if --docs ≠ none)

Generate codebase documentation files in the target repo root. Controlled by the --docs flag:

Flag naming follows the --check precedent in /harness-update (consistent --<key>=<value> form).

8-a. Brownfield guard (run before any write)

For each file to be generated, check if a same-named file already exists in the target repo root:

• Not present → write normally
• Present → write as <name>_harness.md (e.g. PROJECT_MAP_harness.md) + output warning: ⚠️ PROJECT_MAP.md already exists — wrote PROJECT_MAP_harness.md instead. Merge manually. Never overwrite the existing file.

8-b. Context incorporation (from Step 1-b discovery)

Reuse the context_summary produced in Step 1-b — do not re-search the repo. Incorporate it into the generated baseline docs so they carry product intent:

• context_summary ≠ none → ARCHITECTURE.md: fill the ## Purpose / System Boundaries section with the project goal · key domain entities · scope boundaries (cite source paths). DATA_FLOW.md: note the key domain entities / flows named in the summary.
• context_summary = none → leave a placeholder: <!-- No context docs found — fill in manually -->

The Step 1-b hallucination + failure-safe guards apply unchanged (read facts only · cite source paths · mark uncertain with <!-- verify -->).

8-c. Generate PROJECT_MAP.md

Scan the repo and produce:

# PROJECT_MAP — <project_repo>

## Directory Structure (top 2 levels)
<tree output, depth 2, skip .git / __pycache__ / node_modules>

## Technology Stack
<detected from build.gradle.kts / package.json / requirements.txt / go.mod>

## Module List
<skills/: list SKILL.md names | hooks/: list *.py filenames | config: plugin.json / marketplace.json>

8-d. Generate ARCHITECTURE.md

Scan entry points and dependency chain:

# ARCHITECTURE — <project_repo>

## Purpose / System Boundaries
<filled by Step 8-b from context_summary: project goal · key domain entities · scope boundaries + `> Source: <paths>`>
<!-- No context docs found — fill in manually -->

## Entry Points
- install.sh — CLI installer
- skills/*/SKILL.md — harness skill definitions (list names from frontmatter `name:`)

## Layer Structure
| Layer | Path | Role |
|-------|------|------|
| Skills | skills/ | Gate A–E + utility skill definitions |
| Hooks | hooks/ | Stop/PreToolUse event handlers |
| Config | plugin.json · marketplace.json | Plugin metadata |
| Docs | README.md · CHANGELOG.md | User-facing documentation |

## Dependency Chain
<parse `import` statements in hooks/*.py to list inter-module dependencies>

8-e. Generate DATA_FLOW.md

Trace code-verifiable data paths:

# DATA_FLOW — <project_repo>

## Session Dashboard Pipeline
${CURRENT_SESSION_FILE} / ${SESSION_INDEX_FILE}
  → session-dashboard-sync.py (Stop hook)
  → session_dashboard_parsers.py (parse)
  → session_dashboard_renderer.py (render)
  → session-dashboard.html

## HARNESS Zone Update Path
CLAUDE.md (HARNESS zone)
  → harness-update skill
  → reconcile (overwrite HARNESS:START…HARNESS:END)
  → harness-answers.yml (_engine_version bump)

## Install Path
install.sh (--version / --target / --dry-run flags)
  → GitHub Releases tarball download
  → skills/ · hooks/ extracted to target repo

## Domain Entities / Flows
<filled by Step 8-b from context_summary if present>
<!-- No context docs found — fill in manually -->

8-f. Generate DOC_INDEX.md

# DOC_INDEX — <project_repo>

> Document status dashboard. Updated by `/init` on first run; sections updated by each Gate.

| Document | Layer | Updated by | Status |
|----------|-------|------------|--------|
| PROJECT_MAP.md | 1 | /init | Generated |
| ARCHITECTURE.md | 1 | /init | Generated |
| DATA_FLOW.md | 1 | /init | Generated |
| DOC_INDEX.md | meta | /init | Generated |
| FEATURE_SPEC.md | 2 | Gate A | Pending |
| API_SPEC.md | 2 | Gate C | Pending |
| TEST_PLAN.md | 2 | Gate C–D | Pending |
| ERROR_HANDLING.md | 2 | Gate D | Pending |
| DECISION_LOG.md | 2 | All gates (ADR) | Pending |

Status values: Generated / Pending / Updated (YYYY-MM-DD) / Not present

Layer 2 documents (FEATURE_SPEC through DECISION_LOG) are not generated by Step 8 — they are created by Step 9 with skeleton + Gate markers only.

Step 9 — Generate Layer 2 document skeletons (if --docs=full)

Generate 5 Layer 2 documents with skeleton structure and Gate markers only. No content is filled in — markers indicate which Gate fills each section.

9-a. Brownfield guard

Same rule as Step 8: if a same-named file already exists in the target repo root, write as <name>_harness.md and output a warning. Never overwrite.

9-b. File naming

File names are fixed (FEATURE_SPEC.md, etc.). Replace <session_id> placeholder inside each file with the actual session name at Gate A time.

9-c. Skeleton templates

FEATURE_SPEC.md:

# FEATURE_SPEC — <session_id>

## Overview
<!-- Gate A에서 채워짐 -->

## Acceptance Criteria
<!-- Gate A에서 채워짐 -->

## Out of Scope
<!-- Gate A에서 채워짐 -->

API_SPEC.md:

# API_SPEC — <session_id>

## Endpoints
<!-- Gate B에서 채워짐 -->

## Request / Response Shapes
<!-- Gate B에서 채워짐 -->

## Error Codes
<!-- Gate B에서 채워짐 -->

TEST_PLAN.md:

# TEST_PLAN — <session_id>

## Test Cases
<!-- Gate C에서 채워짐 -->

## Verification Checklist
<!-- Gate D에서 채워짐 -->

ERROR_HANDLING.md:

# ERROR_HANDLING — <session_id>

## Failure Paths
<!-- Gate D에서 채워짐 -->

## Recovery Strategies
<!-- Gate D에서 채워짐 -->

DECISION_LOG.md:

# DECISION_LOG — <session_id>

## Architecture Decision Records (ADR)

<!-- 각 Gate에서 ADR 추가 -->
<!-- 형식: ### [YYYY-MM-DD] <결정 제목> / Context / Decision / Evidence / Consequences / Prediction·Check by / Outcome -->

9-d. DOC_INDEX.md update

After writing the 5 files, update DOC_INDEX.md: change each Layer 2 row's Status from Pending to Skeleton.

Step 10 — Fill Layer 2 document sections per Gate (if --docs=full)

This step defines what content to write into each Layer 2 document at each Gate. Step 9 created the skeleton with markers; Step 10 describes the fill rules. Actual filling happens as the AI works through Gates A~E — this step records the rules so every gate knows its responsibility.

10-a. Brownfield guard

Same pattern as Step 9: if the Layer 2 file already exists with user content (not a harness-generated skeleton), do not overwrite the filled sections. Detect by checking whether a section contains text beyond <!-- Gate markers. If content exists, append new content in a <!-- harness-added --> block below the existing content.

10-b. Fill format per document

FEATURE_SPEC.md (Gate A fills):

## Overview
<!-- Gate A에서 채워짐 -->
<one-sentence summary of what this session adds or changes>

## Acceptance Criteria
<!-- Gate A에서 채워짐 -->
- AC1: <measurable criterion>
- AC2: <measurable criterion>

API_SPEC.md (Gate C fills):

## Endpoints Changed
<!-- Gate B에서 채워짐 -->
### <METHOD> <path>
- Request: `<body or params>`
- Response 200: `<shape>`
- Response 4xx: `<error shape>`

TEST_PLAN.md (Gate C fills test cases, Gate D fills checklist):

## Test Cases
<!-- Gate C에서 채워짐 -->
| Case | Input | Expected | Type |
|------|-------|----------|------|
| TC1  | …     | …        | happy/edge/error |

## Verification Checklist
<!-- Gate D에서 채워짐 -->
- [ ] All happy-path test cases PASS
- [ ] Error-path test cases PASS
- [ ] No regression in existing tests

ERROR_HANDLING.md (Gate D fills):

## Failure Paths
<!-- Gate D에서 채워짐 -->
| Failure | Symptom | Root cause | Recovery |
|---------|---------|------------|----------|

## Recovery Strategies
<!-- Gate D에서 채워짐 -->
- <strategy 1>

DECISION_LOG.md (any Gate fills an ADR):

### [<YYYY-MM-DD>] <Decision title>
<!-- Gate <X>에서 채워짐 -->
- **Context**: <why this decision was needed>
- **Decision**: <what was chosen>
- **Evidence**: <the observation that decided it — session, command, numbers>
- **Consequences**: <trade-offs, constraints, follow-ups>
- **Prediction / check by**: <what should change and how you will measure it> / <date or "after N sessions"> (optional)
- **Outcome**: <filled in after the check date — held / did not hold / unchecked + evidence> (optional)

10-c. When NOT to fill

• If a Gate produces no artifact for a document (e.g. no API changes → API_SPEC unchanged), leave the marker in place. Do not write placeholder text like "N/A" — an empty marker is the correct state.
• Do not backfill sections from a later Gate into an earlier Gate's section (e.g. do not fill FEATURE_SPEC at Gate C).

10-d. DOC_INDEX.md status progression

Update DOC_INDEX.md Layer 2 row Status as each section is filled:

Verification Checklist (for Gate C after /init)

• C1: .claude/harness-answers.yml exists and is valid YAML
• C2: _engine_version matches plugin.json → version
• C3: CLAUDE.md contains <!-- HARNESS:START --> and <!-- HARNESS:END --> and <!-- PROJECT-OWNED below -->
• C4: archive_path / worklog_path appear only in harness-answers.yml, not duplicated as hardcoded prose in CLAUDE.md
• C5: ${SESSION_INDEX_FILE} and ${CURRENT_SESSION_FILE} stubs exist (if session_docs: true)
• C6: hooks are wired exactly once — plugin or install.sh install: the project's .claude/settings.json has no harness entries (Step 6 skipped); source copy: the 3 Stop guards with absolute paths, session-dashboard-sync.py first. No settings file contains ${CLAUDE_PLUGIN_ROOT}
• C7: session-dashboard.html exists at the repo root (generated by Step 7)
• C8: --docs=full run → PROJECT_MAP.md · ARCHITECTURE.md · DATA_FLOW.md · DOC_INDEX.md all present at repo root
• C9: Brownfield conflict → _harness suffix file written, original file untouched
• C10: --docs=none run → none of the 4 doc files generated (skip confirmed)
• C11: --docs=full run → FEATURE_SPEC.md · API_SPEC.md · TEST_PLAN.md · ERROR_HANDLING.md · DECISION_LOG.md all present at repo root
• C12: Each Layer 2 file contains Gate markers (<!-- Gate appears ≥ 1 per file) and no filled content
• C13: DOC_INDEX.md Layer 2 rows show Skeleton status (not Pending) after Step 9
• C14: FEATURE_SPEC.md has content filled in the Gate A section (not just a marker)
• C15: API_SPEC.md has content filled in the Gate C section
• C16: TEST_PLAN.md has content filled in Gate C and D sections
• C17: ERROR_HANDLING.md has content filled in the Gate D section
• C18: DECISION_LOG.md has at least one ADR entry (any gate)
• C19: --docs=full on a repo containing a planning/business doc → ARCHITECTURE.md Purpose / System Boundaries references the discovered content (not just a placeholder) and cites the source paths
• C20: CLAUDE.md Project Overview is populated from the discovered context docs (or keeps the [Fill in: …] placeholder when none found)
• C21: no context docs found → context_summary = none, all consumers fall back to the placeholder gracefully (no crash / no silent doc skip)
• C22: harness-answers.yml → plan_tier is present and is exactly "1" or "2"; the corresponding filename field (single_plan_file for "1", master_plan_file/detail_plan_file for "2") is non-empty; the tier-appropriate plan-doc stub exists at the repo root (Step 5)
• C23: harness-answers.yml sets error_topics_path (or code_repos), and the lesson store README.md exists (Step 4-b)

Notes

• /harness-update reads _engine_version from harness-answers.yml and reconciles the HARNESS zone in CLAUDE.md (Axis A) when the engine version bumps.
• Re-running /init on an existing repo: warn the user if CLAUDE.md already has a HARNESS zone to avoid overwriting customizations in that zone.
• archive_path and worklog_path in harness-answers.yml replace the hardcoded prose values that previously lived in CLAUDE.md §Archive Canonical Paths — this resolves the SSOT-in-prose violation.
• Step 6/7 (hook wiring check + dashboard generation): plugin and install.sh installs already wire the guards, so Step 6 only wires a source copy, with absolute paths. Before 2026-10-22 it wired ${CLAUDE_PLUGIN_ROOT} paths into the project settings, which Claude Code never runs.