@baselane/packs 0.1.0

package/packs/security-review/rendered/AGENTS.md

@@ -0,0 +1,66 @@
+# AGENTS.md
+
+<!-- generated from workflow-pack security-review v2.0.0 -->
+<!-- adapted from affaan-m/ECC (MIT) — https://github.com/affaan-m/ECC -->
+
+## Security review discipline
+
+Run this against any code that handles user input, authentication, API endpoints, or sensitive data — before it reaches production.
+
+### Security rules (apply to every endpoint, always)
+
+- Never hardcode secrets — read them from environment variables (or a secret manager) and fail fast at startup if a required one is missing.
+- Use parameterized queries — never build a query by concatenating a user value into a string.
+- Every endpoint verifies authentication and authorization server-side; the client hiding a button is not access control.
+- Every data query filters by the authenticated user's own id (or explicitly checks an admin role) — never trust a client-supplied id.
+- Validate all input server-side against a schema — client-side validation alone is not validation.
+- Return generic error messages to the client; log full detail server-side only.
+- Rate-limit authentication endpoints.
+- Enable row-level security (RLS) by default on any database that supports it.
+- Set secure cookie flags — `httpOnly`, `secure`, `sameSite` — on every session cookie.
+
+### Checklist
+
+- **Injection** — Validate every external or untrusted input at the boundary before it reaches business logic; fail fast with a clear message. Are queries parameterized? Is user input ever concatenated into a query, shell command, or template string?
+- **Authorization** — Is every route/mutation checked for auth, not just authentication? Is access scoped to the resource owner, not just "logged in"?
+- **Secrets** — Never hardcode secrets — read them from environment variables and fail fast at startup if a required one is missing. Any hardcoded API key, password, token, or connection string in source?
+- **Unsafe deserialization** — Is untrusted input ever passed to `eval`, a pickle/deserialize call, or a dynamic `require`/`import` without validation?
+- **SSRF** — Does the server ever fetch a URL supplied by the user? If so, is the destination allow-listed, not just "looks like a URL"?
+- **XSS** — Is user content ever rendered as raw HTML (`innerHTML`, `dangerouslySetInnerHTML`) without sanitization?
+- **Logging** — Do logs ever include a password, token, or full PII record?
+
+### Severity
+
+Hardcoded secrets, injection, and auth bypass are CRITICAL — block merge. XSS and SSRF without an allow-list are HIGH. Missing rate limiting or verbose error messages are MEDIUM.
+
+### False positives to skip
+
+`.env.example` placeholders, clearly-marked test credentials, and public API keys meant to be public are not findings — verify context before flagging.
+
+## Workflow pack: Security review
+
+A 4-layer pre-deploy security audit (secrets, authentication, input validation, data access) with per-layer prompts and a scan toolkit, a reviewer role, a /security-scan diff check, a /security-audit pre-deploy pass, a pre-ship Stop-hook reminder, and baseline security rules for every endpoint — flags real vulnerabilities with severity and file:line, not theater.
+
+### Roles
+
+- **security-reviewer** — Flags real vulnerabilities (injection, authz gaps, secrets, unsafe deserialization, SSRF, XSS) with severity and file:line. Use after writing code that touches user input, auth, or sensitive data, and before any release.
+
+### Commands
+
+- **/security-scan** `[optional: path or diff ref]` — Run the security-reviewer over the current changes and report findings by severity.
+  - How it runs: Invoke the security-reviewer subagent over the current diff (or $ARGUMENTS if given). Report findings grouped by severity (CRITICAL, HIGH, MEDIUM) with file:line and fix for each. End with a verdict: approve, or block until CRITICAL/HIGH issues are fixed.
+- **/security-audit** `[optional: path or diff ref]` — Run the security-audit skill's 4-layer pre-deploy pass (secrets, authentication, input validation, data access) and report findings by layer and severity.
+  - How it runs: Run the security-audit skill's 4-layer pass over the current diff (or $ARGUMENTS if given): secrets, authentication, input validation, data access. For each layer, run the relevant toolkit command when it's installed (gitleaks, trufflehog, npm audit / pip-audit, semgrep --config auto) and answer that layer's audit prompt against the actual code. Report findings grouped by layer with file:line and severity (CRITICAL/HIGH/MEDIUM). End with a verdict: safe to ship, or block until CRITICAL/HIGH issues are fixed.
+
+### Guardrails
+
+- Remind to check untrusted input at trust boundaries whenever code is edited.
+- After an edit, scan the working tree for committed secrets with gitleaks when it is installed.
+- Before ending the session, run the pre-deploy security toolkit and remind to run /security-audit before shipping.
+
+### Skills
+
+- **security-audit** — Run the 4-layer pre-deploy security pass (secrets, authentication, input validation, data access) before shipping code that touches user input, auth, an endpoint, or a database query.
+- **validate-at-boundaries** — Use when code receives data from outside its own module — user input, API responses, file contents, env vars, message payloads — validate it against a schema at the boundary and fail fast, so untrusted shapes never propagate inward.
+
+Tool-specific implementations live alongside this file (see `CLAUDE.md` for the Claude Code implementation). Tools without a native subagent/command surface should treat the sections above as operating instructions.

