lastlight 0.16.0 → 0.16.1

package/workflows/security-feedback.yaml

@@ -1,25 +0,0 @@
-kind: health
-name: security-feedback
-description: |
-  Process maintainer feedback on a security-labelled issue (usually a
-  per-run scan summary). Classifies the comment and acts:
-
-    - create-issues — break selected findings out into individual issues
-      that can later be fed to the `build` skill (the primary flow)
-    - accept-risk / false-positive — update SECURITY.md via PR to
-      suppress the finding in future scans
-    - reopen — ask the maintainer to re-run `@last-light security-review`
-    - discuss / ignore — reply conversationally or do nothing
-
-  The scan-summary issue grammar is defined in
-  `skills/security-review/SKILL.md § Issue format`; this skill's parser
-  mirrors it (version-checked on entry).
-
-  Triggered by:
-    - @last-light mention on issues labelled "security"
-
-phases:
-  - name: feedback
-    label: Security feedback
-    skill: security-feedback
-    model: "{{models.security}}"

package/workflows/security-review.yaml

@@ -1,37 +0,0 @@
-kind: health
-name: security-review
-classification:
-  intent: security
-  description: |
-    SECURITY — The user wants a security scan/review of a repo: "security review cliftonc/repo", "scan for vulnerabilities", "check security", "can you do a security review of <repo>?".
-  examples:
-    - '"run a security review on cliftonc/lastlight" → INTENT: SECURITY, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
-    - '"can you do a security review of https://github.com/cliftonc/lastlight" → INTENT: SECURITY, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
-    - '"scan https://github.com/cliftonc/lastlight for vulnerabilities" → INTENT: SECURITY, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
-description: |
-  Scan the target repository for security issues using open-source tools
-  (npm audit, semgrep, gitleaks) plus AI code review. Files ONE summary
-  issue per run (Renovate-style) containing a GitHub task list of every
-  finding grouped by Critical / High / Medium / Low. Honours SECURITY.md
-  for known false positives and accepted risks.
-
-  Maintainers break findings out into individual issues by commenting on
-  the summary issue (see the `security-feedback` skill — which handles
-  `@last-light create issues for the criticals`, per-item accept-risk /
-  false-positive commands, and conversational follow-ups).
-
-  Each invocation scans exactly ONE repo. The weekly cron fans out into
-  one independent run per managed repo.
-
-  Triggered by:
-    - weekly cron (Monday 10:00, fans out over every managed repo)
-    - manual CLI: tsx src/cli.ts security owner/repo
-    - @last-light security-review in a GitHub comment
-    - Slack: "security review cliftonc/repo"
-
-phases:
-  - name: scan
-    label: Security scan
-    skill: security-review
-    model: "{{models.security}}"
-    variant: "{{variants.security}}"

package/workflows/verify.yaml

@@ -1,93 +0,0 @@
-kind: verify
-name: verify
-classification:
-  intent: verify
-  description: |
-    VERIFY — The user wants you to TEST whether a specific claim or behaviour is actually true and report the evidence: "verify that the rate limiter blocks", "does this PR really fix the crash?", "confirm X actually works", "check that Y no longer happens", "prove the --fork flag creates a new session". The deliverable is a CONFIRMED/REFUTED verdict backed by RUNNING the code — not a code change and not a code-quality review. Prefer VERIFY over REVIEW when the user wants proof a behaviour works/is fixed, rather than an assessment of the diff.
-  examples:
-    - '"verify that the --fork flag creates a new session in cliftonc/foo#12" → INTENT: VERIFY, REPO: cliftonc/foo, ISSUE: 12, REASON: NONE'
-    - '"does this actually fix the crash?" with ISSUE TITLE "Fix null deref on resize" → INTENT: VERIFY, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"can you confirm the rate limiter actually blocks at 100 req/s?" with ISSUE TITLE "Add rate limiter" → INTENT: VERIFY, REPO: NONE, ISSUE: NONE, REASON: NONE'
-description: |
-  Verify a behaviour claim against a repo or PR and report whether the evidence
-  confirms or refutes it. It installs and runs the code in the sandbox, captures
-  bash/text evidence, optionally drives the UI in a real browser, then posts a
-  single CONFIRMED / REFUTED / INCONCLUSIVE verdict. 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
-  verdict and (when it ran) the browser evidence into ONE combined verdict,
-  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 `verify_browser` phase drives the UI in a real headless Chromium and
-  captures screenshot evidence; everywhere else it is silently skipped (graceful
-  degradation) and the text verdict stands alone. The synthesis runs either way.
-
-  Triggered by:
-    - a `@last-light verify <claim>` comment on an issue/PR
-    - manual CLI: tsx src/cli.ts verify owner/repo#N -- "<claim>"
-
-status_checklist: true
-final_message: "{{synthesisResult}}"
-
-phases:
-  - name: phase_0
-    label: Context
-    type: context
-    depends_on: []
-
-  - name: verify
-    label: Verify
-    depends_on: [phase_0]
-    prompt: prompts/verify.md
-    # verify: the investigator procedure + report shape (primary).
-    # building: install + run the repo to capture evidence.
-    skills: [verify, building]
-    model: "{{models.verify}}"
-    variant: "{{variants.verify}}"
-    output_var: verifyResult
-    messages:
-      on_start: "Verifying the claim — installing, running, and capturing evidence..."
-      on_success: "Text verification complete."
-      on_failure: "I couldn't complete the verification — 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
-  # `verify`, so it still runs (after this phase, by declaration order) and
-  # folds in `verifyBrowserResult` only when this phase actually produced it.
-  - name: verify_browser
-    label: Verify (browser)
-    depends_on: [verify]
-    prompt: prompts/verify-browser.md
-    skills: [verify, building, browser-qa]
-    model: "{{models.verify}}"
-    variant: "{{variants.verify}}"
-    requires_sandbox: docker
-    sandbox_image: qa
-    output_var: verifyBrowserResult
-    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 verdict stands."
-
-  # Synthesis. Depends only on `verify` (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 concise combined
-  # verdict; 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: [verify, verify_browser]
-    prompt: prompts/verify-synth.md
-    model: "{{models.verify}}"
-    variant: "{{variants.verify}}"
-    output_var: synthesisResult
-    messages:
-      on_start: "Synthesizing the final verdict..."
-      on_success: "Verdict posted below."
-      on_failure: "I couldn't synthesize the final verdict — see the logs."