implement

---
name: implement
description: "Orchestrates the make-it-work pipeline for one ticket — context check → close-the-gaps → risk assessment → Lightweight implementation (low risk) or plan-the-work → execute (TDD) → review-the-code → final context sync — with saved, resumable workflow state, Guided, Autonomous, and unattended --autopilot modes, Lightweight → TDD escalation, capped fix/replan loops, and local end-of-run workflow feedback. Never commits implementation changes, pushes, opens a PR, or uploads feedback. Use when taking a ticket from request to a reviewed, context-synced implementation in one run."
disable-model-invocation: true
hooks:
  PostToolUse:
    - matcher: '*'
      hooks:
        - type: command
          command: 'node "${CLAUDE_PLUGIN_ROOT}/skills/implement/scripts/startup-presentation.mjs"'
          timeout: 10
  PreToolUse:
    - matcher: '*'
      hooks:
        - type: command
          command: 'node "${CLAUDE_PLUGIN_ROOT}/skills/implement/scripts/startup-presentation.mjs"'
          timeout: 10
  Stop:
    - hooks:
        - type: command
          command: 'node "${CLAUDE_PLUGIN_ROOT}/skills/implement/scripts/startup-presentation.mjs"'
          timeout: 10
---

# Implement

**Role:** Act as a thin orchestrator for the make-it-work pipeline.

**Goal:** Take one ticket from request to a reviewed, context-synced implementation by running the existing stage skills in order. `implement` assesses the ticket's risk to choose the run mode, decides which phase runs next, runs that stage skill, interprets the outcome it reports, records the transition, enforces the loop limits, and performs the final context sync. It never redoes a stage's own reasoning — refinement belongs to `close-the-gaps`, planning to `plan-the-work`, implementation to `execute` (or, in Lightweight mode, a dispatched implementation subagent), review to `review-the-code`.

**Autonomy changes:** Before Start or Resume, read [references/autonomy-changes.md](references/autonomy-changes.md). Keep this contract active during inline stages: chat changes queue for the next phase, while the saved effective mode governs the current phase.

**Ticket updates:** For an explicitly supplied tracker ticket or a run with a saved `ticket_publication` journal, read [references/ticket-publication.md](references/ticket-publication.md) at Start/Resume and keep it active through the run. `implement` alone publishes accepted specs, plans (attachments or authorized comment fallback), significant blockers, completion/review/verification summaries and one final Jira HTML dashboard attachment through available connector capabilities, under a separately saved, explicit consent. Autonomy never grants ticket-write permission. Local spec/pasted-content runs stay local unless the user explicitly supplies a tracker destination.

**Fresh-run response order (Guided, Autonomous and Autopilot):**

1. Create the state and HTML with `workflow.mjs init` in its own tool call.
2. The initializer returns `next_action.type: assistant_message`. Perform that
   action immediately: send `next_action.text` as a user-visible assistant chat
   message before calling any further tool, including an activity checkpoint,
   a reference read, or Context check. Send a standalone assistant response with
   no tool calls, then finish that response. The Stop hook confirms its runtime
   text and continues the active workflow automatically. For example:

   [Open implementation dashboard](</absolute/project/make-it-work/TICKET/TICKET-status.html>)

   I'll check the project context next.

   The tool result's `delivery_status: not_sent` means this message is still
   yours to send. If only tool calls/results have occurred since init, the link
   has not been shared in chat. Emit it now; a later assertion that it was sent
   does not count.

3. After that internal response boundary, follow `continuation`. A normal
   run continues into Context check for the same user request, without a reply,
   acknowledgment or approval. Do not wait for the user to restart it.

The skill's startup-presentation hooks reinforce this order. The immediate
post-init reminder requires the assistant chat action. Stop confirms the exact
clickable link from its runtime `last_assistant_message` rather than waiting for
the asynchronously written transcript. It saves a local confirmation receipt
bound to the session, initialization, run start and dashboard. Later tool hooks
can use that receipt while the transcript catches up. This is evidence of
assistant output, not evidence that a person read or approved it. Older runtimes
without that payload retain the bounded transcript fallback. Partial final JSONL
writes and diagnostic request replays do not count as new announcements.
If a tool was denied after the link streamed, finish the standalone response;
do not repeat the link or keep retrying tools. Stop requires the actual chat link
and checks that a fresh run is no longer In Progress at any stage. Continue the
saved stage in this turn until completion or a genuine saved pause/stop. Pending
offline-answer waits retain their existing behavior.

When a delegated background agent is still running, yield with a brief waiting
update and let its completion notification resume the session. Do not launch
shell sleeps, file watches or repeated status polls merely to keep the turn open.
The Stop hook permits this wait only with runtime launch evidence for a live
agent launched in the current Plan, Execute, Lightweight, Review or Fix phase.
Plan includes delegated testing-readiness and plan-drafting work. The workflow stays In Progress; yielding does not complete or pause it. Completion,
failure or a runtime inventory showing the agent is no longer running restores
the continuation requirement. A waiting claim, shell job or agent from an earlier
phase does not qualify. On hand-back, verify the result and continue the stage. The hooks record local,
sanitized interruption and wait observations for terminal workflow feedback;
recording failures do not change enforcement or the saved workflow status.

New initialization also captures a read-only baseline of application files in
every approved repository. Before the first authorized Execute or Lightweight
stage, tool hooks detect changes relative to that baseline and Stop blocks a
terminal response even if a same-phase stop was saved. Workflow artifacts,
Markdown, project context under .claude and docs are excluded so refinement and
planning can write their documented outputs. Existing local edits are preserved.
This detects completed tool mutations; it does not undo them or sandbox Bash.
On a violation, preserve the edits and recover through refinement, risk assessment,
the approved implementation route and independent review. Resume the saved phase
if an internal failure was checkpointed as Stopped. Never claim a bypassed change
is complete or ask the user to accept it as the default escape. Only a genuine
external blocker justifies asking for guidance. A new user turn clears the fresh
startup obligation; these hooks do not replace Resume checks or retrofit old runs.

The standalone announcement response is an internal verification boundary, not
a workflow pause. Do not request acknowledgment, ask whether to continue, or
require another user message. Let the Stop hook resume the active run, then
continue through the chosen autonomy's normal workflow
until a genuine documented question, approval, pause, stop, or completion.
Use an ordinary assistant text block; thinking/progress updates displayed as
`· summary` can strip links and do not count. Do not claim to open a browser.
For **Pending offline refinement**, the existing offline-answer wait is a genuine
pause: include the link in that stop message and follow its existing resume
instructions instead of entering Context check.