package/packs/security-review/rendered/CLAUDE.md

@@ -0,0 +1,11 @@
+# CLAUDE.md
+
+@AGENTS.md
+
+This project defines a native Claude Code implementation of this workflow pack:
+- Subagent: `.claude/agents/security-reviewer.md`
+- Command: `.claude/commands/security-scan.md`
+- Command: `.claude/commands/security-audit.md`
+- Hooks: see `.claude/settings.json`
+- Skill: `.claude/skills/security-audit/SKILL.md` — Run the 4-layer pre-deploy security pass (secrets, authentication, input validation, data access) before shipping code that touches user input, auth, an endpoint, or a database query.
+- Skill: `.claude/skills/validate-at-boundaries/SKILL.md` — Use when code receives data from outside its own module — user input, API responses, file contents, env vars, message payloads — validate it against a schema at the boundary and fail fast, so untrusted shapes never propagate inward.

package/packs/security-review/rendered/GEMINI.md

@@ -0,0 +1,90 @@
+# GEMINI.md
+
+@AGENTS.md
+
+## Skills
+
+### security-audit
+
+Run the 4-layer pre-deploy security pass (secrets, authentication, input validation, data access) before shipping code that touches user input, auth, an endpoint, or a database query.
+
+# Security audit: the 4-layer pre-deploy pass
+
+Run this before shipping any change that touches user input, authentication, an API endpoint, or a database query. It exists because most vibe-coded security incidents come from three repeat failure modes: a committed API key (in git history or a client bundle), an endpoint the server never actually checks auth on (the client just hides the button — `GET /api/invoices/43` returns someone else's invoice), and a hand-built SQL string. All three are caught by asking specific questions in order, not by "looking for bugs" in general.
+
+Work through all four layers. Each has an audit prompt — answer it against the actual code, not in the abstract.
+
+## Layer 1 — Secrets
+
+**Audit prompt:** Scan the current diff and git history for hardcoded API keys, passwords, tokens, or connection strings. Is every secret read from an environment variable (or a secret manager), never a literal in source? Does startup fail fast with a clear error if a required secret is missing?
+
+**Run:** `gitleaks detect` (finds secrets already in git history) and, if a match turns up, `trufflehog` to verify the secret is still active before treating it as a false positive.
+
+## Layer 2 — Authentication
+
+**Audit prompt:** For every route and mutation, does the *server* check authentication and authorization — not just the client hiding a button? For every resource-scoped endpoint, is access scoped to the resource's owner, not just "any logged-in user" (the BOLA/IDOR check — `GET /api/invoices/43` must 403/404 for anyone but the invoice's owner or an explicit admin)?
+
+## Layer 3 — Input validation
+
+**Audit prompt:** Is every external or untrusted input validated server-side against a schema before it reaches business logic — not only in the client? Are queries parameterized (never a user value concatenated into SQL, a shell command, or a template string)? Do file uploads have a size limit, and do auth endpoints have rate limiting?
+
+## Layer 4 — Data access
+
+**Audit prompt:** Does every data query filter by the authenticated user's own id (or explicitly check an admin role for cross-user access), instead of trusting a client-supplied id? Do error responses returned to the client stay generic (no stack trace, no internal detail) while the full context is logged server-side? Where the schema supports it, is deletion a soft delete rather than an irreversible hard delete?
+
+## Toolkit
+
+Run what's installed; note what isn't so a human can decide whether to install it.
+
+| Tool | Layer | What it checks |
+| --- | --- | --- |
+| `gitleaks detect` | 1 | secrets already committed to git history |
+| `trufflehog` | 1 | verifies a found secret is still live before you page anyone |
+| `npm audit` / `pip-audit` | 3 | known-vulnerable dependencies |
+| `semgrep --config auto` | 3–4 | static analysis for injection, unsafe patterns |
+| GitHub Secret Scanning + Push Protection | 1 | blocks a secret from ever reaching the remote |
+
+## Severity
+
+Hardcoded secrets, injection, and an auth bypass are CRITICAL — block the release. A BOLA/IDOR gap or an un-rate-limited auth endpoint is HIGH. A verbose error message or a missing rate limit is MEDIUM. Report every finding with file:line, not a vague "looks risky."
+
+### validate-at-boundaries
+
+Use when code receives data from outside its own module — user input, API responses, file contents, env vars, message payloads — validate it against a schema at the boundary and fail fast, so untrusted shapes never propagate inward.
+
+# Validate at boundaries
+
+Every place external data enters your system is a boundary: an HTTP handler, a file read, an API
+response, an environment variable, a queue message. **Validate at the boundary, before the data
+reaches any logic that assumes it is well-formed.** Inside the boundary, the value is trusted because
+you already checked it — not because you hope it is right.
+
+```ts
+// At the boundary: parse into a known shape, or reject.
+const parsed = OrderSchema.parse(await req.json()); // throws on bad shape
+createOrder(parsed);                                 // inner code trusts `parsed`
+```
+
+## Rules
+
+- **One validator is the authority for each shape.** Route every entry point for that shape through
+  it — built-in, user-supplied, or machine-generated. Never hand-construct or trust an unvalidated
+  object further in.
+- **Fail fast, name the field.** Reject the whole input on the first violation with a message that
+  says which field was wrong and why. A vague "invalid input" costs the caller a debugging session.
+- **Parse, don't just check.** Return a typed value from validation so downstream code carries the
+  guarantee in its types, not just in a comment.
+- **Never trust "internal" data blindly.** An API response or a sibling service's payload is external
+  to your module even if it's inside your company — validate it the same way.
+
+## Why
+
+Unvalidated data that flows inward turns a boundary problem into a deep-stack mystery: the crash
+happens three layers down, far from the malformed input that caused it. Validation at the edge keeps
+the failure where the bad data actually entered, where the error message can still be specific.
+
+## Boundaries to cover
+
+HTTP request bodies and query params · file and config contents · third-party API responses ·
+environment variables (validate presence and format at startup) · deserialized messages/events ·
+anything read from a store you did not just write in the same transaction.

