lastlight 0.1.15 → 0.2.1

package/skills/security-review/references/issue-format.md

@@ -0,0 +1,302 @@
+# § Issue format
+
+This is the **contract** between `security-review` (producer) and
+`security-feedback` (consumer). Every rule here is machine-parsed; do not
+deviate. `security-feedback` is staged into a separate workspace and cannot read
+this file, so it keeps its own copy of the row/severity grammar — **if you change
+the grammar here, update `skills/security-feedback/SKILL.md` in lockstep.**
+
+## Title
+
+```
+Security scan — YYYY-MM-DD
+```
+
+- Exactly one em-dash (` — `, U+2014), surrounded by single spaces.
+- Date is the scan's UTC date in ISO form.
+- Same-day re-scans produce a second issue with the same title. GitHub disambiguates by issue number; the scanner never edits a prior-run issue.
+
+## Body
+
+The body is assembled from eight blocks, in this exact order, separated by blank lines:
+
+```
+{header comments}
+
+{intro paragraph}
+
+{how-to-respond section}
+
+{summary table}
+
+{suppression note}
+
+{scope note}
+
+{overflow note — omitted when overflow == 0}
+
+{findings sections}
+```
+
+### Block 1 — header comments
+
+Three HTML comments, each on its own line, in this exact order:
+
+```
+<!-- lastlight-security-scan-version: 1 -->
+<!-- lastlight-security-scan-date: YYYY-MM-DD -->
+<!-- lastlight-security-scan-ts: YYYY-MM-DDTHH:MM:SSZ -->
+```
+
+- `version` is a format version. Bump if the structure changes incompatibly — `security-feedback` will check this and refuse to parse unknown versions.
+- `date` matches the title.
+- `ts` is an ISO-8601 UTC timestamp with second precision (no milliseconds).
+
+### Block 2 — intro paragraph
+
+Exactly one paragraph, with the commit count and short-SHA range substituted:
+
+```
+Reviewing {N} commits since {priorScanDate} ({firstShortSha}..{lastShortSha}). Findings here focus on SDLC and workflow changes — Dependabot, GitHub Code Scanning, and Renovate handle the rest. Tick the box once the underlying issue is resolved or recorded in `SECURITY.md`.
+```
+
+`{N}` is the size of `commitsReviewed`. `{priorScanDate}` is the YYYY-MM-DD of the prior scan (or the bootstrap floor). When `N == 1`, both short SHAs are the same — render as `({onlyShortSha})` rather than `({sha}..{sha})`.
+
+### Block 3 — how-to-respond section
+
+Verbatim, including the heading:
+
+```
+## How to respond
+
+**Preferred flow** — tick the boxes on the findings you want broken out, then comment:
+
+- `@last-light create issues` — files one issue per **ticked** finding (default)
+
+**Other shortcuts:**
+
+- `@last-light create issues for the criticals` — every Critical finding (ticked or not)
+- `@last-light create issues for the highs` — same, for High
+- `@last-light create issues for items 1, 3, 5` — specific items by number (1-based, top to bottom)
+- `@last-light create issues for all` — every finding in this scan
+- `@last-light accept-risk for item N: <reason>` — suppress this finding in future scans
+- `@last-light false-positive for item N: <reason>` — suppress this finding in future scans
+- Comment freely to ask questions or discuss
+```
+
+(Item positions in commands map to the `item:N` HTML-comment markers defined below. Ticking a box in GitHub's UI rewrites the row from `[ ]` to `[x]` — the feedback skill treats that as your selection.)
+
+### Block 4 — summary table
+
+Verbatim header, with numbers substituted. Always include all four severity rows, even when the count is 0.
+
+`{nC}`, `{nH}`, `{nM}`, `{nL}` and `{nTotal}` are **TRUE counts** (post-filtering, pre-cap) — i.e. how many findings of each severity actually survived the SECURITY.md filtering, regardless of whether each individual row is listed below the cap. The same numbers appear in the `### 🔴 Critical ({nC})` etc. section headers. The overflow note (Block 6) communicates how many of those counts were truncated from the listed rows.
+
+```
+## Summary
+
+| Severity | Count |
+|----------|------:|
+| Critical | {nC} |
+| High     | {nH} |
+| Medium   | {nM} |
+| Low      | {nL} |
+| **Total**| **{nTotal}** |
+```
+
+### Block 5 — suppression note
+
+A single line:
+
+```
+Suppressed by `SECURITY.md`: {nSuppressed} (accepted: {nA}, false-positives: {nFP}). Below severity floor: {nFloor}.
+```
+
+Set each count to 0 when N/A. Emit the line unconditionally so the structure is stable.
+
+### Block 6 — scope note
+
+Always emit, immediately after the suppression note. Lists the human (non-bot) commits actually reviewed, so a maintainer can see what diff produced these findings:
+
+```
+> Commits reviewed: {short-sha-1} {subject-1}, {short-sha-2} {subject-2}, …
+```
+
+Cap at 10 entries; if there are more, append ` +{N} more` after the last item. Subjects are truncated to 60 chars with `…` if longer. Renovate/Dependabot commits are filtered out at § 1.5 and never appear here.
+
+### Block 7 — overflow note
+
+Emit **only** when `overflow > 0`:
+
+```
+> **Note** — {overflow} lower-severity findings are not listed here. The cap is: ALL critical and high, plus the first 10 medium/low (after sort). Tighten `SECURITY.md` severity floors or break out items from this scan, then re-run to surface the rest.
+```
+
+### Block 8 — findings sections
+
+Four sections, in this **exact order** (Critical → High → Medium → Low). Always emit all four headers, even when a section has zero findings — the feedback skill relies on stable anchors.
+
+The header counts (`{nC}` etc.) are the **true** post-filter counts, identical to those in Block 4's summary table. The rows listed under each header are subject to the § 7 cap: critical and high are always complete; medium + low are truncated to the first 10 combined. When a section is partially listed, append `(showing first N of {nM})` after the marker — see the per-section header rule below.
+
+```
+## Findings
+
+### 🔴 Critical ({nC})
+
+{rows or "_No findings._"}
+
+### 🟠 High ({nH})
+
+{rows or "_No findings._"}
+
+### 🟡 Medium ({nM}){if truncated: " (showing first {kM} of {nM})"}
+
+{rows or "_No findings._"}
+
+### 🟢 Low ({nL}){if truncated: " (showing first {kL} of {nL})"}
+
+{rows or "_No findings._"}
+```
+
+Where `kM` and `kL` are the actual rows listed in this issue (sum of the two ≤ 10). When `kM == nM` or `kL == nL` (no truncation in that section), omit the parenthetical.
+
+### Finding-row grammar
+
+Every finding is exactly two lines: a task-list row, then a `<details>` block (one blank line between rows within a section).
+
+The task-list row is **one physical line** with this exact shape:
+
+```
+- [ ] <!-- item:N fp:FINGERPRINT --> **TITLE** — `FILE:LINE` (TOOL · `RULE`)
+```
+
+Matched by this canonical regex (multiline, case-sensitive) — covers all three row states:
+
+```
+/^- \[([ x])\] <!-- item:(\d+) fp:([0-9a-f]{8,}) --> (?:~~)?\*\*(.+?)\*\* — `([^`]+):(\d+)` \(([a-z][a-z0-9-]*) · `([^`]+)`\)(?:~~ → #(\d+))?$/m
+```
+
+Capture groups, in order:
+
+1. `checkbox` — `" "` (unticked) or `"x"` (ticked or broken-out)
+2. `itemNumber` (1-based across all severities)
+3. `fingerprint` (lowercase hex, ≥ 8 chars)
+4. `title` (plain text; no backticks, no asterisks)
+5. `file` (no backticks, forward-slash path)
+6. `line` (integer; use `0` when not line-scoped)
+7. `tool` (lowercase, hyphenated — e.g. `npm-audit`, `semgrep`, `gitleaks`, `claude`)
+8. `rule` (the tool's native rule id; may contain dots, hyphens)
+9. `subIssueNumber` — present **only** when the row has been broken out to a sub-issue; `undefined` otherwise
+
+Derived state (the feedback skill computes these from the captures):
+
+| State | Written as | `checkbox` | `subIssueNumber` |
+|-------|------------|------------|------------------|
+| **pending** | `- [ ] <!-- item:N fp:FP --> **TITLE** — …` | `" "` | `undefined` |
+| **user-ticked** (maintainer clicked the box in GitHub's UI) | `- [x] <!-- item:N fp:FP --> **TITLE** — …` | `"x"` | `undefined` |
+| **broken-out** (feedback skill created a sub-issue) | `- [x] <!-- item:N fp:FP --> ~~**TITLE** — …~~ → #SUBISSUE` | `"x"` | the sub-issue number |
+
+Rules:
+
+- `alreadyBrokenOut` ≡ `subIssueNumber != null`. Broken-out rows are immutable — the feedback skill never re-opens them, never touches their checkbox, never re-creates sub-issues from them.
+- `userTicked` ≡ `checkbox === "x" && subIssueNumber == null`. These are the candidates the default `@last-light create issues` command selects.
+- When creating sub-issues from ticked rows, the feedback skill transitions each row from **user-ticked** → **broken-out** by wrapping the visible text in `~~…~~` and appending ` → #{subIssueNumber}`. The checkbox stays `[x]`; the strikethrough + link is the canonical broken-out marker.
+- Un-ticking (moving a user-ticked row back to `[ ]`) is fine — the row just becomes pending again. The scanner doesn't police this.
+
+The per-finding detail block follows immediately on the next line:
+
+````
+<details><summary>Details</summary>
+
+```{LANGUAGE}
+{SNIPPET}
+```
+
+{EXPLANATION}
+
+**Suggested fix:** {SUGGESTED_FIX}
+
+</details>
+````
+
+Rules:
+- `LANGUAGE` is the fenced-code language tag; empty string when unknown.
+- `SNIPPET` is the code excerpt; no surrounding fences, no trailing blank line inside the fence.
+- `EXPLANATION` and `SUGGESTED_FIX` are markdown strings; they may contain their own fenced code blocks and line breaks.
+- The `<details>` block ends with `</details>` on its own line.
+
+## Worked example
+
+A scan with 1 critical + 1 high finding renders like:
+
+````markdown
+<!-- lastlight-security-scan-version: 1 -->
+<!-- lastlight-security-scan-date: 2026-04-21 -->
+<!-- lastlight-security-scan-ts: 2026-04-21T10:00:00Z -->
+
+Reviewing 3 commits since 2026-04-14 (a1b2c3d..f9e8d7c). Findings here focus on SDLC and workflow changes — Dependabot, GitHub Code Scanning, and Renovate handle the rest. Tick the box once the underlying issue is resolved or recorded in `SECURITY.md`.
+
+## How to respond
+
+- `@last-light create issues for the criticals` — file individual issues for every Critical finding
+- `@last-light create issues for the highs` — same, for High
+- `@last-light create issues for items 1, 3, 5` — file issues for specific items by number (1-based, top to bottom)
+- `@last-light create issues for all` — every finding in this scan
+- `@last-light accept-risk for item N: <reason>` — suppress this finding in future scans
+- `@last-light false-positive for item N: <reason>` — suppress this finding in future scans
+- Comment freely to ask questions or discuss
+
+## Summary
+
+| Severity | Count |
+|----------|------:|
+| Critical | 1 |
+| High     | 1 |
+| Medium   | 0 |
+| Low      | 0 |
+| **Total**| **2** |
+
+Suppressed by `SECURITY.md`: 0 (accepted: 0, false-positives: 0). Below severity floor: 0.
+
+> Commits reviewed: a1b2c3d wire user-supplied repo into git clone, e5f6a7b add admin shell endpoint, f9e8d7c rotate webhook secret
+
+## Findings
+
+### 🔴 Critical (1)
+
+- [ ] <!-- item:1 fp:abc123def4567890 --> **Command injection in git clone** — `mcp-github-app/src/index.js:42` (semgrep · `javascript.lang.security.exec-shell-command`)
+<details><summary>Details</summary>
+
+```javascript
+execSync(`git clone ${userInput}`)
+```
+
+`userInput` originates from an HTTP request and is concatenated directly into a shell command, allowing arbitrary command execution.
+
+**Suggested fix:** use `execFileSync('git', ['clone', userInput])` so arguments aren't re-parsed by a shell.
+
+</details>
+
+### 🟠 High (1)
+
+- [ ] <!-- item:2 fp:def456abc7890123 --> **Hardcoded API key in config** — `src/config.ts:18` (gitleaks · `generic-api-key`)
+<details><summary>Details</summary>
+
+```typescript
+const API_KEY = "sk_live_abc123..."
+```
+
+A live API key is committed to the repo. Anyone with read access to the repo (or the git history of a former branch) can use it.
+
+**Suggested fix:** move the key to an environment variable (`process.env.API_KEY`) and rotate the exposed one immediately.
+
+</details>
+
+### 🟡 Medium (0)
+
+_No findings._
+
+### 🟢 Low (0)
+
+_No findings._
+````

package/skills/verify/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: verify
+description: Test a behaviour claim as an investigator and report whether the evidence confirms or refutes it — CONFIRMED / REFUTED / INCONCLUSIVE with bash-captured evidence. Use when asked to verify a claim, prove a fix works, or check that a PR does what it says.
+version: 1.0.0
+tags: [github, verify, testing, evidence]
+---
+
+# Verify
+
+Test a specific claim about behaviour and report whether the evidence supports
+or refutes it. The deliverable is a **verdict with evidence**, not an opinion.
+
+This skill uses the **building** skill for installing dependencies and running
+the repo's build/test commands in the sandbox.
+
+> **Scope (text-evidence path).** In the default text phase the sandbox agent
+> has bash, file read, and the github tools — no browser, no screenshots, no
+> video. Prove claims with what bash can capture: test output, command
+> stdout/stderr, `curl` against a dev-server you start, log excerpts, file
+> contents, exit codes. Driving a real browser and attaching screenshots is the
+> separate `browser-qa` skill, which is staged only in the gated browser phase
+> running on the docker QA image (Playwright + Chromium). If that skill isn't in
+> your catalogue and a claim genuinely can only be shown in a rendered UI, say
+> so under **INCONCLUSIVE** rather than guessing — the browser phase will pick
+> it up when available.
+
+## Ground rule — investigator, not advocate
+
+Your job is to find out whether the claim is **true**, not to make it look true.
+A conclusive "this is broken" with clear evidence is exactly as valuable as a
+"this works". Specifically:
+
+- **Never fabricate, hardcode, mock, or stage evidence** to match an expected
+  outcome. Do not edit the code under test to make a result appear.
+- If the behaviour you observe **contradicts** the claim, that is the result —
+  report it as REFUTED with the evidence inline. Don't bury it.
+- **Don't retry a failing test hoping for a different answer.** Retry only after
+  *changing* the environment or procedure (wrong branch, missing build step),
+  and only when you have reason to believe the test setup — not the code — was
+  wrong. One unexpected result that reproduces is a finding.
+
+## Parse the target
+
+The Context block gives you the claim and (usually) a PR or issue. The claim may
+arrive as:
+
+- A **direct claim** — "ESC cancels streaming in bash mode", "the `--fork` flag
+  creates a new session".
+- A **PR reference + claim** — verify the claim against that PR's head.
+- A **PR reference only** — read the PR description + diff and identify the most
+  important, most testable claim it makes; state which claim you chose.
+
+When a PR/issue is given, read its description and diff for context (from the
+local checkout — see the **building** skill's workspace notes; don't pull the
+diff through the API).
+
+## Decide what would convince a skeptic
+
+Name the single behaviour to observe and the evidence that settles it:
+
+- **Functional claim** (a feature works, a flow completes) → run it and capture
+  the output / exit code / resulting state.
+- **Regression / fix claim** ("no longer clears the screen", "stops erroring") →
+  show the **before and after**: reproduce on the base ref, then show it gone on
+  the head ref. Both states must appear in the evidence — an off-camera "it's
+  fixed" doesn't count.
+- **Output/encoding claim** → capture the exact bytes/text (`xxd`, `od -c`, raw
+  stdout) rather than describing them.
+
+## Run the test
+
+Follow the **building** skill to install and build. Then exercise the claim with
+the minimal sequence that demonstrates it, capturing evidence at the decisive
+step. Start a dev-server in the background and `curl` it when the claim is about
+a running service; run the CLI directly when it's a CLI claim; run the targeted
+test when the repo already encodes the behaviour as a test.
+
+If the environment blocks a clean test (missing dependency the sandbox can't
+provide, build failure you can't resolve, infra that won't run), capture what
+blocked it — that drives an **INCONCLUSIVE** result, not a guess.
+
+## Report
+
+Produce your report as your **final message** in this shape — the workflow posts
+it for you (don't `github_add_issue_comment` yourself; that would double-post).
+**Keep it concise**: a one-line environment summary, the decisive evidence
+(commands + key output, not every line), and a one-paragraph conclusion — not an
+exhaustive walkthrough.
+
+```
+## Verify: <claim>
+
+**Environment:** <branch / commit, package manager, how the app was run>
+
+### Evidence
+<commands run + their captured output — fenced. Include both states for a
+before/after claim.>
+
+### Conclusion
+**CONFIRMED** | **REFUTED** | **INCONCLUSIVE**
+
+<one paragraph: what the evidence shows and why it settles the claim.>
+```
+
+- **REFUTED** — state the expected behaviour (from the claim), the observed
+  behaviour (from the evidence), include the evidence inline, and note any
+  environmental factors (branch, commit, OS). This is a valuable finding, not a
+  failed run.
+- **INCONCLUSIVE** — report exactly what blocked the test and what would be
+  needed to resolve it. Do not guess at the outcome.
+
+## Do NOT
+
+- Retry a failing test more than once without changing the environment/procedure.
+- Hardcode expected output, mock responses, or edit the code under test to force
+  a result.
+- Assume unexpected behaviour means *you* made a mistake — it may be a real bug.
+- Omit evidence that contradicts the claim.

package/workflows/answer.yaml

@@ -0,0 +1,37 @@
+kind: answer
+name: answer
+description: |
+  Answer a question issue directly. Used when a newly-opened issue asks for
+  information, an explanation, or a comparison rather than a code change — the
+  bot researches (repo docs + web search) and posts a single sourced answer
+  comment, labels the issue `question`, and leaves it open. No agent brief, no
+  ready-for-agent, no PR.
+
+  Delivery is uniform: the agent's final message (the answer) is captured as
+  `answerResult` and posted by the harness via `postComment` — as a comment on
+  the originating issue for GitHub-initiated runs, or into the Slack thread for
+  Slack-initiated runs. The skill therefore does NOT post the answer itself; it
+  only applies the `question` label when answering a GitHub issue.
+
+  Triggered by:
+    - issue.opened webhook when the router classifies the issue as a question
+    - a Slack message classified as a question against a managed repo
+    - manual override via routes.github.issue_answer / routes.slack.answer
+
+phases:
+  - name: phase_0
+    label: Context
+    type: context
+
+  - name: answer
+    label: Answer
+    prompt: prompts/answer.md
+    skill: issue-answer
+    model: "{{models.answer}}"
+    web_search: true
+    unrestricted_egress: true
+    output_var: answerResult
+    messages:
+      on_start: "Researching and drafting an answer..."
+      on_success: "{{answerResult}}"
+      on_failure: "I couldn't put together an answer — see the logs for details."

package/workflows/build.yaml

@@ -2,6 +2,10 @@ kind: build
 name: build
 description: "Architect -> Executor -> Reviewer build cycle"
 trigger: build
+# Render progress as a single in-place task-list comment/message that updates
+# as phases run, instead of a new comment per phase. The per-phase
+# `messages.on_*` below become the one-line detail on each checklist step.
+status_checklist: true
 
 phases:
   - name: phase_0
@@ -12,6 +16,7 @@ phases:
     label: Guardrails
     prompt: prompts/guardrails.md
     model: "{{models.guardrails}}"
+    variant: "{{variants.guardrails}}"
     on_output:
       contains_BLOCKED:
         action: fail
@@ -27,7 +32,7 @@ phases:
       contains_READY:
         action: continue
     messages:
-      on_success: "**Guardrails check: READY** — verified. Starting architect analysis..."
+      on_success: "READY — foundational tooling verified — [guardrails-report.md]({{artifactUrl guardrails-report.md}})"
       on_blocked: |
         **Guardrails check: BLOCKED** — missing foundational tooling.
 
@@ -38,67 +43,72 @@ phases:
     label: Architect
     prompt: prompts/architect.md
     model: "{{models.architect}}"
+    variant: "{{variants.architect}}"
     approval_gate: post_architect
+    approval_artifact: architect-plan.md
     approval_gate_message: |
       **Architect analysis complete** — approval required before implementation.
 
       - Branch: `{{branch}}`
       - Plan: `{{issueDir}}/architect-plan.md`
 
-      **To proceed:** comment `@last-light approve`
-      **To abort:** comment `@last-light reject [reason]`
+      **Review & decide:** {{approvalUrl}}
+      **Or comment:** `@last-light approve` / `@last-light reject [reason]`
     messages:
-      on_success: |
-        **Architect analysis complete.**
-        - Branch: `{{branch}}`
-        - Plan: `{{issueDir}}/architect-plan.md`
-
-        Starting implementation...
+      # Single-line messages become the one-line detail on the checklist step,
+      # so keep them concise and link the artifact on the branch.
+      on_success: "Plan ready — [architect-plan.md]({{artifactUrl architect-plan.md}})"
 
   - name: executor
     label: Executor
     prompt: prompts/executor.md
+    skill: building
     model: "{{models.executor}}"
+    variant: "{{variants.executor}}"
     messages:
-      on_start: "**Starting executor** — implementing the architect's plan..."
-      on_skipped_done: "**Executor** already completed — proceeding to review..."
-      on_success: |
-        **Implementation complete.** Running independent review...
-        - Branch: `{{branch}}`
-        - Summary: `{{issueDir}}/executor-summary.md`
+      on_start: "implementing the architect's plan…"
+      on_skipped_done: "already completed"
+      on_success: "Implemented — [executor-summary.md]({{artifactUrl executor-summary.md}})"
 
   - name: reviewer
     label: Reviewer
     prompt: prompts/reviewer.md
+    # code-review: rubric for the review + re-review prompts.
+    # building: the fix cycle (fix.md) runs under this node and needs the gate.
+    skills: [code-review, building]
     model: "{{models.reviewer}}"
+    variant: "{{variants.reviewer}}"
     output_var: review
     loop:
       max_cycles: 2
       on_request_changes:
         fix_prompt: prompts/fix.md
         fix_model: "{{models.fix}}"
+        fix_variant: "{{variants.fix}}"
         re_review_prompt: prompts/re-reviewer.md
       approval_gate: post_reviewer
+      approval_artifact: reviewer-verdict.md
       messages:
-        on_cycle_start: "**Starting reviewer** (cycle {{cycle}}) — independent verification..."
-        on_approved: "**Review: APPROVED** — proceeding to PR."
-        on_request_changes: "**Review: REQUEST_CHANGES** — fixing issues (cycle {{cycle}}/{{maxCycles}})..."
+        on_cycle_start: "independent verification (cycle {{cycle}})…"
+        on_approved: "Approved — [reviewer-verdict.md]({{artifactUrl reviewer-verdict.md}})"
+        on_request_changes: "**Review: REQUEST_CHANGES** — [reviewer-verdict.md]({{artifactUrl reviewer-verdict.md}}) — fixing issues (cycle {{cycle}}/{{maxCycles}})..."
         on_fix_start: "**Starting fix loop** (cycle {{cycle}}/{{maxCycles}}) — addressing reviewer feedback..."
         on_fix_failed: "Fix cycle {{cycle}} failed. Proceeding to PR with known issues."
-        on_max_cycles: "**Review: REQUEST_CHANGES** after {{maxCycles}} fix cycles. Proceeding with remaining issues noted."
+        on_max_cycles: "**Review: REQUEST_CHANGES** after {{maxCycles}} fix cycles — see [reviewer-verdict.md]({{artifactUrl reviewer-verdict.md}}). Proceeding with remaining issues noted."
         on_pause_for_approval: |
           **Review: REQUEST_CHANGES** — approval required before fix loop.
 
           - Verdict: `{{issueDir}}/reviewer-verdict.md`
 
-          **To proceed with fixes:** comment `@last-light approve`
-          **To abort:** comment `@last-light reject [reason]`
+          **Review & decide:** {{approvalUrl}}
+          **Or comment:** `@last-light approve` / `@last-light reject [reason]`
 
   - name: pr
     label: PR
     prompt: prompts/pr.md
     model: "{{models.pr}}"
+    variant: "{{variants.pr}}"
     on_success:
       set_phase: complete
     messages:
-      on_start: "**Creating PR** — packaging changes for review..."
+      on_start: "packaging changes for review…"

package/workflows/cron-security.yaml

@@ -0,0 +1,6 @@
+kind: cron
+name: weekly-security-scan
+schedule: "0 10 * * 1"
+workflow: security-review
+context:
+  deliverSlackSummary: true

package/workflows/demo.yaml

@@ -0,0 +1,55 @@
+kind: demo
+name: demo
+description: |
+  Record a short demo VIDEO of a PR or feature and post it. Drives the repo's
+  web UI in a real headless browser, screen-records the session, and composites
+  a titled, size-capped mp4 with ffmpeg — delivered inline on the originating
+  issue/PR (and in the dashboard Artifacts view). Does not modify code.
+
+  This workflow's demo phase runs ENTIRELY on the docker backend with the
+  browser-QA image (Playwright + Chromium + ffmpeg baked in). On gondolin, or a
+  docker host without that image, the demo phase is silently SKIPPED (graceful
+  degradation) and the run completes without a video — it never fails the
+  trigger. Compositing is ffmpeg-only (title card, optional before/after,
+  trim/speed, size cap) — there is no Remotion / cinematic pipeline.
+
+  Delivery is a single in-place status comment (`status_checklist`): the run
+  shows its phases ticking off, then the demo phase's report — with the playable
+  video embedded — becomes the comment footer via `final_message`. The agent
+  does NOT post anything itself.
+
+  Triggered by:
+    - a `@last-light demo [notes]` comment on an issue/PR
+    - manual CLI: tsx src/cli.ts demo owner/repo#N [-- "notes"]
+
+status_checklist: true
+final_message: "{{demoResult}}"
+
+phases:
+  - name: phase_0
+    label: Context
+    type: context
+    depends_on: []
+
+  # The demo phase. Gated to the docker backend AND the enriched
+  # `lastlight-sandbox-qa:latest` image (Playwright + Chromium + ffmpeg). On
+  # gondolin, or a docker host without that image, the scheduler silently skips
+  # it (the run still completes — there is no text fallback for a video).
+  - name: demo
+    label: Demo
+    depends_on: [phase_0]
+    prompt: prompts/demo.md
+    # demo: the director procedure + compose-demo.sh wrapper (primary).
+    # browser-qa: the headless driver (agent-browser.mjs) with --record-dir.
+    # building: install + run the repo's dev-server to drive.
+    skills: [demo, browser-qa, building]
+    model: "{{models.demo}}"
+    variant: "{{variants.demo}}"
+    requires_sandbox: docker
+    sandbox_image: qa
+    output_var: demoResult
+    messages:
+      on_start: "Recording a demo — installing, running the app, and capturing the UI..."
+      on_success: "Demo recorded — see the video below."
+      on_failure: "I couldn't record the demo — see the logs for details."
+      on_skipped_done: "Demo unavailable on this host (needs the docker browser-QA image)."

package/workflows/explore.yaml

@@ -8,6 +8,9 @@ description: |
   for Slack-initiated runs).
 
 trigger: explore
+# Single in-place task-list comment/message instead of a comment per phase.
+# Reply-gate questions and the published spec still post as standalone notes.
+status_checklist: true
 
 phases:
   - name: phase_0
@@ -19,6 +22,8 @@ phases:
     prompt: prompts/explore-read.md
     model: "{{models.explore}}"
     output_var: baseline
+    unrestricted_egress: true
+    web_search: true
     messages:
       on_start: "Cloning `{{owner}}/{{repo}}` and reading the codebase..."
 
@@ -26,6 +31,8 @@ phases:
     label: Socratic questioning
     prompt: prompts/explore-ask.md
     model: "{{models.explore}}"
+    unrestricted_egress: true
+    web_search: true
     generic_loop:
       max_iterations: 8
       until: "output.contains('READY')"
@@ -41,6 +48,8 @@ phases:
     prompt: prompts/explore-synthesize.md
     model: "{{models.architect}}"
     output_var: spec
+    unrestricted_egress: true
+    web_search: true
     messages:
       on_start: "Writing up the spec from our conversation..."