Spec: Harness Methodology Domain

User Input

Deliver the full M2 Private Harness Wiki milestone for Harness Intelligence. IP-100 creates the harness domain for methodology, criteria, trust model, skill packs, prompt surfaces, validation, execution modes, and lifecycle flows separately from CLI mechanics.

Child requirements:

• IP-119: navigation includes Foundations, Prompt Surfaces, Skills and Packs, Execution Modes, Validation and Tools, and Lifecycle Flows.
• IP-120: concepts cover harness, context engineering, progressive disclosure, prompt scopes, skills, hooks, validation gates, external tools, subagents, and memory notes; skill packs are modeled before individual skills.
• IP-121: flows cover repo adoption, requirements grill, backlog conversion, spec creation, planning, sequential/parallel implementation, browser validation, code review, debug, issue reporting, docs maintenance, baseline publish, and update.

Context

The private wiki needs a readable Harness methodology domain so internal colleagues and agents can understand the operating model behind punks/dp. The grill and reference docs already capture a product contract, but that material is not yet organized as durable wiki knowledge. This spec turns the accepted requirements into source domain pages and routed Fumadocs pages without inventing fake implementation specs.

Non-Goals

• Public web IA or landing copy.
• A page for every individual skill in v1.
• Plan-level worker decomposition in human-facing pages.
• CLI implementation mechanics, baseline registry internals, or filesystem update behavior.
• Backoffice telemetry or project usage UI.
• Synthetic specs generated from grill artifacts.

Acceptance Criteria

• apps/wiki/content/docs/project/domains/harness.mdx lists the harness domain IA and separates methodology from CLI mechanics.
• Routed /docs/harness navigation is grouped into Foundations, Prompt Surfaces, Skills and Packs, Execution Modes, Validation and Tools, and Lifecycle Flows.
• Harness concept pages cover the required inventory: harness, context engineering, progressive disclosure, prompt scopes, skills, hooks, validation gates, external tools, subagents, memory notes, and skill packs.
• Skill packs are modeled as pack-level concepts before any individual skill pages.
• Lifecycle flow pages cover adoption through closeout: repo adoption, requirements grill, backlog conversion, spec creation, planning, sequential/parallel implementation, browser validation, review, debugging, issue reporting, docs maintenance, baseline publish, and update.
• Flow pages are compatible with future docs-ingest output and do not contain agent-only implementation task instructions.
• The CLI domain remains linked for mechanics and is not rewritten as methodology.
• Changed meta.json files are valid JSON and include every new routed page or folder.
• Local build/typecheck and browser smoke prove the harness routes render and navigation is readable.

Constraints

• The harness domain is internal/private.
• apps/wiki/content/docs/project/domains owns project-side domain source indexes. Do not create a new docs/reference domain mirror.
• Routed MDX pages should curate and summarize, not duplicate full source pages or specs.
• Use grill artifacts as source evidence for concepts/flows, not as backlog/spec replacements.
• Keep wording semi-technical and concrete, not marketing.

Technical Notes

• Existing harness domain had only one concept, phase-goal-workflow.
• apps/wiki/content/docs/harness/meta.json was flat and listed only index plus that one concept route.
• The source concept inventory should be intentionally compact in M2: a few durable pages can cover multiple related concepts without creating per-skill sprawl.

Decision Log