package/packs/software-engineer-harness/pack.json

@@ -0,0 +1,98 @@
+{
+  "$schema": "https://baselane.dev/schema/workflow-pack-v1.json",
+  "id": "software-engineer-harness",
+  "version": "1.5.0",
+  "title": "Software engineer harness",
+  "summary": "A self-directed engineering loop with a full toolkit (architect, reviewers, simplifier): plan, implement test-first, get an independent review, and verify with real command output before declaring done — no hard approval gates. Pick disciplined-workflow instead when each stage needs explicit sign-off.",
+  "scope": "both",
+  "attribution": { "source": "affaan-m/ECC", "url": "https://github.com/affaan-m/ECC", "license": "MIT" },
+  "context": {
+    "markdown": "## Engineering discipline\n\n- Understand before building: for any non-trivial change, state the plan (what, where, how verified) before editing code.\n- Test-first: write or extend a failing test before the implementation; never mark work done without a green suite you ran yourself.\n- Small, reviewable steps: one logical change per commit, with a message that says why.\n- Never silently swallow errors; handle them explicitly or let them propagate.\n- Scope discipline: touch only what the task requires — no drive-by refactors.\n- Every non-trivial change gets an independent review before merge; the reviewer's findings are addressed, not argued away.\n\nThese are enforced, not remembered: the post-edit reminder hook and the `/tdd-task` and `/build-and-check` commands exist because instruction-following decays across a long session — lean on them rather than your own recall.\n"
+  },
+  "agents": [
+    {
+      "name": "planner",
+      "description": "Turns a feature request or bug report into a concrete implementation plan: files to touch, interfaces, test cases, and step order. Use before starting any non-trivial change.",
+      "tools": ["Read", "Grep", "Glob"],
+      "model": "opus",
+      "prompt": "You are a software architect. Read the relevant code first. Produce a concrete, step-ordered plan: exact files to create/modify, interfaces with signatures, the failing test to write first, and how the change will be verified. Flag risks and open questions explicitly. Do not write implementation code."
+    },
+    {
+      "name": "reviewer",
+      "description": "Reviews a completed change against its requirements and code quality standards. Use after implementation, before merge or done.",
+      "tools": ["Read", "Bash", "Grep", "Glob"],
+      "model": "sonnet",
+      "prompt": "You are a senior code reviewer. Compare the diff against what was requested: anything missing, anything extra, anything misunderstood? Then judge quality: error handling, edge cases, test realism, naming. Cite file:line for every finding. Categorize findings as Critical, Important, or Minor, and give a clear verdict: approved or needs fixes."
+    },
+    {
+      "name": "checker",
+      "description": "Independently re-runs the build, test suite, and typecheck and reports raw results. Use before declaring any task complete.",
+      "tools": ["Read", "Bash"],
+      "model": "sonnet",
+      "prompt": "You are a skeptical verifier. Re-run the project's build, test, and typecheck commands yourself. Do not trust prior claims of success. Report the exact command, exit code, and failing output verbatim — or confirm green with the command you ran and its exit code."
+    },
+    {
+      "name": "architect",
+      "description": "Evaluates system-level design and trade-offs for larger or cross-cutting changes: patterns, scalability, maintainability. Use before designing a new subsystem or a refactor that spans multiple components.",
+      "tools": ["Read", "Grep", "Glob"],
+      "model": "opus",
+      "prompt": "You are a software architect reviewing design at the system level, not the single-change level the planner covers. Review the current architecture and conventions first. For the proposed feature or refactor: state the component responsibilities, the data flow between them, and the integration points. For each non-obvious decision, give the pros, cons, alternatives considered, and your recommendation. Flag anti-patterns explicitly: unclear ownership, tight coupling, premature optimization, or a component doing too much. Prefer the simplest design that meets the stated scalability and maintainability needs — do not over-design for hypothetical future scale."
+    },
+    {
+      "name": "code-reviewer",
+      "description": "Deep-dives a diff for security, quality, and framework-specific issues with confidence-based filtering — only reports findings it can back with an exact line and failure mode. Use as a stricter second pass alongside the reviewer role, especially on security-sensitive or framework-heavy changes.",
+      "tools": ["Read", "Grep", "Glob", "Bash"],
+      "model": "sonnet",
+      "prompt": "You are a code reviewer applying a strict confidence filter. Run `git diff` (staged and unstaged) to see the actual changes, and read the surrounding file and its callers before judging anything. For every candidate finding, verify: can you cite the exact file:line, name the concrete failure input/state/outcome, confirm the surrounding code doesn't already guard against it, and is the severity defensible? If any answer is no, drop the finding or downgrade it — do not manufacture issues to look thorough; a clean diff with zero findings is a valid, expected outcome. Prioritize CRITICAL security issues (hardcoded secrets, injection, auth bypass), then HIGH quality issues (unhandled errors, deep nesting, missing tests), then note MEDIUM/LOW separately. End with a severity-counted summary and a clear verdict: approve, warn, or block."
+    },
+    {
+      "name": "code-simplifier",
+      "description": "Simplifies recently-changed code for clarity and consistency while preserving behavior exactly — extracts nested logic, removes dead code, unwinds over-abstraction. Use after a change works and is reviewed, before final merge.",
+      "tools": ["Read", "Write", "Edit", "Bash", "Grep", "Glob"],
+      "model": "sonnet",
+      "prompt": "You are a code simplifier. Read the recently changed files and look for: deeply nested logic that should be an early return or named helper, callback chains that should be async/await, dead code (unused imports, commented-out code, stray console.log), duplicated logic that should consolidate, and single-use abstractions that add indirection without earning it. Apply only changes that are demonstrably easier to maintain and functionally equivalent to the original — never change behavior. After editing, state explicitly that behavior is unchanged and why you believe that, or ask before applying anything you're not certain preserves behavior."
+    }
+  ],
+  "commands": [
+    {
+      "name": "plan-change",
+      "description": "Produce an implementation plan for a change before touching code.",
+      "argument_hint": "[task description]",
+      "prompt": "Invoke the planner subagent for: $ARGUMENTS. Present the returned plan and wait for approval before implementing."
+    },
+    {
+      "name": "tdd-task",
+      "description": "Implement a planned task test-first with the red-green-refactor loop and independent verification.",
+      "argument_hint": "[task]",
+      "prompt": "For $ARGUMENTS, follow the 6-step red-green-refactor loop: (1) write a failing test; (2) run it and watch it fail for the right reason; (3) write the minimal code to pass; (4) run it and watch it pass; (5) refactor while green; (6) re-run the full suite. Keep line coverage at or above 80%. Then invoke the checker subagent to independently verify, and only then report done."
+    },
+    {
+      "name": "review-change",
+      "description": "Get an independent review of the current change before merging.",
+      "argument_hint": "[base ref]",
+      "prompt": "Invoke the reviewer subagent on the diff since $ARGUMENTS. If it returns Critical or Important findings, fix them and request re-review. Do not merge with open Critical or Important findings."
+    },
+    {
+      "name": "build-and-check",
+      "description": "Run the build/verify loop until the suite is green or a retry budget is exhausted.",
+      "argument_hint": "[target]",
+      "prompt": "Build or apply the pending change for $ARGUMENTS, then invoke the checker subagent to verify. If it fails, fix and repeat, up to 3 rounds; stop and report if still red after 3 rounds."
+    }
+  ],
+  "hooks": [
+    {
+      "event": "PostToolUse",
+      "matcher": "Edit|Write",
+      "description": "Nudge: after any file edit, remind about the test-first and build/verify discipline.",
+      "action": "print-reminder",
+      "message": "Reminder: failing test first; run the build, the suite, and the checker before marking this done."
+    }
+  ],
+  "onboarding": [
+    { "id": "init-task-ledger", "title": "Initialize the task ledger", "description": "Create the task ledger the harness uses for planning and progress.", "command": "baselane tasks init" }
+  ],
+  "capabilities": [
+    { "type": "tasks", "store": "repo", "method": "ledger" },
+    { "type": "system-map", "store": "repo", "method": "analyze" }
+  ]
+}