**Pipeline checkpoint:** Before editing implementation code or tests, carry out Start's branch guard and create the ticket's workflow state and dashboard, send the returned startup chat message before any further tool, and continue with Context check in the same turn. Follow the saved phase transitions and required stage skills through review and final sync. Only the run mode chosen under Risk assessment may skip stages (Lightweight skips Plan and Execute). No mode waives the mandatory minimum — the refined spec, the independent review, and the final context sync — and nothing waives a handoff, checkpoint, or log row. If a required stage cannot run, checkpoint its documented stop in the state instead of implementing the ticket directly. Do not report a ticket as complete merely because its code and tests pass; `status: Complete` requires the pipeline's terminal checks.

---

## Usage

```
/make-it-work:implement [TICKET-ID | path/to/spec.md] [--autopilot] [--mode lightweight|tdd] [--workspace path]
```

Or paste the ticket content directly into the chat after invoking.

- **`--autopilot`** — strip this flag before resolving the ticket or spec path. It selects Autopilot without the initial autonomy question. This flag alone leaves ticket updates off; an explicit scoped instruction or the same run's saved consent can authorize publication. Both interactive Autopilot choices use the same execution policy: no `AskUserQuestion` calls during implementation, and `--autopilot` forwarded to every dispatched stage. Requirements-conflict resolution and revised-spec approval are mandatory human exceptions during implementation. After a package-enabled run is Complete, the optional delivery offer is another exception: it always asks, but never delays or changes the completed result. It never commits, pushes, opens a PR, invokes `go-deep`, or guesses through a missing/contradictory required fact; those cases checkpoint a `Stopped` state with an actionable reason. Testing readiness may configure minimal test tooling and follow `define-test-strategy` inline before planning.
- **`--mode lightweight|tdd`** — strip this flag the same way. It forces that run mode for a new run (`mode_source: user`); risk is still assessed and recorded, and escalation still applies (see Risk assessment). Record it as a flag decision in the first Audit-log row. An explicit chat request for a mode has the same effect. An older run without `adaptive_version` ignores it.
- **Ticket key or pasted content** — derive `<TICKET>` exactly as `close-the-gaps` Phase 1 does: the ticket ID; otherwise a kebab-case slug of the title; otherwise `spec-YYYY-MM-DD`.
- **Spec path** — `<TICKET>` is the file name without its `-spec.md` suffix.
- **No argument** — list `make-it-work/*/*-state.md` files whose `status` is not `Complete`. Exactly one → offer to resume it; under `--autopilot`, resume it only when its saved autonomy is `autopilot` and its workspace fingerprints still match. Several or none → ask the user; under `--autopilot`, stop with the matching no-safe-default reason. Ignore flat artifacts from runs started before the per-ticket layout.

## Autopilot mode

While the current autonomy is `autopilot`, construct every later ordinary implementation question/checkpoint payload exactly as the interactive path would, but do not call `AskUserQuestion` or wait during implementation. `--autopilot` and Start's autonomy question select the initial mode; a later explicit chat request follows **Change autonomy during a run** below. Requirements-conflict resolution and revised-spec approval also require explicit user input in Autopilot; see **Requirements conflict — return to refinement**. Workspace repository/branch selection is a separate mandatory explicit approval, including Autopilot; see [workspace.md](references/workspace.md). Completion's optional delivery offer happens only after the run is terminal and is always asked, including in Autopilot. Append each orchestration-level resolution with the shared schema in `docs/autopilot-log-schema.md`. When `--autopilot` is supplied and `<TICKET>` is known, initialize `make-it-work/<TICKET>/implement-autopilot-log.jsonl` fresh before Start's existing-run check, so a hard stop there can still be logged, unless an explicit mode-change request in this message overrides the flag; that request uses the reference's log-preservation rule. When Autopilot is selected interactively for a new run, initialize it immediately after that choice, before the branch guard. Log the autonomy selection as the first resolution in either case; the rationale must distinguish a user's selection from a flag-selected default. Use `node "<base>/../../scripts/decision-log.mjs" init|append implement --root "<repo-root>" --ticket "<TICKET>"` in its own Bash call when Bash is available; a denied log write never blocks unrelated pipeline work.

Auto-resolve only these safe defaults: apply the assessed (or forced) run mode and any escalation; create the suggested ticket-named feature branch when starting on the base branch; retain a clean resumable autopilot run's saved mode; establish the recommended minimal test setup before planning; continue with clear related/unrelated regression classification; choose sequential dispatch; and replan when the existing Autonomous rules already prescribe replan. Honor an explicitly selected manual verification policy without asking again; never infer it from unavailable automated results. Forward `--autopilot` to `close-the-gaps`, `define-test-strategy` during readiness, `plan-the-work`, `execute`, and the Review dispatch; `execute` forwards it to `run-regression` for its automated completion gate.

Stop, record `chosen: null`, set `status: Stopped`, clear `current_activity`, regenerate the dashboard, and report the remediation when there is no safe default: no ticket or several resumable runs, detached HEAD, an existing completed/stopped run or standalone artifacts that would need a reuse/overwrite choice, changed worktree on resume, unresolved TBDs or plan blockers, uncertain regression ownership, an unavailable regression result, a review `Route: human` finding, or any stage's own hard stop. A normal terminal feedback retrospective never re-opens a successful run: write the best available share-safe diagnosis and retain material uncertainty in `openQuestions` rather than asking follow-ups.

At the terminal report, summarize auto-resolved decisions and the implement log path in addition to the normal completion/stop summary.

## Change autonomy during a run

Apply [references/autonomy-changes.md](references/autonomy-changes.md) throughout the run. An explicit chat request such as "switch to Guided", "switch to Autonomous", or "switch to Autopilot" queues the current ticket's mode for the next phase without restarting it. Save `queued_autonomy` separately from effective `autonomy` and refresh an existing dashboard before acknowledging it. The latest request replaces the queue; requesting the effective mode cancels it. Use effective autonomy for all remaining work/questions in the current phase, including nested stages and open approvals. The ordinary phase transition applies the queue before next-phase work and records that application. No queued change supplies a missing answer or approves delivery.

---

## Stage skills

The stage skills are siblings of this skill in the plugin. Take the `Base directory for this skill:` path printed when this skill loaded, and resolve:

- `<base>/../close-the-gaps/SKILL.md`
- `<base>/../plan-the-work/SKILL.md`
- `<base>/../execute/SKILL.md`
- `<base>/../review-the-code/SKILL.md`
- `<base>/../define-test-strategy/SKILL.md` — only for testing readiness, including refresh after setup

Read each one with the Read tool when its phase starts — **never** start them through the Skill tool; they are deliberately user-invoked only outside this orchestrator. Follow each skill's instructions including its `## When run by implement` section, passing the inputs that section names.

