lastlight 0.1.15 → 0.2.1

package/workflows/prompts/pr-fix.md

@@ -1,8 +1,8 @@
 You are fixing a PR based on a maintainer's request.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
-2. Read CLAUDE.md and AGENTS.md if they exist
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned the PR's head ref and your cwd is the repo root. Git is configured.
+Read CLAUDE.md (and CONTRIBUTING.md if present) for project-specific guidance.
 
 CONTEXT:
 - PR #{{prNumber}}: {{prTitle}}
@@ -13,10 +13,9 @@ NOTE: The CI failures above are the primary issue — fix those first.
 {{/if}}
 INSTRUCTIONS:
 1. Understand what the maintainer is asking for
-2. Read the relevant code and understand what needs to change
-3. Make the fix — keep changes minimal and focused
-4. Run tests, lint, and typecheck to verify everything passes
-5. DO NOT commit until all checks pass
+2. Read the relevant code and make the fix — keep changes minimal and focused
+3. Follow the **building** skill: install dependencies, then run the full
+   test/lint/typecheck gate — do NOT commit until it all passes
 
 AFTER FIXING:
 1. git add -A && git commit -m "fix: address feedback on PR #{{prNumber}}

package/workflows/prompts/pr.md

@@ -1,6 +1,6 @@
 Create a pull request for the work on branch {{branch}}.
 
-Use the MCP tool create_pull_request with the following:
+Use the MCP tool github_create_pull_request with the following:
 - owner: {{owner}}
 - repo: {{repo}}
 - head: {{branch}}
@@ -14,14 +14,14 @@ Use the MCP tool create_pull_request with the following:
   (3-6 bullet points describing what changed)
 
   ## Planning and execution docs
-  - [Guardrails report]({{branchUrl guardrails-report.md}})
-  - [Architect plan]({{branchUrl architect-plan.md}})
-  - [Executor summary]({{branchUrl executor-summary.md}})
-  - [Reviewer verdict]({{branchUrl reviewer-verdict.md}})
-  - [Status]({{branchUrl status.md}})
+  - [Guardrails report]({{artifactUrl guardrails-report.md}})
+  - [Architect plan]({{artifactUrl architect-plan.md}})
+  - [Executor summary]({{artifactUrl executor-summary.md}})
+  - [Reviewer verdict]({{artifactUrl reviewer-verdict.md}})
+  - [Status]({{artifactUrl status.md}})
 
   Before adding each link above, run `ls -1 {{issueDir}}/`
-  on the branch and OMIT any line whose file doesn't exist on disk. Use the
+  and OMIT any line whose file doesn't exist on disk. Use the
   exact full https URLs above as written — do NOT shorten to relative paths,
   they will not render in the PR description.
 
@@ -30,9 +30,10 @@ Use the MCP tool create_pull_request with the following:
 
 Note: There are unresolved reviewer issues after {{review.cycles}} fix cycles. See reviewer-verdict.md on the branch.{{/if}}
 
-Then use add_issue_comment on issue #{{issueNumber}} to post the PR link.
+Do NOT post a comment with the PR link — the harness adds it to the status
+checklist on the issue automatically. Just create the PR.
 
 Update status.md: current_phase = complete, add pr_number.