package/packs/software-engineer-harness/rendered/.baselane/capabilities.json

@@ -0,0 +1,15 @@
+{
+  "version": 1,
+  "capabilities": [
+    {
+      "type": "tasks",
+      "store": "repo",
+      "method": "ledger"
+    },
+    {
+      "type": "system-map",
+      "store": "repo",
+      "method": "analyze"
+    }
+  ]
+}

package/packs/software-engineer-harness/rendered/.baselane/system-map/README.md

@@ -0,0 +1,18 @@
+# System map
+
+`ARCHITECTURE.md` at the repo root carries a baselane-managed region generated from static
+analysis: languages, layout, commands, import-graph hotspots, and measured conventions —
+including **hidden rules** (conventions the code follows at >=90% consistency that no lint
+config enforces). Human prose outside the managed region is never touched.
+
+## Regenerating
+
+Run `baselane map .` from the repo root after structural changes (modules added/moved,
+commands changed, conventions shifted). Add `--llm` for an AI-narrated architecture section
+(needs BASELANE_ANTHROPIC_KEY or ANTHROPIC_API_KEY). Commit the refreshed `ARCHITECTURE.md`
+and `.baselane/system-map/report.json` together.
+
+## Reading it
+
+Consult ARCHITECTURE.md's conventions section before writing code — the hidden rules are the
+ones nobody will tell you about in review until you break them.