That inline-stage rule applies only to the pipeline skills listed above. It does not waive any repository's `CLAUDE.md` skill-loading gate: load matching domain/UC skills by the method that repository requires before source exploration, edits or review. Pass that distinction explicitly to implementation, fix and review delegates. If required loading is unavailable, checkpoint the stage's blocker instead of silently substituting a later documentation read.

- Pass the exact **workflow state path**, even for an older run without a dashboard, the current autonomy, and the workflow-decision audit contract to each stage (including readiness and nested regression). The workflow state path does not authorize dashboard backfill. Inline stages share this session's autonomy-change handling; dispatched subagents do not own it.
- Pass the resolved `implement` directory and [activity checkpoint contract](references/activity.md) into inline stages and nested skills. The main session owns activity writes, including the description saved before dispatching a subagent and retained while waiting for its result; delegated agents must not write workflow activity or edit HTML. Preserve the contract's legacy single-step Progress-helper exception.
- Pass this scope constraint to every stage and delegated agent, including nested skills: never invoke or follow `go-deep` inline during `implement`, in any autonomy mode. Defer full onboarding, repair and broad documentation audits; report the affected repo and concrete gap to the parent for Context discoveries and the completion recommendation. Ticket-scoped documentation maintenance still applies.
- Refinement, planning, and execution run inline in this session; while the current mode is `autopilot`, pass `--autopilot` so their own decision policies replace questions while `execute` dispatches its own per-step subagents. Recompute this from the saved mode for each dispatch, including nested regression; do not reuse the invocation's original flag after a change.
- On workspace runs, pass the saved `workspace_contract` and artifact root through every stage and delegated agent under [the workspace contract](references/workspace.md). It overrides standalone root detection and repo-relative artifact assumptions. Newly discovered repos require explicit scope/branch approval before edits.
- Review runs in a fresh subagent, for an independent read of the change (see Review dispatch).
- Lightweight implementation and its fixes run in a fresh subagent with no stage skill (see Lightweight implementation).

If a required stage file is missing, stop and tell the user the exact path that could not be found. Do not improvise the stage.

The feedback retrospective's detailed contract is in `<base>/references/feedback.md`. Read it only after an eligible run has already reached its terminal state; ordinary in-progress phases do not need it.

For runs with `handoff_version: 1`, also read `<base>/references/handoffs.md` before the first stage. Each stage produces the versioned JSON result described there. Validate it and run the read-only `handoff.mjs next` helper after the stage; use its action to select the next phase or question. The Transition table below still specifies the side effects of each route and remains the compatibility path for older runs.

---

## Workflow state

**Scripted checkpoints:** Read [references/controller.md](references/controller.md) before Start. New runs are initialized and transitioned by `scripts/workflow.mjs`; its `controller_version: 1` contract replaces manual state/counter/hash/audit writes described below. The template remains the source for initialization defaults. Existing runs without the field retain their original behavior.

**Waiting for input:** Once state exists, read the reference's pending-input lifecycle before any user question or approval. Blocking waits are persisted as Paused with their actual question/choices, cleared activity and refreshed HTML before asking. Resolve the saved ID explicitly before continuing; optional permission requests can remain nonblocking. Delivery after Complete retains its separate journal. This replaces ad hoc question/pause bookkeeping below.

For a new run, create the real directory `make-it-work/<TICKET>/` under the artifact root and put all ticket-scoped artifacts there. Keep the existing `<TICKET>-` filenames inside that directory. Do not move or resume flat artifacts from older runs. The run's state lives in `make-it-work/<TICKET>/<TICKET>-state.md`, next to the other pipeline artifacts. Create it with exactly this template:

````markdown
# Workflow state — <TICKET>

```
ticket: <TICKET>
handoff_version: 1
review_scope_version: 1       # full delivery diff required for clean review and packaging             # new runs use validated JSON handoffs; absent on older runs
review_context_version: 2     # prepare known context and evidenced test-map assessment; new runs only
review_checks_version: 1      # required skill/rule and mapping assessment evidence; new runs only
feedback_evidence_version: 1  # numbered source packet and inspection coverage; new runs only
status: In Progress            # In Progress | Paused | Stopped | Complete
phase: context-check           # context-check | close-the-gaps | spec-approval | plan | plan-approval | execute | lightweight | review | fix-plan | final-sync | final-approval | complete
final_package_version: 1       # new runs build a content-bound final package; absent on older runs
acceptance_evidence_version: 1 # new TDD runs map requirement clauses to assertions/observations
verification_version: 1        # new runs persist per-step and AC evidence; absent on older runs
adaptive_version: 1            # new runs assess risk and choose a run mode; absent on older runs, which carry none of the fields through implementation_report below
risk: none                     # none | low | medium | high — none until assessed
mode: none                     # none | lightweight | tdd — low → lightweight; medium/high → tdd
mode_source: none              # none | assessed | user — user = forced by flag, chat, or spec-approval override
risk_rationale: none           # one line: the factors that drove the assessment, plus any override/disagreement note
escalations: 0                 # Lightweight → TDD escalations (limit 1)
implementation_report: none    # make-it-work/<TICKET>/<TICKET>-lightweight.md once Lightweight implementation ran
autonomy: guided               # effective mode for the current phase: guided | autonomous | autopilot; legacy runs may have pending
queued_autonomy: none          # none | guided | autonomous | autopilot; applies only at the next phase transition
refinement_destination: none    # none | here | slack-draft | slack-send; separate from autonomy and ticket updates
start_time: none                # ISO 8601 UTC timestamp captured when the state file is first created; never fabricated or backfilled
plugin_version: none            # exact version from this plugin's .claude-plugin/plugin.json, captured once at Start; never changed or backfilled
execution_mode: none            # none | subagent-driven | inline — set once execute's Mode-selection phase runs
inline_pause_mode: none         # none | stop-after-each-step | run-straight-through — set only when execution_mode is inline
spec: none
spec_hash: none
plan: none
plan_version: 1                # 1 = the initial plan; each replan adds 1
plan_hash: none
testing_readiness_version: 1    # parent completion checkpoint required before planning
testing_readiness: none         # readiness artifact path, resolved within Plan before stage planning
execution: not-started         # not-started | running | passed | verified-manually | guardrail | retry-limit | gate-failed | gate-no-result | stopped
review: not-started            # not-started | clean | fix-required | replan-required | human-decision
review_cycle: 0                # reviews run for the current plan version (limit = fix_cycle's limit + 1 = 4 — one initial review plus one re-review per fix-plan round)
fix_cycle: 0                   # fix-plan rounds for the current plan version (limit 3 — review_cycle's limit is derived from this one, see its own comment)
fix_plan_round_steps: none      # step count added by the current fix-plan round; reset to none when a new fix-plan round begins
fix_plan_dispatch: none         # none | sequential | parallel — dispatch order for the current fix-plan round's own added steps; reset to none when a new fix-plan round begins; never set for the original plan's own steps
replans_used: 0                # limit 2 per run
gate: none                     # none | full-suite | scoped | scoped+full
pause_reason: none
branch: <current branch>
base: <base branch>
head: <commit hash>
worktree_fingerprint: <hash>
execute_report: none           # path of the last saved execute report
context_updated: none
ticket_publication: none        # this run's publication-journal path; none/missing means no tracker writes
current_activity: none          # one-sentence, high-level description of what's actively being done right now; none while not In Progress, or before the active phase's first narrated sentence
current_activity_updated_at: none # host UTC timestamp saved by the activity helper; optional on older states
pending_inputs: []              # script-owned JSON records; blocking requests pause, optional requests preserve status
real_rows_from: 1               # Audit-log row number of the first row with a real (post-upgrade) timestamp; 1 for any run created under this feature. Set only by Resume, for a run whose state file predates this feature (see Resume).
```

