# HyperQE Bootstrap Rule (Automation Lifecycle)

This rule is mandatory for all agent harnesses (Cursor, Claude Code, Codex, GitHub Copilot).

## Intent
Enforce a deterministic HyperQE delivery lifecycle before implementation for automation projects.

## Mandatory Lifecycle (4-Phase — Primary since v8.0.0)

1. Design (`/hqe-design`) — intake, discovery, feasibility, reuse search, automation design
2. Develop (`/hqe-develop`) — POM/locator/helper updates, script generation, initial execution
3. Validate (`/hqe-validate`) — execute → analyze → repair → rerun → stabilize → review → verify
4. Deliver (`/hqe-deliver`) — aggregation, traceability, merge readiness decision

Or run end-to-end:
- `/hqe-generate`

## Hard Rules
1. Never implement automation before `/hqe-design` is completed.
2. Never create new automation assets before reusable asset search.
3. Never validate without executing the automation script.
4. Failed execution during `/hqe-validate` MUST trigger maintenance workflow.
5. After maintenance, script MUST be re-run.
6. Regression scripts MUST have a stability assessment.
7. Delivery requires evidence-based validation.
8. Manual testcase → automation script traceability is mandatory.
9. Gates cannot pass using checklist-only validation.
10. Merge readiness requires governance decision.

## Approval Actions
- `/approve`
- `/rework <reason>`
- `/reject <reason>`
- `/skip-gate <reason>`
- `/escalate <target>`

Each action records a `GateDecision` (`.hyperqe/core/schemas/gate-decision.schema.json`) at
`.hqe/gate-decisions/{deliveryId}/{gate-slug}.json` (`gate-slug` = kebab-case gate name, e.g.
`design-gate`). **A gate decision always names one specific `deliveryId` — never a shared
"batch" placeholder.** Every gate (Design/Development/Validation/Delivery) governs one
`delivery-{id}` end to end (`.hqe/memory/delivery-{id}/`, `.hqe/artifacts/{deliveryId}/...`); even
when several deliveries were designed together in one batch intake (Initiative A6) and mirrored
into one human-review Markdown file for readability, each already carries its own independent
recommendation (`design-quality-assessment.json` per delivery). Approving one TC and reworking
another in the same batch is a normal, expected outcome — one decision must never stand in for
all of them. If the delivery being reviewed isn't obvious from context, ask which `deliveryId`
before recording a decision; do not default to a batch-wide one.

**Before treating any gate as awaiting human input, check this file first** — a decision may
already have been recorded from the orchestration dashboard (`.hyperqe/scripts/orchestration-dashboard/`)
rather than typed in this chat. Honor an existing decision exactly as if the matching action had
just been typed here; do not re-block or ask again. This is one recording mechanism with two entry
points (chat command or dashboard button), not two separate approval systems.

## Gate review toggle (`.hyperqe/hqe.config.json`)

- **`gates.reviewEnabled`** (boolean, default **`true`**): when **`true`**, human gate sign-off is expected before treating a phase as closed for handoff (use `/approve` and checklist evidence as today).
- When **`false`**, the runtime **does not block** progression on waiting for explicit `/approve` for gate closure; the agent must still run gate **checklists as quality work**, write artifacts, and **record in the phase artifact or summary** that human gate review was skipped by configuration (timestamp + `.hyperqe/hqe.config.json gates.reviewEnabled=false`). This is **organizational risk acceptance** — not a substitute for missing evidence or broken tests.

## Evidence verbosity toggle (`.hyperqe/hqe.config.json` → `evidenceVerbosity`)

- **`"full"`** (default): human-review Markdown summaries (`design-summary.md`, `develop-summary.md`,
  `validate-summary.md`, `delivery-summary.md`) are a full mirror of their paired JSON artifact —
  every field restated in tables/prose, per the templates under `.hyperqe/templates/human-review/`.
- **`"lite"`**: the canonical JSON artifact (`automation-design.json`, `development-report.json`,
  `validation-report.json`, `delivery-report.json`, etc.) remains the same — no reduction in what
  is *validated* or *recorded*. Only the optional Markdown summary changes: a short highlights
  block (recommendation/verdict, key scores, open risks, blocker count) plus a direct link to the
  JSON artifact, instead of restating every field. This exists purely to cut token spend on
  large/verbose generation; it never reduces gate evidence, schema validation, or hard rules.

## Orchestration event logging (`.hyperqe/hqe.config.json` → `orchestrationLog.enabled`)

- **`enabled`** (boolean, default **`true`**): when true, every agent harness bound by this rule
  (Cursor, Claude Code, Codex, GitHub Copilot) records orchestration events by running
  `node .hyperqe/scripts/log-orchestration-event.mjs --type <type> --name <name> [--workflow <id>]
  [--phase <phase>] [--delivery <id>] --status <status>` at these points:
  1. **Command start** — `--type command --name hqe-design` (etc., **without** the leading `/` —
     on Windows Git Bash/MSYS a leading `/` in an argument gets auto-converted to a filesystem path
     before Node sees it, corrupting the logged name) when a slash command from
     `.hyperqe/commands/command-registry.json` is resolved.
  2. **Skill invocation** — `--type skill --name <workflow's "skill" field>` when that skill's
     `SKILL.md` is loaded and applied.
  3. **Agent delegation** — `--type agent --name <workflow's "assignedAgent" field>` when work is
     delegated to that agent persona.
  4. **Workflow step start/complete** — `--type workflow-step --name <steps[].id>` with
     `--status started` then `--status completed` (or `blocked`, citing `blockIf`, via `--detail`).
  5. **Gate result** — `--type gate --name <gate name>` with `--status passed|failed|blocked` when
     a `type: "gate"` step resolves.
- Feeds `.hqe/orchestration-log/events.jsonl`, read live by
  `.hyperqe/scripts/orchestration-dashboard/server.mjs` (see `docs/production-readiness-roadmap.md`
  Initiative F). **This log is self-reported by the harness's own instruction-following — there is
  no code that enforces the logging call, since HyperQE's command/workflow/skill/gate layer itself
  is prose for an LLM to act on, not an executable runtime.** Treat gaps in the log as missed
  logging calls, not as proof those steps didn't happen.
- **Claude Code specifically** gets a partial deterministic backstop: `.claude/settings.json`'s
  `PostToolUse` hook (`.hyperqe/scripts/hooks/log-artifact-event.mjs`) automatically logs a `gate-decision`
  event when a `.hqe/gate-decisions/{deliveryId}/{gate-slug}.json` file is written, and a
  `workflow-step` completion event for known final phase artifacts (`design-summary.md`,
  `development-report.json`, `validation-report.json`, `delivery-report.json`, etc.), regardless of
  whether the agent remembered to call the script manually. It **cannot** cover command-start,
  skill-invocation, or agent-delegation events (those aren't file-write events, so hooks can't see
  them), and hooks don't exist in Cursor or Copilot — the fully self-reported convention above
  remains the only mechanism for those two harnesses and for the 3 event types the hook can't reach.
- When `false`, skip all of the above — no orchestration events are recorded (the dashboard will
  simply show nothing for that session).