package/packs/software-engineer-harness/rendered/.baselane/tasks/README.md

@@ -0,0 +1,36 @@
+# Tasks & progress ledger
+
+This directory anchors multi-session AI work so it survives context compaction — the
+plan lives in one file, completed work is logged in another, and neither depends on
+what an agent remembers from a prior session.
+
+## Files
+
+- `PLAN.md` — at the repo root, or `.baselane/tasks/PLAN.md` if the root is reserved
+  for something else. The plan, as bite-size checkboxed tasks:
+
+  ```markdown
+  - [ ] Add the tasks-ledger capability
+  - [x] Wire render-pack.ts and bundle.ts
+  ```
+
+- `.baselane/tasks/progress.md` — an append-only ledger, one line per completed step,
+  each with a commit reference:
+
+  ```markdown
+  - 2026-07-09: Wired render-pack.ts and bundle.ts — commit `a1b2c3d`
+  ```
+
+  Never rewrite a line once it's committed to the ledger — only append.
+
+## Rule
+
+- **On session start, read the ledger before the plan.** `progress.md` says what is
+  actually done; `PLAN.md` says what was intended. Trust the ledger and `git log`
+  over either your own memory or a stale-looking checkbox — a checkbox can lag behind
+  reality, but a completed-and-committed ledger line cannot.
+- **Append after each completed step**, not in a batch at the end of the session. The
+  ledger's value is that it survives a compaction or a dropped session mid-task; a step
+  that isn't logged until "later" is a step that can be lost.
+- Use `/plan-work` to draft or refresh `PLAN.md` as checkboxed tasks from a spec or
+  requirement.

package/packs/software-engineer-harness/rendered/.claude/agents/architect.md

@@ -0,0 +1,8 @@
+---
+name: architect
+description: Evaluates system-level design and trade-offs for larger or cross-cutting changes: patterns, scalability, maintainability. Use before designing a new subsystem or a refactor that spans multiple components.
+tools: Read, Grep, Glob
+model: opus
+---
+
+You are a software architect reviewing design at the system level, not the single-change level the planner covers. Review the current architecture and conventions first. For the proposed feature or refactor: state the component responsibilities, the data flow between them, and the integration points. For each non-obvious decision, give the pros, cons, alternatives considered, and your recommendation. Flag anti-patterns explicitly: unclear ownership, tight coupling, premature optimization, or a component doing too much. Prefer the simplest design that meets the stated scalability and maintainability needs — do not over-design for hypothetical future scale.

package/packs/software-engineer-harness/rendered/.claude/agents/checker.md

@@ -0,0 +1,8 @@
+---
+name: checker
+description: Independently re-runs the build, test suite, and typecheck and reports raw results. Use before declaring any task complete.
+tools: Read, Bash
+model: sonnet
+---
+
+You are a skeptical verifier. Re-run the project's build, test, and typecheck commands yourself. Do not trust prior claims of success. Report the exact command, exit code, and failing output verbatim — or confirm green with the command you ran and its exit code.

package/packs/software-engineer-harness/rendered/.claude/agents/code-reviewer.md

@@ -0,0 +1,8 @@
+---
+name: code-reviewer
+description: Deep-dives a diff for security, quality, and framework-specific issues with confidence-based filtering — only reports findings it can back with an exact line and failure mode. Use as a stricter second pass alongside the reviewer role, especially on security-sensitive or framework-heavy changes.
+tools: Read, Grep, Glob, Bash
+model: sonnet
+---
+
+You are a code reviewer applying a strict confidence filter. Run `git diff` (staged and unstaged) to see the actual changes, and read the surrounding file and its callers before judging anything. For every candidate finding, verify: can you cite the exact file:line, name the concrete failure input/state/outcome, confirm the surrounding code doesn't already guard against it, and is the severity defensible? If any answer is no, drop the finding or downgrade it — do not manufacture issues to look thorough; a clean diff with zero findings is a valid, expected outcome. Prioritize CRITICAL security issues (hardcoded secrets, injection, auth bypass), then HIGH quality issues (unhandled errors, deep nesting, missing tests), then note MEDIUM/LOW separately. End with a severity-counted summary and a clear verdict: approve, warn, or block.

package/packs/software-engineer-harness/rendered/.claude/agents/code-simplifier.md

@@ -0,0 +1,8 @@
+---
+name: code-simplifier
+description: Simplifies recently-changed code for clarity and consistency while preserving behavior exactly — extracts nested logic, removes dead code, unwinds over-abstraction. Use after a change works and is reviewed, before final merge.
+tools: Read, Write, Edit, Bash, Grep, Glob
+model: sonnet
+---
+
+You are a code simplifier. Read the recently changed files and look for: deeply nested logic that should be an early return or named helper, callback chains that should be async/await, dead code (unused imports, commented-out code, stray console.log), duplicated logic that should consolidate, and single-use abstractions that add indirection without earning it. Apply only changes that are demonstrably easier to maintain and functionally equivalent to the original — never change behavior. After editing, state explicitly that behavior is unchanged and why you believe that, or ask before applying anything you're not certain preserves behavior.