## Known regressions

None

## Decided findings

None

## Context discoveries

None

## Audit log

| # | Time | From | To | Outcome / reason |
| --- | --- | --- | --- | --- |
````

**Checkpoint rule** — at every transition, rewrite the field block and append one row to the Audit log *before* starting the next phase. Immediately before that state-file write, capture the timestamp from the host clock with `date -u '+%Y-%m-%dT%H:%M:%SZ'` and copy that exact output verbatim into the row's `Time` cell. Do not use the session clock, infer a time, reuse an earlier capture, estimate, or back-fill a timestamp; the capture must be the final pre-write operation for that checkpoint, including the first row a run ever logs. This keeps the log aligned with the local clock that renders the dashboard. After every phase that changes files (close-the-gaps, plan, fix-plan, execute, lightweight, final-sync), re-record `head` and `worktree_fingerprint`. Whenever the user edits the spec or plan by hand at a pause, re-record `spec_hash` / `plan_hash` before the next phase starts. Immediately after rewriting the field block, also regenerate `make-it-work/<TICKET>/<TICKET>-status.html` from the fields just written — never let the two fall out of sync (see Progress dashboard below).

**Fingerprints:**

- `head` = `git rev-parse HEAD`.
- `worktree_fingerprint` = `git hash-object --stdin` over the concatenated output of `{ git diff HEAD --binary -- . ':!make-it-work'; git ls-files --others --exclude-standard -z -- . ':!make-it-work' | xargs -0 -I{} git hash-object {}; }` — the tracked diff's bytes, followed by one `git hash-object` line per untracked file in `git ls-files`'s stable sorted order, all piped through a single final `git hash-object --stdin` call. This is one exact, reproducible pipeline, not two separate hashes to combine by hand — so an edit inside a new, untracked file changes the fingerprint too, and the same repo state always produces the same fingerprint.
- `spec_hash` = `git hash-object <spec>`.
- `plan_hash` = the same, over the plan with its `## Execution Status` section (from that header to the next `## ` header) removed — `execute` owns and updates that section.

**Base branch** — `base` is the branch this work will merge into: `git symbolic-ref --short refs/remotes/origin/HEAD` without its `origin/` prefix, or `main` when that fails. Show it in the start summary so the user can correct it.

---

## Progress dashboard

Alongside the state file, maintain a human-readable static snapshot at `make-it-work/<TICKET>/<TICKET>-status.html`. Create it immediately after the first state-file write on Start → New run or Start → Pending offline refinement, then regenerate it after every later state mutation named by the Checkpoint rule or by a phase-specific instruction.

Dashboard rendering is deterministic code, not model-authored HTML. All ordinary dashboard refreshes must use the checkpoint helper — never edit a state field and then separately remember to invoke the renderer. Resolve `<base>` to this skill's directory exactly as in Stage skills, then run:

```sh
node "<base>/scripts/dashboard-checkpoint.mjs" render --state "make-it-work/<TICKET>/<TICKET>-state.md"
```

For a narration/activity update, use the helper's one operation instead of manually writing `current_activity`: `node "<base>/scripts/dashboard-checkpoint.mjs" activity --state "make-it-work/<TICKET>/<TICKET>-state.md" --activity "<exact narrated sentence or none>"`. The helper validates the state, saves `current_activity`, `current_activity_updated_at` and an Activity audit row together, then renders the dashboard. A render failure retains the saved audit evidence; retry the same activity to repair rendering without another row or timestamp change. Only an activity update changes its timestamp; rendering and decision checkpoints preserve it. An active phase without activity shows an explicit fallback, and an existing description without a timestamp shows `Last updated: unavailable`. State transitions and Audit-log edits still use their existing write procedure, followed by the helper's `render` operation.

The renderer owns parsing and validating the state and current plan, calculating timing and loop-aware timeline state, escaping state-derived content, reading the fixed logo and HTML template from this skill's assets, and atomically replacing `<TICKET>-status.html`. Never reproduce, patch, or hand-edit the generated HTML. Its inputs are the workflow state, the plan while step progress is needed, and, after completion, the optional delivery plan/progress journal. Delivery never changes implementation's Complete status, loop counters, or elapsed time. Its own journal drives the Deliver dot, repository results, timestamps and links; its helper regenerates existing dashboards after delivery checkpoints.

**Never backfill** — when Resume finds a run with no status file, do not invoke the renderer merely to add one. Only tickets whose state file was first created through one of the two creation paths above participate in dashboard updates. Once a participating ticket has a dashboard, every required regeneration uses the same command.

**Renderer failure** — a nonzero exit means the state or referenced plan violates the dashboard contract, or the dashboard could not be written. Do not enter the next phase and do not append a transition row describing progress that did not occur. Report the renderer's error, correct the source state/plan when the correction is unambiguous, and rerun the command. Because the renderer writes atomically, an existing dashboard remains intact on failure.

**Workflow decision audit:** read [references/workflow-decisions.md](references/workflow-decisions.md) at Start and Resume. Record every explicit user workflow choice from questions, chat or invocation options, including approvals, refusals, permission scope/revocation and channel selection. Decisions that change phase belong in that transition row; use `dashboard-checkpoint.mjs decision` for other decisions. Carry pre-state choices into the first row. Distinguish user choices from automatic policy/defaults, reference exact approved versions, preserve history and refresh the existing dashboard. Stages report choices to the main session before dependent work. The reference defines the shared input and resume contract; permission journals remain authoritative.