-git add .lastlight/ && git commit -m "status: PR created for #{{issueNumber}}" && git push origin HEAD
+{{#if !externalizeArtifacts}}git add .lastlight/ && git commit -m "status: PR created for #{{issueNumber}}" && git push origin HEAD{{/if}}{{#if externalizeArtifacts}}Do NOT git add or commit {{issueDir}}/ — the harness persists it to the Last Light server automatically.{{/if}}
 
-OUTPUT: The PR number and URL.
+OUTPUT: The PR number and URL (so the harness can link the PR from the checklist).

package/workflows/prompts/qa-browser.md

@@ -0,0 +1,95 @@
+You are running the **browser-QA pass** of a qa-test run — driving the target
+through its flow in a **real headless browser** and capturing **screenshot
+evidence** for each step. A text-evidence QA run already ran and posted its
+per-step report; your job is to add visual proof for the steps that exercise a
+rendered UI. Read the `browser-qa` skill for the driver contract and the
+`qa-test` skill for the flow procedure and report shape, then follow them. The
+`building` skill installs and runs the repo.
+
+**Stay in the browser.** Do **not** read, quote, or analyse the repo's source
+code — the text pass already covered it. Your evidence is strictly what the
+browser shows: the driver's extracted text, assertion results, console errors,
+and the screenshots. No code walkthroughs.
+
+## What to test
+
+{{#if commentBody}}
+**Target / steps / request:**
+{{commentBody}}
+{{/if}}
+{{#if issueTitle}}**Issue/PR title:** {{issueTitle}}{{/if}}
+{{#if issueBody}}
+**Issue/PR body:**
+{{issueBody}}
+{{/if}}
+
+Target repo: **{{owner}}/{{repo}}**
+{{#if issueNumber}}Target issue/PR: **#{{issueNumber}}**{{/if}}
+
+If the target is a CLI or a pure API with no UI, the text pass already covered
+it — keep this pass short and say no browser evidence was needed. Focus on flows
+that actually render a UI.
+
+## First: confirm the browser is available
+
+Run the driver's probe before anything else:
+
+```
+node <browser-qa skill dir>/scripts/agent-browser.mjs doctor
+```
+
+(The `browser-qa` skill is staged into this phase's skill bundle — find its
+absolute path from the available-skills catalogue.) If `doctor` exits non-zero,
+the browser toolchain isn't present: say so plainly and stop — do not fake
+screenshots. This phase only runs on the docker QA image, so `doctor` should
+pass.
+
+## Workspace + run the app
+
+You are already inside the **{{repo}}** repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root (no `cd`). If this is a PR, read the
+diff and design a flow that exercises what changed. Follow the `building` skill
+to install and start the app's dev-server in the background; wait until it's
+listening on `localhost`.
+
+## Drive the flow and capture evidence
+
+State the steps and their success criteria first. Author a `flow.json` (shape
+documented in the `browser-qa` skill), then run `agent-browser.mjs run flow.json
+--base-url http://localhost:<port> --out-dir {{issueDir}}`, capturing a
+screenshot at each decisive step. Save every screenshot under **`{{issueDir}}/`**
+— the harness harvests that directory. Parse the JSON report (per-step status,
+extracted text, assertion results, console errors) — that, not the images, is
+what you reason over. On a step failure continue to the next step unless it
+blocks everything downstream; treat console/page errors as findings.
+
+## How your report is delivered — read carefully
+
+Your **final message is the report**, and the harness posts it for you{{#if issueNumber}} as
+a comment on **#{{issueNumber}}**{{/if}}{{#if !issueNumber}} back into the thread this request came from{{/if}}.
+Title it clearly as the **browser-QA evidence** so it reads as a supplement to
+the text report, not a competing one. Use the `qa-test` report shape
+(Environment / Results table / Issues found / Coverage). Every defined step gets
+a row and a result.
+
+**Keep it tight** — a one-line environment summary, the results table (one row
+per step, terse Evidence cell), the inline screenshots, any issues found, and a
+short "what was / wasn't exercised". No per-step narration or code analysis.
+
+**Embed each step's screenshot inline** in its Evidence cell so it renders in
+the comment.
+{{#if artifactBaseUrl}}Every PNG you saved to `<name>.png` is served publicly at
+`{{artifactBaseUrl}}/<name>.png`. Put a **raw Markdown image** in the Evidence
+cell — `!` then `[caption]` then the URL in parentheses — with no backticks and
+no code fence (inside a code span it shows as literal text instead of
+rendering). For example, a screenshot saved as `step-2.png` becomes: an
+exclamation mark, `[Step 2]`, then `({{artifactBaseUrl}}/step-2.png)` with no
+spaces and no backticks.{{/if}}{{#if !artifactBaseUrl}}No public URL is
+configured, so reference each screenshot by filename (e.g. `step-2-cart.png`)
+and note it's in the run's Artifacts view.{{/if}}
+
+**Do NOT post it yourself** with `github_add_issue_comment` — that would
+double-post. Never claim a step passed that you didn't run, and never fabricate
+a screenshot. If screenshots couldn't be persisted (no server-mode build
+assets), still report the per-step DOM/text observations and say the images
+weren't retained.

package/workflows/prompts/qa-synth.md

@@ -0,0 +1,44 @@
+You are writing the **single final QA report** for a qa-test run. Two passes
+have already run: a text-evidence QA flow and (sometimes) a browser-QA pass.
+Your job is to **synthesize them into one concise report** — the reader sees
+only your output, not the individual passes.
+
+This is a **pure writing task**. Do **not** run commands, install anything, read
+repo files, or start a server — everything you need is below. Do **not** post a
+comment yourself (`github_add_issue_comment`); your final message *is* the
+comment, delivered by the harness.
+
+## What was tested
+
+{{#if commentBody}}{{commentBody}}{{/if}}{{#if issueTitle}} (issue/PR: {{issueTitle}}){{/if}}
+
+## Text QA report
+
+{{qaResult}}
+
+{{#if qaBrowserResult}}
+## Browser-QA report (real headless browser + screenshots)
+
+{{qaBrowserResult}}
+{{/if}}
+
+## Write the report
+
+Produce a tight Markdown comment:
+
+- A **single results table** (`| Step | Status | Evidence |`) covering every
+  step exercised across both passes. When the same step ran in both, prefer the
+  browser result for rendered-UI steps and note the text result only if it adds
+  something. Mark untested/blocked steps honestly.
+{{#if qaBrowserResult}}- **Embed each step's screenshot inline** in its Evidence cell exactly as it
+  appears in the browser-QA report above (the `![caption](https://…/<name>.png)`
+  image Markdown) so it renders in this comment. Keep them; don't turn them into
+  plain links or drop them.{{/if}}
+- A short **Issues found** list (each real FAIL with expected vs observed), or
+  "none" if clean.
+- A one-line **coverage** note: what was exercised, and anything notable that
+  wasn't.
+
+Keep it short — no per-step narration outside the table, no restating both
+reports in full. Surface real failures plainly; never claim a step passed that
+neither pass actually ran.

package/workflows/prompts/qa-test.md

@@ -0,0 +1,60 @@
+You are running a **QA test flow** — driving a target through a sequence of
+steps and reporting step-level pass/fail with evidence. Read the `qa-test` skill
+for the full procedure, then follow it. It uses the `building` skill for
+installing and running the repo. This prompt gives you the target/steps and how
+your report is delivered.
+
+## What to test
+
+{{#if commentBody}}
+**Target / steps / request:**
+{{commentBody}}
+{{/if}}
+{{#if issueTitle}}**Issue/PR title:** {{issueTitle}}{{/if}}
+{{#if issueBody}}
+**Issue/PR body:**
+{{issueBody}}
+{{/if}}
+
+Target repo: **{{owner}}/{{repo}}**
+{{#if issueNumber}}Target issue/PR: **#{{issueNumber}}**{{/if}}
+
+If specific steps are given (often after `--`), use them. Otherwise, if this is a
+PR, read the diff and design a flow that exercises what changed. State the steps
+and their success criteria before running.
+
+## Workspace
+
+You are already inside the **{{repo}}** repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured; no clone, no
+`cd`.
+
+## Evidence — what you can and can't drive
+
+You have **bash, file read, and the github tools** — no browser, no
+screenshots. QA a **CLI** directly, or a **web service** by starting its
+dev-server in the background and exercising it with `curl` (status codes,
+bodies, headers). Capture stdout/stderr and exit codes as per-step evidence.
+
+If the **whole target is a rendered UI** (the flow only makes sense in a
+browser), don't install/build to guess at it — a browser-QA pass runs after you
+and owns it. Note in one line that it's UI-shaped and deferred, and stop. For a
+**mixed** flow, drive the text/CLI/API steps here and mark only the
+rendered-UI steps **BLOCKED** (deferred to browser QA) rather than faking a
+result. On a step failure, continue to the next step unless it blocks
+everything downstream.
+
+## How your report is delivered — read carefully
+
+Your **final message is the report**, and the harness posts it for you:
+{{#if issueNumber}}
+- as a comment on **#{{issueNumber}}**.
+{{/if}}
+{{#if !issueNumber}}
+- back into the thread this request came from.
+{{/if}}
+
+Make your final message the complete QA report in the shape the `qa-test` skill
+defines (Environment / Results table / Issues found / Coverage). **Do NOT post
+it yourself** with `github_add_issue_comment` — that would double-post. Report
+real failures as failures; never claim a step passed that you didn't run.

package/workflows/prompts/re-reviewer.md

@@ -1,7 +1,7 @@
 You are the CODE REVIEWER — RE-REVIEW after fix cycle {{fixCycle}}.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured.
 
 This is a FOLLOW-UP review. You previously requested changes. The executor has attempted to fix them.
 
@@ -10,17 +10,16 @@ SCOPE — review ONLY what changed in the fix cycle:
 2. Read the "## Fix Cycle {{fixCycle}}" section in {{issueDir}}/executor-summary.md — what was fixed
 3. Diff only the fix commit(s): git log --oneline -3 and git diff HEAD~1
 
-CHECK:
-1. Were the specific issues you raised actually addressed?
-2. Did the fix introduce any new problems?
-3. Do tests still pass?
-
-DO NOT re-review the entire changeset. Only verify your previous issues were fixed.
+Verify your previous issues were actually addressed and the fix introduced no new
+problems (apply the **code-review** rubric to the fix). Do NOT re-review the
+entire changeset. Tests: the fix cycle already ran the full suite (see its
+summary section) — for independent signal, follow the **building** skill to run
+the typecheck command and the tests covering the fixed files.
 
 AFTER REVIEW:
 1. APPEND to {{issueDir}}/reviewer-verdict.md under heading "## Re-review after Fix Cycle {{fixCycle}}" (preserve the original verdict above). The new section MUST itself contain a "VERDICT: APPROVED" or "VERDICT: REQUEST_CHANGES" line.
 2. Update status.md with reviewer_status: APPROVED or REQUEST_CHANGES
-3. git add .lastlight/ && git commit -m "review: re-review after fix cycle {{fixCycle}} for #{{issueNumber}}" && git push origin HEAD
+{{#if !externalizeArtifacts}}3. git add .lastlight/ && git commit -m "review: re-review after fix cycle {{fixCycle}} for #{{issueNumber}}" && git push origin HEAD{{/if}}{{#if externalizeArtifacts}}3. Do NOT git add or commit {{issueDir}}/ — the harness persists it to the Last Light server automatically.{{/if}}
 
 OUTPUT FORMAT — your stdout MUST start with one of these two lines, EXACTLY, on its own line, with no leading whitespace:
 

package/workflows/prompts/reviewer.md

@@ -1,7 +1,7 @@
 You are the CODE REVIEWER. Independent verification — you have NO shared context with the executor.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured.
 
 SCOPE — review ONLY changed files:
   git log --oneline main..HEAD
@@ -10,13 +10,14 @@ SCOPE — review ONLY changed files:
 
 Read {{issueDir}}/architect-plan.md and executor-summary.md for context.
 
-CHECK:
-1. Does implementation match the plan?
-2. Do tests pass?
-3. Security concerns?
-4. Logic errors or missed edge cases?
+Apply the **code-review** skill's rubric (finding tiers + what to check), scoped
+to the changed files, and confirm the implementation matches the plan. Do NOT
+review unchanged files or flag pre-existing issues.
 
-DO NOT review unchanged files or flag pre-existing issues.
+Tests: the executor already ran the FULL suite and pasted results in
+executor-summary.md — review that output rather than re-running everything. For
+your own independent signal, follow the **building** skill to run the typecheck
+command and the tests covering the changed files.
 
 AFTER REVIEW:
 1. Write {{issueDir}}/reviewer-verdict.md with the following structure (exact headings):
@@ -38,7 +39,7 @@ AFTER REVIEW:
    (paste actual output)
 
 2. Update status.md with reviewer_status: APPROVED or REQUEST_CHANGES (matching the verdict)
-3. git add .lastlight/ && git commit -m "review: verdict for #{{issueNumber}}" && git push origin HEAD
+{{#if !externalizeArtifacts}}3. git add .lastlight/ && git commit -m "review: verdict for #{{issueNumber}}" && git push origin HEAD{{/if}}{{#if externalizeArtifacts}}3. Do NOT git add or commit {{issueDir}}/ — the harness persists it to the Last Light server automatically.{{/if}}
 
 OUTPUT FORMAT — your stdout MUST start with one of these two lines, EXACTLY, on its own line, with no leading whitespace:
 

package/workflows/prompts/verify-browser.md

@@ -0,0 +1,93 @@
+You are running the **browser-QA pass** of a verify run — driving the claim's
+behaviour in a **real headless browser** and capturing **screenshot evidence**.
+A text-evidence verify already ran and posted its verdict; your job is to add
+visual proof (or to settle a claim that can only be shown in a rendered UI).
+Read the `browser-qa` skill for the driver contract and the `verify` skill for
+the investigator rules, then follow them. The `building` skill installs and runs
+the repo.
+
+**Stay in the browser.** Do **not** read, quote, or analyse the repo's source
+code — the text pass already covered the code. Your evidence is strictly what
+the browser shows: the driver's extracted text, assertion results, console
+errors, and the screenshots. No `index.html`/CSS walkthroughs, no "from the
+checked-in code" observations.
+
+## The claim to test
+
+{{#if commentBody}}
+**Claim / request:**
+{{commentBody}}
+{{/if}}
+{{#if issueTitle}}**Issue/PR title:** {{issueTitle}}{{/if}}
+{{#if issueBody}}
+**Issue/PR body:**
+{{issueBody}}
+{{/if}}
+
+Target repo: **{{owner}}/{{repo}}**
+{{#if issueNumber}}Target issue/PR: **#{{issueNumber}}**{{/if}}
+
+If the claim is purely about non-UI behaviour (a CLI, an API response, a pure
+function) the text pass already covered it — keep this pass short: note that the
+claim isn't UI-shaped and that no browser evidence was needed. Spend the effort
+where a rendered UI is the only place the claim shows.
+
+## First: confirm the browser is available
+
+Run the driver's probe before anything else:
+
+```
+node <browser-qa skill dir>/scripts/agent-browser.mjs doctor
+```
+
+(The `browser-qa` skill is staged into this phase's skill bundle — find its
+absolute path from the available-skills catalogue.) If `doctor` exits non-zero,
+the browser toolchain isn't present: say so plainly and stop — do not fake
+screenshots. This phase only runs on the docker QA image, so `doctor` should
+pass.
+
+## Workspace + run the app
+
+You are already inside the **{{repo}}** repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root (no `cd`). For a PR claim, check out
+the PR head. Follow the `building` skill to install and start the app's
+dev-server in the background; wait until it's listening on `localhost`.
+
+## Drive the UI and capture evidence
+
+Author a `flow.json` (shape documented in the `browser-qa` skill), then run
+`agent-browser.mjs run flow.json --base-url http://localhost:<port>
+--out-dir {{issueDir}}`. Save every screenshot under **`{{issueDir}}/`** — the
+harness harvests that directory. Parse the JSON report (extracted text,
+assertion results, console errors) — that, not the images, is what you reason
+over. For a before/after regression claim, capture both states.
+
+## How your report is delivered — read carefully
+
+Your **final message is the report**, and the harness posts it for you{{#if issueNumber}} as
+a comment on **#{{issueNumber}}**{{/if}}{{#if !issueNumber}} back into the thread this request came from{{/if}}.
+Title it clearly as the **browser-QA evidence** so it reads as a supplement to
+the text verdict, not a competing one. Use the `verify` report shape
+(Environment / Evidence / **Conclusion: CONFIRMED | REFUTED | INCONCLUSIVE**).
+
+**Keep it tight** — a one-line environment summary, the evidence (screenshots +
+the key assertion/text/console results), and a one-sentence conclusion. No
+per-step narration, no code analysis, no long Coverage prose; a short
+"what was / wasn't exercised" is enough.
+
+**Embed each screenshot inline** so it renders in the comment.
+{{#if artifactBaseUrl}}Every PNG you saved to `<name>.png` is served publicly at
+`{{artifactBaseUrl}}/<name>.png`. Write a **raw Markdown image** for each one
+under Evidence — `!` then `[caption]` then the URL in parentheses — on its own
+line. Do **NOT** wrap it in backticks or a code fence; inside a code span it
+shows as literal text instead of rendering. For example, a screenshot saved as
+`home.png` becomes a line reading: an exclamation mark, `[Home]`, then
+`({{artifactBaseUrl}}/home.png)` with no spaces and no backticks.{{/if}}{{#if !artifactBaseUrl}}No
+public URL is configured, so reference each screenshot by filename (e.g.
+`after-login.png`) and note it's in the run's Artifacts view.{{/if}}
+
+**Do NOT post it yourself** with `github_add_issue_comment` — that would
+double-post. Never fabricate a screenshot or a pass; a clearly-evidenced
+**REFUTED** is a real finding. If screenshots couldn't be persisted (no
+server-mode build assets), still report what the DOM/text evidence showed and
+say the images weren't retained.

package/workflows/prompts/verify-synth.md

@@ -0,0 +1,44 @@
+You are writing the **single final verdict** for a verify run. Two passes have
+already run: a text-evidence verification and (sometimes) a browser-QA pass.
+Your job is to **synthesize them into one concise comment** — the reader sees
+only your output, not the individual passes.
+
+This is a **pure writing task**. Do **not** run commands, install anything, read
+repo files, or start a server — everything you need is below. Do **not** post a
+comment yourself (`github_add_issue_comment`); your final message *is* the
+comment, delivered by the harness.
+
+## The claim
+
+{{#if commentBody}}{{commentBody}}{{/if}}{{#if issueTitle}} (issue/PR: {{issueTitle}}){{/if}}
+
+## Text-verification report
+
+{{verifyResult}}
+
+{{#if verifyBrowserResult}}
+## Browser-QA report (real headless browser + screenshots)
+
+{{verifyBrowserResult}}
+{{/if}}
+
+## Write the verdict
+
+Produce a tight Markdown comment:
+
+- **Lead with the conclusion** on its own line: **CONFIRMED**, **REFUTED**, or
+  **INCONCLUSIVE**. If the two passes disagree, reconcile them and say why the
+  combined evidence lands where it does (browser evidence is decisive for
+  rendered-UI behaviour; text evidence for everything else).
+- One short paragraph of the **key evidence** that settles it — the decisive
+  commands/output and assertion results, not a replay of both reports.
+{{#if verifyBrowserResult}}- **Embed the browser screenshots inline** exactly as they appear in the
+  browser-QA report above (the `![caption](https://…/<name>.png)` image
+  Markdown) so they render in this comment. Keep them; don't turn them into
+  plain links or drop them.{{/if}}
+- A one-line **coverage** note: what was exercised, and anything notable that
+  wasn't.
+
+Keep it short and decisive — no per-step narration, no restating both reports in
+full. If a pass reported a failure or a REFUTED, surface it plainly; don't bury
+it under the other pass.

package/workflows/prompts/verify.md

@@ -0,0 +1,63 @@
+You are **verifying a claim** — testing whether a stated behaviour is actually
+true and reporting the evidence. Read the `verify` skill for the full procedure
+and investigator rules, then follow it. It uses the `building` skill for
+installing and running the repo. This prompt gives you the claim and how your
+report is delivered.
+
+## The claim to test
+
+{{#if commentBody}}
+**Claim / request:**
+{{commentBody}}
+{{/if}}
+{{#if issueTitle}}**Issue/PR title:** {{issueTitle}}{{/if}}
+{{#if issueBody}}
+**Issue/PR body:**
+{{issueBody}}
+{{/if}}
+
+Target repo: **{{owner}}/{{repo}}**
+{{#if issueNumber}}Target issue/PR: **#{{issueNumber}}**{{/if}}
+
+If no explicit claim is given and this is a PR, read the PR description + diff
+and pick the single most important, most testable claim it makes — and say which
+claim you chose.
+
+## Workspace
+
+You are already inside the **{{repo}}** repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured; no clone, no
+`cd`. For a PR claim, check out the PR head (see the `pr-review`/`building`
+workspace notes); for a before/after claim, `git fetch` the base ref too.
+
+## First — is this even a text-checkable claim?
+
+You have **bash, file read, and the github tools** — no browser, no
+screenshots, no video. Before doing any setup, judge whether the claim is
+**purely about a rendered UI** (visual layout, mobile rendering, a click/render
+flow that only shows in a browser). If it is, **do not install/build/guess** —
+a dedicated browser-QA pass runs after you and owns it. Say in one line that the
+claim is UI-shaped and defer it to the browser pass, conclude **INCONCLUSIVE
+(UI-only — deferred to browser QA)**, and stop. Spend your effort only on claims
+bash can actually settle.
+
+## Evidence — what you can and can't capture
+
+For a text-checkable claim, prove it with test output, command stdout/stderr,
+exit codes, `curl` against a dev-server you start, and log/file excerpts.
+
+## How your report is delivered — read carefully
+
+Your **final message is the report**, and the harness posts it for you:
+{{#if issueNumber}}
+- as a comment on **#{{issueNumber}}**.
+{{/if}}
+{{#if !issueNumber}}
+- back into the thread this request came from.
+{{/if}}
+
+Make your final message the complete report in the shape the `verify` skill
+defines (Environment / Evidence / **Conclusion: CONFIRMED | REFUTED |
+INCONCLUSIVE**). **Do NOT post it yourself** with `github_add_issue_comment` —
+that would double-post. The only acceptable result that contradicts the claim is
+a clearly-evidenced **REFUTED**; surface it, don't bury it.

package/workflows/qa-test.yaml

@@ -0,0 +1,87 @@
+kind: qa-test
+name: qa-test
+description: |
+  Run an automated QA flow against a repo's CLI or locally-served app and report
+  step-level pass/fail with evidence. It installs and runs the code in the
+  sandbox, exercises a flow (CLI invocations or curl against a dev-server),
+  optionally drives the UI in a real browser, then posts a single per-step QA
+  report. Does not modify code.
+
+  Delivery is a single in-place status comment (`status_checklist`): the run
+  shows its phases ticking off, then a final `synthesize` phase folds the text
+  report and (when it ran) the browser evidence into ONE combined report,
+  delivered as the comment's footer via `final_message`. No comment-per-phase.
+  Posted on the originating issue/PR for GitHub runs, or into the Slack thread
+  for Slack runs. The agents therefore do NOT post anything themselves.
+
+  When the host runs the docker backend with the browser-QA image built, the
+  gated `qa_browser` phase drives a real headless Chromium against the
+  locally-served app and captures step-level screenshot evidence; everywhere
+  else it is silently skipped (graceful degradation) and the text report stands
+  alone. The synthesis runs either way.
+
+  Triggered by:
+    - a `@last-light qa-test <target> [-- steps]` comment on an issue/PR
+    - manual CLI: tsx src/cli.ts qa-test owner/repo#N -- "<steps>"
+
+status_checklist: true
+final_message: "{{synthesisResult}}"
+
+phases:
+  - name: phase_0
+    label: Context
+    type: context
+    depends_on: []
+
+  - name: qa_test
+    label: QA Test
+    depends_on: [phase_0]
+    prompt: prompts/qa-test.md
+    # qa-test: the flow procedure + report shape (primary).
+    # building: install + run the repo to exercise the flow.
+    skills: [qa-test, building]
+    model: "{{models.qa-test}}"
+    variant: "{{variants.qa-test}}"
+    output_var: qaResult
+    messages:
+      on_start: "Running the QA flow — installing, running, and exercising each step..."
+      on_success: "Text QA flow complete."
+      on_failure: "I couldn't complete the QA run — see the logs for details."
+
+  # Browser-QA pass (Tier B). Gated to the docker backend AND the enriched
+  # `lastlight-sandbox-qa:latest` image (Playwright + Chromium). On gondolin, or
+  # a docker host without that image, the scheduler silently skips this phase.
+  # It is terminal (nothing depends on it) — `synthesize` depends only on
+  # `qa_test`, so it still runs (after this phase, by declaration order) and
+  # folds in `qaBrowserResult` only when this phase actually produced it.
+  - name: qa_browser
+    label: QA Test (browser)
+    depends_on: [qa_test]
+    prompt: prompts/qa-browser.md
+    skills: [qa-test, building, browser-qa]
+    model: "{{models.qa-test}}"
+    variant: "{{variants.qa-test}}"
+    requires_sandbox: docker
+    sandbox_image: qa
+    output_var: qaBrowserResult
+    messages:
+      on_start: "Browser QA available — driving the UI and capturing screenshots..."
+      on_success: "Browser QA complete — screenshots captured."
+      on_skipped_done: "Browser QA unavailable on this host — text report stands."
+
+  # Synthesis. Depends only on `qa_test` (always runs after the gated browser
+  # phase by declaration order, and never skips when that phase is gated out).
+  # Reads the prior reports from phaseOutputs and writes ONE combined report;
+  # its output (`synthesisResult`) becomes the comment footer via the
+  # workflow-level `final_message`. Pure composition — no skills, no repo work.
+  - name: synthesize
+    label: Summary
+    depends_on: [qa_test]
+    prompt: prompts/qa-synth.md
+    model: "{{models.qa-test}}"
+    variant: "{{variants.qa-test}}"
+    output_var: synthesisResult
+    messages:
+      on_start: "Synthesizing the final report..."
+      on_success: "Report posted below."
+      on_failure: "I couldn't synthesize the final report — see the logs."