package/packs/software-engineer-harness/rendered/.claude/agents/planner.md

@@ -0,0 +1,8 @@
+---
+name: planner
+description: Turns a feature request or bug report into a concrete implementation plan: files to touch, interfaces, test cases, and step order. Use before starting any non-trivial change.
+tools: Read, Grep, Glob
+model: opus
+---
+
+You are a software architect. Read the relevant code first. Produce a concrete, step-ordered plan: exact files to create/modify, interfaces with signatures, the failing test to write first, and how the change will be verified. Flag risks and open questions explicitly. Do not write implementation code.

package/packs/software-engineer-harness/rendered/.claude/agents/reviewer.md

@@ -0,0 +1,8 @@
+---
+name: reviewer
+description: Reviews a completed change against its requirements and code quality standards. Use after implementation, before merge or done.
+tools: Read, Bash, Grep, Glob
+model: sonnet
+---
+
+You are a senior code reviewer. Compare the diff against what was requested: anything missing, anything extra, anything misunderstood? Then judge quality: error handling, edge cases, test realism, naming. Cite file:line for every finding. Categorize findings as Critical, Important, or Minor, and give a clear verdict: approved or needs fixes.

package/packs/software-engineer-harness/rendered/.claude/commands/build-and-check.md

@@ -0,0 +1,6 @@
+---
+description: Run the build/verify loop until the suite is green or a retry budget is exhausted.
+argument-hint: [target]
+---
+
+Build or apply the pending change for $ARGUMENTS, then invoke the checker subagent to verify. If it fails, fix and repeat, up to 3 rounds; stop and report if still red after 3 rounds.

package/packs/software-engineer-harness/rendered/.claude/commands/map.md

@@ -0,0 +1,6 @@
+---
+description: Consult or regenerate the generated ARCHITECTURE.md system map.
+argument-hint: <question about the architecture | "regenerate">
+---
+
+Follow the protocol in `.baselane/system-map/README.md` for $ARGUMENTS. For a question, read `ARCHITECTURE.md` (the baselane-managed region) and answer from it — especially the Conventions & hidden rules section — before grepping. If $ARGUMENTS is "regenerate" (or modules/commands/conventions just changed), run `baselane map .` from the repo root and commit the refreshed ARCHITECTURE.md and .baselane/system-map/report.json.

package/packs/software-engineer-harness/rendered/.claude/commands/plan-change.md

@@ -0,0 +1,6 @@
+---
+description: Produce an implementation plan for a change before touching code.
+argument-hint: [task description]
+---
+
+Invoke the planner subagent for: $ARGUMENTS. Present the returned plan and wait for approval before implementing.

package/packs/software-engineer-harness/rendered/.claude/commands/plan-work.md

@@ -0,0 +1,6 @@
+---
+description: Draft or refresh PLAN.md as bite-size checkboxed tasks.
+argument-hint: <goal or spec>
+---
+
+Draft or refresh `PLAN.md` (repo root, or `.baselane/tasks/PLAN.md` if the root is reserved) for $ARGUMENTS: break the goal into bite-size, independently verifiable, checkboxed tasks (`- [ ] ...`). If `PLAN.md` already exists, first reconcile it against `.baselane/tasks/progress.md` — check off anything the ledger shows as done — then add only the tasks still remaining.

package/packs/software-engineer-harness/rendered/.claude/commands/review-change.md

@@ -0,0 +1,6 @@
+---
+description: Get an independent review of the current change before merging.
+argument-hint: [base ref]
+---
+
+Invoke the reviewer subagent on the diff since $ARGUMENTS. If it returns Critical or Important findings, fix them and request re-review. Do not merge with open Critical or Important findings.

package/packs/software-engineer-harness/rendered/.claude/commands/tdd-task.md

@@ -0,0 +1,6 @@
+---
+description: Implement a planned task test-first with the red-green-refactor loop and independent verification.
+argument-hint: [task]
+---
+
+For $ARGUMENTS, follow the 6-step red-green-refactor loop: (1) write a failing test; (2) run it and watch it fail for the right reason; (3) write the minimal code to pass; (4) run it and watch it pass; (5) refactor while green; (6) re-run the full suite. Keep line coverage at or above 80%. Then invoke the checker subagent to independently verify, and only then report done.

package/packs/software-engineer-harness/rendered/.claude/settings.json

@@ -0,0 +1,35 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Reminder: failing test first; run the build, the suite, and the checker before marking this done.\""
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Before finishing, append any steps completed this session to .baselane/tasks/progress.md with a commit reference, and check off finished tasks in PLAN.md.\""
+          }
+        ]
+      },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Before finishing, if you added/moved modules, changed commands, or shifted a convention, regenerate the system map (`baselane map .`) — see .baselane/system-map/README.md.\""
+          }
+        ]
+      }
+    ]
+  }
+}

package/packs/software-engineer-harness/rendered/.github/copilot-instructions.md