For controller runs, run `workflow.mjs init` alone and perform its `next_action`: send `next_action.text` unchanged as a standalone user-visible assistant response with no tool calls. Finish that response so Stop can confirm the runtime text; it continues a normal new run automatically without a user reply. Then follow `continuation` into Context check. Do not await acknowledgment. For the pending-offline path, include it in the existing documented stop message. Do not combine initialization and context checking in one tool call. For legacy creation paths, after successful dashboard creation, display a clickable Markdown link labeled **Open implementation dashboard**, targeting the actual HTML file's resolved absolute path. Wrap the link target in angle brackets when its path contains spaces. Present the link in assistant chat, not only in tool output or as a code-formatted path. Show it once, in whichever of Start's two creation points creates the state file first for this ticket (New run's first chat message, before Context Check; or Pending offline refinement's stop message). Never repeat it at later checkpoints, and never mention it for Resume. Providing the link does not require automatically opening a browser.

---

## Narration

Read and follow [references/activity.md](references/activity.md), including inside inline stages, testing readiness, and nested regression. Save each work description before the chunk starts. Before every subagent dispatch, checkpoint what the agent will do; keep that description visible while awaiting its result, then report the actual next activity. Subagents do not write workflow activity or edit HTML; legacy single-step Progress helpers retain their required dashboard refresh.

Before any stretch of work that involves several tool calls with no natural pause point in between — reading multiple files to investigate something, writing and running a batch of tests, applying a fix and re-verifying it — say one plain sentence describing the high-level activity about to happen, then proceed without further narration until that chunk's natural conclusion. Not a sentence per tool call, and not a sentence per tiny sub-step — just enough that the user always knows what's currently happening without having to infer it from a string of tool calls.

Each such sentence must use the dashboard checkpoint helper's `activity` operation to update the state file's `current_activity` field and regenerate the dashboard, so the same "what's happening right now" signal is visible to someone reading the dashboard async, not only someone reading live chat:

- `current_activity` holds exactly the sentence just said in chat, or `none`.
- Clear it and `current_activity_updated_at` back to `none` the moment a new phase becomes the active phase, before that phase's own first narrated sentence lands — a sentence from a finished phase must never linger under the next phase's dot.
- Clear both fields back to `none` whenever `status` moves to `Paused`, `Stopped` or `Complete` — nothing is actively being done while waiting on the user, and the existing pause-reason banner already covers that state. A narrated sentence resumes the next time real work actually does.
- Rendered on the dashboard only while `status: In Progress` (see Progress dashboard above).

**Worked example — Start's own checkpoints.** Start is the stretch of work most likely to be someone's first impression of this pipeline, and it runs through several tool calls (autonomy choice, branch guard, state-file/dashboard creation, Context check) with no interstitial text by default — apply the rule above explicitly here:

- After the branch guard resolves, say in one sentence what's about to happen, e.g. "Setting up the run — creating the state file and dashboard, then checking the project has the context this pipeline needs."
- After Context check's outcome (pass or stop), say so in one line before continuing.
- After Context check succeeds and any reuse/redo choice resolves, say what phase is starting next, e.g. "Starting refinement — I'll explore the relevant code and then ask clarifying questions." — before silently diving into Phase 2/3 code exploration.

---

## Start

**Workspace routing comes first:** read [references/workspace.md](references/workspace.md) before resolving a current branch or running the checks below. Resolve layout and artifact root with the shared helper. A workspace needs no root `CLAUDE.md` or `.git`. For workspace runs, run `find-the-repos` inline, preview the exact repositories and branch actions, and obtain explicit user approval in **every** autonomy mode before creating or switching branches. Run the early context precheck on the selected repositories before applying those branch actions. Then use the per-repository branch helper instead of the single-repo branch guard below. An existing workspace run resumes its saved contract before any new discovery or branch changes.

Resolve the ticket, current branch, base branch, and any existing state file before these checks. Work through them in order. A new run chooses autonomy before creating a branch; an existing run keeps its saved autonomy and goes through Resume before any branch change.

If this message explicitly requests a mode change, apply **Change autonomy during a run** before any saved-Autopilot or flag-mismatch shortcut below. Keep all branch/workspace comparisons and existing-run checks; a mode change does not approve Resume anyway, Redo, or Start over.

1. **Detached `HEAD`** → stop: tell the user to create or switch to a feature branch first. A run must never start on a detached HEAD — there is no branch for the work this run produces to live on.
2. **Existing run** — a state file exists:
   - `status: Complete` with an explicit request to sync/reconcile/retry **ticket updates for this completed run** → use the publication reference's completed-run path only. Preserve Complete, its artifacts and consent; do not start a new implementation, repeat stages or re-offer delivery. Report actual publication results and finish.
   - `status: Complete` with an explicit response to its saved delivery offer, or a request to continue its already opted-in preparation → follow Completion's delivery-response handling and inline `deliver` continuation below. Preserve Complete and its package; do not offer a new implementation or repeat the delivery opt-in question. A previously recorded opt-in is not exact-plan approval.
   - `status: Complete`, or `status: Stopped` with `phase: context-check` → ask whether to start a new run (the state file is overwritten) or stop. Under `--autopilot`, stop rather than overwriting the state or artifacts. A run that never got past Context Check produced no artifacts worth resuming. Only if the user chooses a new run, continue to Choose autonomy below.
   - Any other status → go to **Resume**. Do not ask for a fresh autonomy choice or create a branch before comparing the saved branch and workspace fingerprints.
3. **Early context precheck, then startup choices for a new run** — run the read-only **Early context precheck** below before autonomy, refinement-destination or publication questions. A known context blocker stops before initialization, consent or branch changes. Then complete **Choose autonomy** before constructing any destination question; never batch these into the same `AskUserQuestion` call. Then follow **Choose refinement destination**, before the branch guard: Guided/Autonomous ask unless a destination is already resolved; either Autopilot choice uses the documented default without prompting. Hold the resolved values and any scoped ticket-update selection until the state file is created; there is no state file or dashboard to update yet. Either Autopilot choice applies the same unattended policy as `--autopilot` from this point onward, including the branch guard and decision log. Autonomy does not supply a user destination choice; Autopilot's default is a policy resolution.
4. **Branch guard**:
   - **Current branch equals `base`** → compute a suggested branch name: `<TICKET>`; if `git rev-parse --verify --quiet refs/heads/<TICKET>` resolves (the name is already taken), try `<TICKET>-2`, `<TICKET>-3`, … incrementing until one does not resolve, and use that instead. Under the selected `autopilot` mode, choose `Create and switch to <suggested-name> (recommended)`, log that checkpoint, run `git switch -c <suggested-name>`, and stop with the command error if it fails — never proceed on the base branch. Otherwise ask with `AskUserQuestion` (`multiSelect: false`): *"You're on `<base>`. Where should this ticket's work go?"*, with these options:
     - Create and switch to `<suggested-name>` (recommended).
     - Create a branch with a different name.
     - Proceed on `<base>` anyway.
     - Stop.

     If the user picks **Create and switch to `<suggested-name>`**, that selection confirms the exact name: run `git switch -c <suggested-name>` immediately, without a second confirmation. If the user picks **Create a branch with a different name**, ask for the name and wait for their reply; use their answer as `<final-name>`, then run `git switch -c <final-name>`. If either command fails (e.g. the name became unavailable or the custom name is invalid), show the error and ask for a different name — never silently retry with a guessed alternative. Once the branch is created, continue to the next Start check.

     If the user picks **Proceed on `<base>` anyway**, continue to the next Start check without creating a branch.

     If the user picks **Stop**, stop here.
   - **Otherwise** → continue to the next Start check.
