lastlight 0.15.0 → 0.16.1

package/workflows/prompts/pr.md

@@ -1,39 +0,0 @@
-Create a pull request for the work on branch {{branch}}.
-
-Use the MCP tool github_create_pull_request with the following:
-- owner: {{owner}}
-- repo: {{repo}}
-- head: {{branch}}
-- base: {{baseBranch}}
-- title: A concise title describing the change (reference #{{issueNumber}})
-- body: A markdown body that includes EXACTLY these sections in order:
-
-  Closes #{{issueNumber}}
-
-  ## Summary
-  (3-6 bullet points describing what changed)
-
-  ## Planning and execution docs
-  - [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}}/`
-  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.
-
-  ## Test results
-  (paste the actual test/lint/typecheck output from executor-summary.md){{#if !review.approved}}
-
-Note: There are unresolved reviewer issues after {{review.cycles}} fix cycles. See reviewer-verdict.md on the branch.{{/if}}
-
-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.
-{{#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 (so the harness can link the PR from the checklist).

package/workflows/prompts/qa-browser.md

@@ -1,95 +0,0 @@
-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

@@ -1,44 +0,0 @@
-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

@@ -1,60 +0,0 @@
-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,33 +0,0 @@
-You are the CODE REVIEWER — RE-REVIEW after fix cycle {{fixCycle}}.
-
-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.
-
-SCOPE — review ONLY what changed in the fix cycle:
-1. Read {{issueDir}}/reviewer-verdict.md — your previous issues
-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
-
-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
-{{#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:
-
-   VERDICT: APPROVED
-   VERDICT: REQUEST_CHANGES
-
-The orchestrator parses this marker to decide whether to run another fix
-cycle. Do NOT use any other phrasing for the verdict on the first line.
-
-After the marker line, write a 2–5 sentence summary of which previous issues
-were addressed and any remaining concerns.

package/workflows/prompts/reviewer.md

@@ -1,60 +0,0 @@
-You are the CODE REVIEWER. Independent verification — you have NO shared context with the executor.
-
-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 ({{baseBranch}} is this repo's base branch):
-  git log --oneline {{baseBranch}}..HEAD
-  git diff {{baseBranch}}...HEAD --name-only
-  git diff {{baseBranch}}...HEAD
-
-Read {{issueDir}}/architect-plan.md and executor-summary.md for context.
-
-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.
-
-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):
-
-   # Reviewer Verdict — Issue #{{issueNumber}}
-
-   VERDICT: APPROVED      ← or REQUEST_CHANGES, exactly one of these, on its own line
-
-   ## Summary
-   (1–3 sentences)
-
-   ## Issues
-   ### Critical
-   ### Important
-   ### Suggestions
-   ### Nits
-
-   ## Test Results
-   (paste actual output)
-
-2. Update status.md with reviewer_status: APPROVED or REQUEST_CHANGES (matching the verdict)
-{{#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 — after you have written the files above, your LAST action MUST be
-a final text message (NOT a tool call). Do not end your turn on a file write or
-any other tool call. That final message MUST start with one of these two lines,
-EXACTLY, on its own line, with no leading whitespace:
-
-   VERDICT: APPROVED
-   VERDICT: REQUEST_CHANGES
-
-The orchestrator parses this marker from your final message to decide whether to
-run the fix loop — if you end on a tool call with no closing text, the run has
-no verdict to read. Do NOT use any other phrasing for the verdict on the first
-line — words like "approved", "approval", "request changes", or "looks good"
-elsewhere in the body are fine, but the first non-empty line MUST be exactly the
-marker above.
-
-After the marker line, write a 2–5 sentence summary of the most important
-findings. Writing the files is NOT the last step — this summary is.

package/workflows/prompts/verify-browser.md

@@ -1,93 +0,0 @@
-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

@@ -1,44 +0,0 @@
-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

@@ -1,63 +0,0 @@
-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

@@ -1,94 +0,0 @@
-kind: qa-test
-name: qa-test
-classification:
-  intent: qa-test
-  description: |
-    QATEST — The user wants you to drive an app or CLI through a flow and report step-level pass/fail: "qa test the signup flow", "run through login and tell me what breaks", "smoke-test the CLI commands", "exercise the checkout flow". The deliverable is a step-by-step QA report. Prefer QATEST over VERIFY when it's a multi-step flow to exercise rather than a single claim to confirm.
-  examples:
-    - '"qa test the login flow on this PR" with ISSUE TITLE "Add login" → INTENT: QATEST, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"run through the signup flow and tell me what breaks" with ISSUE TITLE "Signup v2" → INTENT: QATEST, REPO: NONE, ISSUE: NONE, REASON: NONE'
-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, qa_browser]
-    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."

package/workflows/repo-health.yaml

@@ -1,15 +0,0 @@
-kind: health
-name: repo-health
-description: |
-  Generate a health report for a repository: open issues, stale issues, PR
-  velocity, label distribution, etc. Repo-scoped (no specific issue/PR).
-
-  Triggered by:
-    - weekly cron (default Monday 09:00)
-    - manual CLI: tsx src/cli.ts health owner/repo
-
-phases:
-  - name: report
-    label: Report
-    skill: repo-health
-    model: "{{models.health}}"