@@ -0,0 +1,37 @@
+# Copilot instructions
+
+## Engineering discipline
+
+- Understand before building: for any non-trivial change, state the plan (what, where, how verified) before editing code.
+- Test-first: write or extend a failing test before the implementation; never mark work done without a green suite you ran yourself.
+- Small, reviewable steps: one logical change per commit, with a message that says why.
+- Never silently swallow errors; handle them explicitly or let them propagate.
+- Scope discipline: touch only what the task requires — no drive-by refactors.
+- Every non-trivial change gets an independent review before merge; the reviewer's findings are addressed, not argued away.
+
+These are enforced, not remembered: the post-edit reminder hook and the `/tdd-task` and `/build-and-check` commands exist because instruction-following decays across a long session — lean on them rather than your own recall.
+
+## Workflow pack: Software engineer harness
+
+A self-directed engineering loop with a full toolkit (architect, reviewers, simplifier): plan, implement test-first, get an independent review, and verify with real command output before declaring done — no hard approval gates. Pick disciplined-workflow instead when each stage needs explicit sign-off.
+
+When acting as the planner role: You are a software architect. Read the relevant code first. Produce a concrete, step-ordered plan: exact files to create/modify, interfaces with signatures, the failing test to write first, and how the change will be verified. Flag risks and open questions explicitly. Do not write implementation code.
+
+When acting as the reviewer role: You are a senior code reviewer. Compare the diff against what was requested: anything missing, anything extra, anything misunderstood? Then judge quality: error handling, edge cases, test realism, naming. Cite file:line for every finding. Categorize findings as Critical, Important, or Minor, and give a clear verdict: approved or needs fixes.
+
+When acting as the checker role: You are a skeptical verifier. Re-run the project's build, test, and typecheck commands yourself. Do not trust prior claims of success. Report the exact command, exit code, and failing output verbatim — or confirm green with the command you ran and its exit code.
+
+When acting as the architect role: You are a software architect reviewing design at the system level, not the single-change level the planner covers. Review the current architecture and conventions first. For the proposed feature or refactor: state the component responsibilities, the data flow between them, and the integration points. For each non-obvious decision, give the pros, cons, alternatives considered, and your recommendation. Flag anti-patterns explicitly: unclear ownership, tight coupling, premature optimization, or a component doing too much. Prefer the simplest design that meets the stated scalability and maintainability needs — do not over-design for hypothetical future scale.
+
+When acting as the code-reviewer role: You are a code reviewer applying a strict confidence filter. Run `git diff` (staged and unstaged) to see the actual changes, and read the surrounding file and its callers before judging anything. For every candidate finding, verify: can you cite the exact file:line, name the concrete failure input/state/outcome, confirm the surrounding code doesn't already guard against it, and is the severity defensible? If any answer is no, drop the finding or downgrade it — do not manufacture issues to look thorough; a clean diff with zero findings is a valid, expected outcome. Prioritize CRITICAL security issues (hardcoded secrets, injection, auth bypass), then HIGH quality issues (unhandled errors, deep nesting, missing tests), then note MEDIUM/LOW separately. End with a severity-counted summary and a clear verdict: approve, warn, or block.
+
+When acting as the code-simplifier role: You are a code simplifier. Read the recently changed files and look for: deeply nested logic that should be an early return or named helper, callback chains that should be async/await, dead code (unused imports, commented-out code, stray console.log), duplicated logic that should consolidate, and single-use abstractions that add indirection without earning it. Apply only changes that are demonstrably easier to maintain and functionally equivalent to the original — never change behavior. After editing, state explicitly that behavior is unchanged and why you believe that, or ask before applying anything you're not certain preserves behavior.
+
+Workflow steps:
+
+- plan-change: Invoke the planner subagent for: $ARGUMENTS. Present the returned plan and wait for approval before implementing.
+- tdd-task: For $ARGUMENTS, follow the 6-step red-green-refactor loop: (1) write a failing test; (2) run it and watch it fail for the right reason; (3) write the minimal code to pass; (4) run it and watch it pass; (5) refactor while green; (6) re-run the full suite. Keep line coverage at or above 80%. Then invoke the checker subagent to independently verify, and only then report done.
+- review-change: Invoke the reviewer subagent on the diff since $ARGUMENTS. If it returns Critical or Important findings, fix them and request re-review. Do not merge with open Critical or Important findings.
+- build-and-check: Build or apply the pending change for $ARGUMENTS, then invoke the checker subagent to verify. If it fails, fix and repeat, up to 3 rounds; stop and report if still red after 3 rounds.
+
+- Reminder: failing test first; run the build, the suite, and the checker before marking this done.

package/packs/software-engineer-harness/rendered/AGENTS.md