5. **Pending offline refinement** — `make-it-work/<TICKET>/<TICKET>-questions.md` exists with `**Status:** Awaiting Answers` → before writing the state, read `<base>/../../.claude-plugin/plugin.json` and capture its exact nonempty `version` value as `plugin_version`; if the manifest cannot be read or has no version, stop and report that error rather than creating an unattributed run. Then create the state file with the selected `autonomy`, `phase: close-the-gaps`, `status: Paused`, `pause_reason: offline refinement pending`, and a real captured timestamp in `start_time` (same capture rule as the Checkpoint rule's `Time` cell). Its first Audit-log row goes from `start` to `close-the-gaps` and records the autonomy choice, branch-guard outcome, and pending offline refinement. Create the progress dashboard (`make-it-work/<TICKET>/<TICKET>-status.html` — see Progress dashboard below), immediately presenting the returned `startup_message` (or the legacy **Open implementation dashboard** link) once in the next assistant stop message before further workflow tools, as specified above. For an explicitly supplied tracker ticket, perform the ticket-publication reference's Start and consent procedure before reporting the pause, with the same Autopilot/local-only rules as New run below; tell the user to finish `/make-it-work:close-the-gaps <that path>` and then run `implement` again; stop.
6. **New run**:
   - Capture a real timestamp into `start_time` (same capture rule as the Checkpoint rule's `Time` cell).
   - Before the first state-file write, read `<base>/../../.claude-plugin/plugin.json` and record its exact nonempty `version` value in `plugin_version`. Do not derive it from the cache directory name, package metadata in the target repository, or a chat message. If the manifest cannot be read or has no version, stop and report that error rather than creating an unattributed run. `plugin_version` is immutable for the run: every later checkpoint, resume, and feedback write preserves it unchanged.
   - Create the state file with `phase: context-check`, `status: In Progress`, the selected `autonomy` and resolved `refinement_destination`, and every other field at its template default (including `real_rows_from: 1`). Log the first Audit-log row: `From: start`, `To: context-check`, with an `Outcome / reason` recording the autonomy choice, refinement destination and its source, any `--mode` flag, and branch-guard outcome (e.g. `New Guided run; Refinement questions: here (user choice); branch <name> created per branch-guard choice` or `New Autopilot run; Refinement questions: here (policy default); proceeding on existing feature branch`). Fold these pre-state choices into this one row; no separate decision rows can be written before the state file exists.
   - Create the progress dashboard (`make-it-work/<TICKET>/<TICKET>-status.html` — see Progress dashboard below) from those fields. Immediately perform the initializer's standalone assistant-message action before calling any further tool. Finish that response so Stop confirms it and automatically continues Context check. Do not wait for acknowledgment at the link. For legacy initialization, use the clickable **Open implementation dashboard** link described above.
   - For an explicitly supplied tracker ticket, follow the ticket-publication reference's **Start and consent** procedure once. Save scoped consent separately from autonomy; publication unavailable, declined or unanswered leaves the implementation workflow local. Under Autopilot, use existing explicit permission or retain local without prompting. Do not configure a tracker for a local spec/pasted requirement without an explicit destination.
   - *Only then* run **Context check**. **If its outcome is "stop"** (no signal at all, or incomplete, per Context check's own Outcomes), set `status: Stopped` explicitly — not `Paused`: there is no mid-run point to resume into until the user has run `go-deep` externally and re-invokes `implement`, which is effectively a fresh attempt, not a resumable pause. Log this as the phase's own Audit-log row (`From`=`To`=`context-check`, `Outcome / reason`: the exact stop message shown to the user), regenerate the dashboard, then stop exactly as Context check's own Outcomes already specify.
   - If Context check succeeds, check whether `make-it-work/<TICKET>/<TICKET>-spec.md` and/or `make-it-work/<TICKET>/<TICKET>-plan.md` already exist from standalone runs. If so, show what was found and ask: reuse them and start at the next phase, or redo from that phase. Under `autopilot`, stop rather than choosing between stale artifacts.
   - **Close out Context check explicitly:** once the reuse/redo decision above resolves, update `phase` to the actual starting phase (`close-the-gaps` for a fresh spec, or `plan` for a reused spec/plan so testing readiness runs before execution). A reused plan is retained rather than redrafted unless readiness exposes a required change. In an adaptive run, first run Risk assessment on the reused spec: a reused plan keeps `mode: tdd` (`mode_source: user`, since reusing it chose TDD), while a reused spec alone goes to Spec approval in Guided (to show and confirm the mode) and otherwise starts at `lightweight` or `plan` by its mode. Log the closing Audit-log row `context-check → <that phase>` with an outcome describing the decision, then regenerate the dashboard. This flips the pre-activated `context-check` dot from `current` to `passed`.

---

## Context check

For `workspace_version: 1`, apply this check independently to each approved repository from `workspace_contract`; no root workspace context is required, and unselected siblings are excluded. Pass the explicit repo root to each inventory call. The controller enforces the same checks at `context-ready`.

Run `node "<base>/../../scripts/context-inventory.mjs" inspect --root <project-root>` under [the inventory contract](../../docs/deterministic-artifacts.md#documentation-inventory). Its signals/completeness/missing paths drive the following outcomes; do not manually recreate those filesystem checks. Workspace structure and affected-repo discovery retain their existing rules.

`implement` needs the project context `go-deep` builds, and checks for it in two layers:

- **Signals** (the same ones `go-deep`'s own prior-run detection uses): a `uc-*` or `domain-*` directory under `.claude/skills/`; a `CLAUDE.md` containing a Skill Loading Gate, Skills Reference, or After Any Feature Change section; `.claude/rules/architecture.md` or `.claude/rules/product.md`.
- **Completeness:** `CLAUDE.md` containing the Skill Loading Gate, `.claude/rules/architecture.md`, `.claude/rules/product.md`, and at least one `.claude/skills/domain-*/SKILL.md`.

Outcomes:

- **No signal at all** → stop: "No project context found. Run `/make-it-work:go-deep` first, then rerun this pipeline. Alternatively, explicitly request direct implementation outside the pipeline."
- **Some signals, but incomplete** → stop, list exactly which pieces are missing, and point the user to `go-deep`'s "Repair existing docs" mode.
- **Complete** → continue.

Test strategy (absence never stops Context check): check the same root, and when it is a workspace root, each repo directory under it. Record repos with missing or old strategies for testing readiness before planning:

- **Missing** → report: "No test-strategy skill — testing readiness will discover or establish the setup before planning."
- **Older strategy without `## Test Map`** → report: "Testing readiness will regenerate the strategy and map from current tests and documentation. Obsolete rules/pointers require manual cleanup." Do not convert or delete old rule files.

Show any warning with Context check's outcome and record it in the closing context-check Audit-log row.

Never run `go-deep` yourself.

---

## Early context precheck

After resolving the repository set and checking whether this is a new or resumed run, run `node "<base>/../../scripts/context-inventory.mjs" inspect --root <repo-root>` for each selected repository before optional startup questions, branch changes, journal initialization or publication consent. Use the same inventory and completeness requirements as Context check. Do not inspect unselected siblings or require workspace-root context. An existing run keeps its saved Resume path rather than being treated as a fresh start.

If any selected repo is incomplete, stop before creating a run. Name the repo and exact missing pieces: no signals means run `/make-it-work:go-deep` first; partial context means its repair mode. Explain the alternatives up front: provide the required context and rerun the pipeline, or explicitly request a separate direct implementation outside this pipeline. Do not automatically start either alternative, run go-deep, or bypass the context gate. State that no new run or ticket-update consent was created. Any essential repository-selection question still precedes this precheck; defer branch application until it passes.

Keep the inventory result for the ordinary post-initialization Context check; rerun only if the selected roots or context files changed. The controller still enforces completeness at `context-ready`. This is a cheap read-only precondition check, not another user question, agent or onboarding stage.

## Choose autonomy

For a new run, ask once before the branch guard with a single `AskUserQuestion` containing only the autonomy question, and wait for its answer before constructing any dependent startup prompt. Hold the answer for the first state-file write. An explicit chat mode selection supplies that answer directly; otherwise `--autopilot` skips the question and selects `autopilot` without granting ticket-write consent. Both interactive Autopilot choices use the same execution policy, including automatic creation of the suggested branch on the base branch. Initialize and append the autopilot decision log as described in Autopilot mode.

When the question will be shown and the user supplied an explicit tracker ticket/destination, first perform the publication reference's read-only target/capability discovery. If the exact issue/site, original description and at least one usable write operation are available, include the fourth option below. This discovery does not initialize a journal, write to a tracker or change the branch. Omit the combined option for local specs/pasted requirements without an explicit destination, ambiguous/inaccessible tickets, or connectors without usable write capabilities. Failed discovery does not block the ordinary three choices.

- **Guided (Recommended)** — pauses for approval after the spec (with the assessed run mode), after the plan when the run has one, and for every human decision.
- **Autonomous** — no approval gates, and replans automatically when the plan stops holding. It still asks every question a stage asks and every uncertain regression, and stops at the loop limits and at completion.
- **Autopilot** — runs without approval or stage-question prompts, with ticket updates off unless separately explicitly authorized. It uses the policy in Autopilot mode and stops safely when no documented default exists.
- **Autopilot + update ticket** — when eligible, the same unattended implementation plus updates to **<issue> at <site>**: refined description replacement after preserving each nonempty description being replaced in an original-description comment, accepted plans as attachments or comments when uploads are unavailable, significant blocker comments, implementation/review/verification summaries and one final HTML dashboard attachment at completion for Jira where uploads are supported. Name the actual supported operations and anything unavailable in this option's description or question body, so selection authorizes a concrete scope. Comments-only connectors remain eligible; their offer excludes description replacement and uploads. If backup comments are unavailable, exclude nonempty description replacement too.

Offer the three ordinary choices plus the combined option only when eligible. Keep **Guided (Recommended)** as the recommended default. Both Autopilot choices persist `autonomy: autopilot`; do not add a fourth autonomy enum, dispatch flag or execution policy.

The combined choice is explicit user consent, never an auto-resolved default. Hold its exact answer, target and granted operations until Start creates the workflow state. Then follow the publication reference's initialization and `consent` procedure, saving `allowed` and `artifact_comments` for that disclosed scope and refreshing the dashboard; do not ask a second ticket-write consent question. Guided/Autonomous retain their separate publication offer. Plain Autopilot supplies no write consent and does not trigger another publication question. A later explicit scope instruction takes precedence; Resume preserves this run's saved scope instead of re-offering startup choices. If the selected target/capabilities become unavailable before consent can be saved, retain local artifacts and report the limitation without claiming updates are enabled or broadening the target.

## Choose refinement destination

Follow [references/refinement-destination.md](references/refinement-destination.md) after choosing autonomy and before dispatching refinement. Guided and Autonomous explicitly choose where questions go even when Slack is unavailable; discover deferred Slack tools before offering supported actions and explain any limitation. Persist the choice in `refinement_destination` independently from autonomy and ticket consent. For either Autopilot choice, `--autopilot`, or an explicit chat selection of Autopilot, do not show a destination question: retain an explicit destination or default to `here` as policy. That default never enables live product questions during Autopilot; unresolved required facts follow the stage's documented hard-stop policy. Skip destination resolution for an existing pending questions file or a spec already accepted for reuse; neither needs a new refinement message.

---

## Resume

If `ticket_publication` names a journal, read it using the publication reference before any further tracker write. Retain consent and successful-operation IDs; reconcile interrupted writes rather than replaying them. Missing/`none` stays local without another consent offer unless the user explicitly asks to enable publication. Publication permission decisions are resume-transparent under the workflow-decision contract; use the checkpoint helper's `resume` result when identifying the last work row. Publication failures never bypass the workspace/resume checks below.

Compare the current `branch`, `head`, `worktree_fingerprint`, `spec_hash`, and `plan_hash` against the state file.

An explicit mode-change request queues the selection before the saved-mode rules below; the old invocation flag cannot overwrite it or cause a mode-mismatch stop. Effective autonomy remains unchanged until the next phase transition. Without such a request, retain the existing flag-mismatch behavior. For Resume's last-row classification, run `dashboard-checkpoint.mjs resume --state <state-path>` and use `last_work_row`, per the workflow-decision contract. It ignores explicitly transparent same-phase decisions and legacy autonomy/publication rows; other decisions still preserve interruption evidence. Keep all other interruption checks. Once a clean resume is established, do not offer another mode choice when this message already selected it. If there is no new selection, retain the saved mode, including any mode applied at an earlier phase boundary; retain its queued selection separately.

- **Paused on `Slack refinement pending`, with nothing else changed** → this takes precedence over the buckets below. Show one line saying the run is waiting on the Product Manager's Slack replies, then resume as Close the gaps → Resuming a Slack pause describes. Changes inside `make-it-work/` (such as the user answering the questions file by hand) don't count as changes. Anything else changed → the last bucket below.
- **Nothing changed, and the last work row returned by the checkpoint helper closed its phase** (that row's `From` differs from its `To`; other same-phase decision rows still never count as closing a phase) → show one line (current phase and autonomy level), offer to change the autonomy level in Guided or Autonomous, then continue at `phase`. If `--autopilot` was supplied without an explicit chat mode-change request, continue only when the saved autonomy is `autopilot`; otherwise stop rather than changing its mode. If the saved autonomy is `autopilot`, retain it and continue without asking, even when the current invocation omitted the flag. This bucket never applies while `phase: context-check`, even when its one logged row (`start → context-check`) technically has `From ≠ To` — that row only records *entering* Context Check, and Context Check's own mandatory follow-on orchestration (the reuse/redo prompt and the closing row) may not have run yet; a `phase: context-check` state always falls to the next bucket instead.
- **Interrupted mid-`context-check`, mid-`close-the-gaps`, mid-`review`, or mid-`final-sync`, with nothing else changed** → these phases are safe to repeat: tell the user, then re-run that phase from its start. For `context-check` specifically, "from its start" means re-entering Start check #6 at its "run Context check" bullet and continuing through it exactly as a New run would — the reuse/redo prompt and the explicit closing row/phase-update — since that orchestration lives in Start, not in a `## Phases` subsection of its own. Keep the saved autonomy; only a legacy state still reading `autonomy: pending` needs Choose autonomy before rerunning Context check, then a same-phase decision row recording the choice and a dashboard refresh.
- **Anything changed, or the run was interrupted mid-`plan`, mid-`fix-plan`, mid-`execute`, or mid-`lightweight`** (the phase started but has no closing log row) → list exactly what differs, then ask; when the current autonomy is `autopilot`, stop rather than choosing among Resume anyway, Redo, or Start over:
  - **Resume anyway** — re-record the fingerprints and continue. For an

[…] pełny plik w paczce .zip

• SKILL.md 137 KB
• assets/insideout-ai-logo-base64.txt 9 KB
• assets/status-template.html 1 KB
• references/activity.md 6 KB
• references/autonomy-changes.md 6 KB
• references/controller.md 26 KB
• references/feedback.md 40 KB
• references/final-sync-mapping.md 6 KB
• references/handoffs.md 11 KB
• references/lightweight-fix.md 4 KB
• references/planning-tests.md 5 KB
• references/refinement-destination.md 6 KB
• references/review-checks.md 3 KB
• references/testing-readiness.md 14 KB
• references/ticket-publication.md 31 KB
• references/verification.md 13 KB
• references/workflow-decisions.md 10 KB
• references/workspace.md 10 KB
• scripts/acceptance-summary.mjs 1 KB
• scripts/acceptance-summary.test.mjs 2 KB
• scripts/artifact-layout.mjs 1 KB
• scripts/assurance-summary.mjs 2 KB
• scripts/assurance-summary.test.mjs 4 KB
• scripts/audit-notes.mjs 2 KB
• scripts/context-maintenance.mjs 4 KB
• scripts/context-maintenance.test.mjs 3 KB
• scripts/dashboard-checkpoint.mjs 8 KB
• scripts/deliver.mjs 22 KB
• scripts/deliver.test.mjs 24 KB
• scripts/delivery-progress.mjs 5 KB
• scripts/feedback-evidence.mjs 7 KB
• scripts/feedback-evidence.test.mjs 5 KB
• scripts/feedback-finalization.mjs 2 KB
• scripts/feedback-handoff.mjs 17 KB
• scripts/feedback-handoff.test.mjs 12 KB
• scripts/feedback-progress.mjs 3 KB
• scripts/feedback-receipts.mjs 2 KB
• scripts/feedback-receipts.test.mjs 6 KB
• scripts/final-package.mjs 21 KB
• scripts/final-package.test.mjs 34 KB
• scripts/handoff.mjs 26 KB
• scripts/handoff.test.mjs 32 KB
• scripts/hook-feedback.mjs 5 KB
• scripts/hook-feedback.test.mjs 6 KB
• scripts/implementation-guard.mjs 7 KB
• scripts/implementation-guard.test.mjs 4 KB
• scripts/lightweight-fix.mjs 7 KB
• scripts/lightweight-fix.test.mjs 7 KB
• scripts/manual-waiver.mjs 2 KB
• scripts/manual-waiver.test.mjs 6 KB
• scripts/pending-input.mjs 7 KB
• scripts/pending-input.test.mjs 27 KB
• scripts/planning-tests.mjs 8 KB
• scripts/planning-tests.test.mjs 14 KB
• scripts/render-status.mjs 57 KB
• scripts/render-status.test.mjs 75 KB
• scripts/review-checks.mjs 5 KB
• scripts/review-checks.test.mjs 2 KB
• scripts/review-scope.mjs 10 KB
• scripts/review-scope.test.mjs 17 KB
• scripts/startup-confirmation.mjs 4 KB
• scripts/startup-presentation.mjs 16 KB
• scripts/startup-presentation.test.mjs 48 KB
• scripts/testing-policy.mjs 5 KB
• scripts/testing-policy.test.mjs 4 KB
• scripts/testing-readiness.mjs 9 KB
• scripts/testing-readiness.test.mjs 11 KB
• scripts/ticket-publication.mjs 27 KB
• scripts/ticket-publication.test.mjs 42 KB
• scripts/verification.mjs 15 KB
• scripts/verification.test.mjs 13 KB
• scripts/workflow-decisions.mjs 3 KB
• scripts/workflow-integration.test.mjs 15 KB
• scripts/workflow.mjs 53 KB
• scripts/workflow.test.mjs 37 KB
• scripts/workspace-scope.mjs 12 KB
• scripts/workspace-scope.test.mjs 11 KB
• scripts/workspace-view.mjs 4 KB
• scripts/write-feedback.mjs 44 KB
• scripts/write-feedback.test.mjs 34 KB