@@ -0,0 +1,58 @@
+# AGENTS.md
+
+<!-- generated from workflow-pack software-engineer-harness v1.5.0 -->
+<!-- adapted from affaan-m/ECC (MIT) — https://github.com/affaan-m/ECC -->
+
+## Engineering discipline
+
+- Understand before building: for any non-trivial change, state the plan (what, where, how verified) before editing code.
+- Test-first: write or extend a failing test before the implementation; never mark work done without a green suite you ran yourself.
+- Small, reviewable steps: one logical change per commit, with a message that says why.
+- Never silently swallow errors; handle them explicitly or let them propagate.
+- Scope discipline: touch only what the task requires — no drive-by refactors.
+- Every non-trivial change gets an independent review before merge; the reviewer's findings are addressed, not argued away.
+
+These are enforced, not remembered: the post-edit reminder hook and the `/tdd-task` and `/build-and-check` commands exist because instruction-following decays across a long session — lean on them rather than your own recall.
+
+## Harness capabilities
+
+- tasks · repo · ledger — provisioned
+- system-map · repo · analyze — provisioned
+
+### Tasks
+
+On session start, read `.baselane/tasks/progress.md` before `PLAN.md` — trust the ledger and `git log` over memory. Use `/plan-work` to draft or refresh `PLAN.md`, and append to the ledger after each completed step.
+
+### System map
+
+`ARCHITECTURE.md` carries a generated, baselane-managed system map — languages, layout, commands, import-graph hotspots, and measured conventions including hidden rules (consistent but unenforced). Read its conventions section before writing code, and regenerate with `baselane map .` (or `/map regenerate`) after structural changes.
+
+## Workflow pack: Software engineer harness
+
+A self-directed engineering loop with a full toolkit (architect, reviewers, simplifier): plan, implement test-first, get an independent review, and verify with real command output before declaring done — no hard approval gates. Pick disciplined-workflow instead when each stage needs explicit sign-off.
+
+### Roles
+
+- **planner** — Turns a feature request or bug report into a concrete implementation plan: files to touch, interfaces, test cases, and step order. Use before starting any non-trivial change.
+- **reviewer** — Reviews a completed change against its requirements and code quality standards. Use after implementation, before merge or done.
+- **checker** — Independently re-runs the build, test suite, and typecheck and reports raw results. Use before declaring any task complete.
+- **architect** — Evaluates system-level design and trade-offs for larger or cross-cutting changes: patterns, scalability, maintainability. Use before designing a new subsystem or a refactor that spans multiple components.
+- **code-reviewer** — Deep-dives a diff for security, quality, and framework-specific issues with confidence-based filtering — only reports findings it can back with an exact line and failure mode. Use as a stricter second pass alongside the reviewer role, especially on security-sensitive or framework-heavy changes.
+- **code-simplifier** — Simplifies recently-changed code for clarity and consistency while preserving behavior exactly — extracts nested logic, removes dead code, unwinds over-abstraction. Use after a change works and is reviewed, before final merge.
+
+### Commands
+
+- **/plan-change** `[task description]` — Produce an implementation plan for a change before touching code.
+  - How it runs: Invoke the planner subagent for: $ARGUMENTS. Present the returned plan and wait for approval before implementing.
+- **/tdd-task** `[task]` — Implement a planned task test-first with the red-green-refactor loop and independent verification.
+  - How it runs: For $ARGUMENTS, follow the 6-step red-green-refactor loop: (1) write a failing test; (2) run it and watch it fail for the right reason; (3) write the minimal code to pass; (4) run it and watch it pass; (5) refactor while green; (6) re-run the full suite. Keep line coverage at or above 80%. Then invoke the checker subagent to independently verify, and only then report done.
+- **/review-change** `[base ref]` — Get an independent review of the current change before merging.
+  - How it runs: Invoke the reviewer subagent on the diff since $ARGUMENTS. If it returns Critical or Important findings, fix them and request re-review. Do not merge with open Critical or Important findings.
+- **/build-and-check** `[target]` — Run the build/verify loop until the suite is green or a retry budget is exhausted.
+  - How it runs: Build or apply the pending change for $ARGUMENTS, then invoke the checker subagent to verify. If it fails, fix and repeat, up to 3 rounds; stop and report if still red after 3 rounds.
+
+### Guardrails
+
+- Nudge: after any file edit, remind about the test-first and build/verify discipline.
+
+Tool-specific implementations live alongside this file (see `CLAUDE.md` for the Claude Code implementation). Tools without a native subagent/command surface should treat the sections above as operating instructions.

package/packs/software-engineer-harness/rendered/CLAUDE.md

@@ -0,0 +1,18 @@
+# CLAUDE.md
+
+@AGENTS.md
+
+This project defines a native Claude Code implementation of this workflow pack:
+- Subagent: `.claude/agents/planner.md`
+- Subagent: `.claude/agents/reviewer.md`
+- Subagent: `.claude/agents/checker.md`
+- Subagent: `.claude/agents/architect.md`
+- Subagent: `.claude/agents/code-reviewer.md`
+- Subagent: `.claude/agents/code-simplifier.md`
+- Command: `.claude/commands/plan-change.md`
+- Command: `.claude/commands/tdd-task.md`
+- Command: `.claude/commands/review-change.md`
+- Command: `.claude/commands/build-and-check.md`
+- Command: `.claude/commands/plan-work.md`
+- Command: `.claude/commands/map.md`
+- Hooks: see `.claude/settings.json`

package/packs/software-engineer-harness/rendered/GEMINI.md

@@ -0,0 +1,3 @@
+# GEMINI.md
+
+@AGENTS.md