p-dev-harness 0.3.0 → 0.4.0

package/workspace-snapshot/files/.agents/skills/planner/SKILL.md

@@ -0,0 +1,263 @@
+---
+name: planner
+description: >-
+  Convert approved product intent or audit findings into implementation-ready
+  plans and reviewable PR slices. Use when planning feature work or audit
+  remediation before implementation runs.
+---
+
+# Planner
+
+Convert approved product intent, Linear issues, product requests, or audit reports into implementation-ready plans and reviewable PR slices. This skill is **planning only** — it produces plans; it does not modify code, create branches, open PRs, or run implementation.
+
+## When to use
+
+- A Linear issue is in **Ready for Planning** and needs a durable plan before build
+- An approved product request needs implementation-ready planning
+- A `code-health-audit`, `architecture-evolution-audit`, `security-audit`, or future audit report needs remediation planning
+- Work is too large for one reviewable PR and needs ordered PR slices
+- The operator wants a planner-consumable plan without implementation changes
+
+## Skill boundaries
+
+### Must do
+
+- Read the available source of intent: Linear issue, product request, prior plan, or audit report
+- Decide whether the work should be one PR or multiple PR slices
+- Produce reviewable, implementation-ready slices with scope, acceptance criteria, validation, dependencies, and ordering
+- Preserve out-of-scope boundaries from the source artifacts
+- For audit remediation, prioritize Critical / High / Medium findings and usually exclude Low / Info unless explicitly requested
+- Produce durable markdown suitable for a Linear plan comment or operator review
+
+### Must not do
+
+- Modify files, create branches, commit, open PRs, merge, deploy, or run implementation
+- Fix audit findings directly
+- Over-specify low-level code changes unless needed to preserve intent, constraints, or safety
+- Invent product requirements or architecture direction beyond the input artifacts
+- Duplicate implementation-agent responsibilities
+
+## Relationship to other roles
+
+| Role | Responsibility |
+|------|----------------|
+| **Audit skills** | Inspect and report findings |
+| **This skill (planner)** | Convert intent or findings into remediation plans and reviewable PR slices |
+| **Implementation agent** | Make scoped code changes on one selected slice |
+
+Do not duplicate audit or implementation responsibilities.
+
+## Planner modes
+
+- **feature-planning** — Use for approved product intent or Linear issues that need a plan before build. Output one implementation plan if the work is PR-sized; otherwise apply PR slicing and output multiple ordered slices.
+- **audit-remediation-planning** — Use for `code-health-audit`, `architecture-evolution-audit`, `security-audit`, or future audit reports. Convert findings into prioritized remediation slices without doing the fixes.
+
+If no mode is specified:
+
+- Linear issue / feature request → `feature-planning`
+- Audit report / finding IDs → `audit-remediation-planning`
+- Uninitialized product foundation issue → `feature-planning` with product foundation emphasis
+- Explicit request to split work → infer `feature-planning` or `audit-remediation-planning` from the source, then apply PR slicing rules
+
+## Uninitialized product foundation mode
+
+When the target repo marker on the development branch is `uninitialized`, or the issue includes `## Product foundation`:
+
+- Plan the approved architecture and foundation PR only — do not plan feature delivery beyond initialization.
+- Capture platform runtime, language/framework, repository structure, testing strategy, and CI strategy in the plan.
+- The foundation PR must update `.p-dev/product.json` with `approvedArchitecture` and remain technology-neutral in deployment assumptions.
+- Do not assume Vercel, npm, or any stack unless the issue or operator provides it.
+
+## Shared capability: PR slicing
+
+PR slicing is **not** a standalone planner mode. Apply it inside feature planning or audit-remediation planning when the work is too large for one reviewable PR.
+
+When slicing:
+
+- Focus on dependency order, independently reviewable scope, and validation per slice
+- Each slice must have clear reviewer value and be independently testable
+- Preserve ordering and dependencies explicitly
+- Avoid broad "refactor everything" slices
+
+## Inputs
+
+Ask for or infer:
+
+1. **Source artifact** — Linear issue, product request, prior plan, or audit report
+2. **Target repo path** and branch/ref
+3. **Planner mode** — `feature-planning` or `audit-remediation-planning` (infer if not specified)
+4. **Scope boundaries** — include / exclude paths or subsystems
+5. **Repo context** — `AGENTS.md`, README, architecture docs, `templates/implementation-plan.md`, prior plan comments
+6. **Audit finding IDs** — when planning audit remediation (e.g. `CH-001`, `AE-001`)
+
+**Sensible default:** plan from the current workspace and current branch using durable artifacts only. Do not run expensive, destructive, or long-running commands unless explicitly asked. Lightweight read-only inspection is allowed.
+
+## PR slicing rules
+
+- Prefer **one PR** when the work is narrow, low-risk, and reviewable as one change
+- **Split** when the work crosses subsystems, mixes product and refactor work, has independent validation boundaries, or would produce a hard-to-review diff
+- Each slice must have a clear user/reviewer value or maintenance outcome
+- Each slice must be independently testable
+- Do not mix unrelated cleanup with feature work unless the cleanup is necessary for that slice
+- Avoid "prep PR" slices unless they reduce real review risk and have observable value
+- Preserve ordering and dependencies explicitly
+- Avoid broad "rewrite everything" recommendations
+
+## Audit-remediation planning rules
+
+- Consume audit findings by stable ID (`CH-001`, `AE-001`, `SEC-001`, etc.) from `code-health-audit`, `architecture-evolution-audit`, `security-audit`, or future audit skills
+- Prioritize **Critical** (if emitted), then **High**, then **Medium**
+- Usually **exclude Low and Info** unless the operator explicitly asks or they are bundled into a nearby higher-priority slice with minimal additional scope
+- Convert findings into remediation goals and acceptance criteria, not implementation instructions
+- Keep security, performance/cost, and product/design findings out of code-health or architecture-evolution remediation unless the operator explicitly routes them to the appropriate audit/planning workflow
+- If findings require product or architecture judgment, mark them as `needs human decision` rather than planning implementation
+
+## Conditional release-impact analysis
+
+When the work touches a **published artifact**, deployment contract, persisted data contract, public API, installer, template/package surface, compatibility boundary, or versioned distribution:
+
+1. Inspect repo-specific release docs, manifests, package config, changelog, and versioning conventions before recommending a version increment.
+2. Do **not** assume npm or SemVer for every target repository.
+3. Classify release impact as one of:
+   - **No release impact** — safe to land without release preparation
+   - **Later release preparation required** — code/docs can merge, but a human-gated release step remains
+   - **Human decision required** — release policy, version bump, or distribution channel is unclear
+4. When relevant, identify compatibility, migration, rollback, and release-validation implications.
+5. Do **not** authorize publishing, tagging, deployment, or final release execution in the plan.
+
+For prototype or internal-only work with no distributable surface, omit release-impact analysis unless the operator asks for it.
+
+## Output package
+
+Produce this artifact when planning is complete. Do not create files unless the operator explicitly asks to save the plan.
+
+Use the format matching the planner mode:
+
+- `feature-planning` → [Feature planning output format](#feature-planning-output-format)
+- `audit-remediation-planning` → [Audit remediation output format](#audit-remediation-output-format)
+
+## Feature planning output format
+
+```markdown
+# Implementation Plan
+
+## Source
+
+- Issue / request:
+- Target repo:
+- Planner mode: feature-planning
+- Recommended slice count: one PR / multiple PRs
+
+## Context
+
+## Scope Boundaries
+
+### In scope
+
+### Out of scope
+
+## PR Slices
+
+### Slice 1: <title>
+
+- Goal:
+- Dependencies:
+- Acceptance criteria:
+- Expected files / areas:
+- Explicitly out of scope:
+- Validation expectations:
+- Implementation-agent handoff notes:
+
+## Risks / Open Questions
+
+## Release impact (include only when relevant)
+
+- Classification: no release impact / later release preparation required / human decision required
+- Affected artifacts:
+- Compatibility / migration notes:
+- Release validation expectations:
+- Explicitly not authorized: publish, tag, deploy, or create GitHub/npm releases
+
+## Overall Validation Plan
+
+## Rollback / Revert Considerations
+```
+
+For a single-PR plan, include one slice. For multi-PR work, include ordered slices with explicit dependencies.
+
+## Audit remediation output format
+
+```markdown
+# Audit Remediation Plan
+
+## Source Audit
+
+- Audit report:
+- Findings considered:
+- Findings excluded:
+- Planner mode: audit-remediation-planning
+
+## Prioritization Summary
+
+| Finding IDs | Priority | Reason | Planned slice |
+|-------------|----------|--------|---------------|
+
+## PR Slices
+
+### Slice 1: <title>
+
+- Findings addressed:
+- Remediation goal:
+- Acceptance criteria:
+- Expected files / areas:
+- Explicitly out of scope:
+- Validation expectations:
+- Dependencies / ordering:
+- Implementation-agent handoff notes:
+
+## Deferred Findings
+
+| Finding ID | Severity | Reason deferred |
+|------------|----------|-----------------|
+
+## Risks / Open Questions
+```
+
+## Handoff to implementation
+
+The planner outputs one implementation-ready slice at a time or a multi-slice plan from which the operator/runner selects the next slice.
+
+For each slice, include:
+
+- Slice title suitable for a PR title
+- Source issue/audit links
+- Goal and acceptance criteria
+- Expected files or areas (advisory — not rigid code edits)
+- Explicit out-of-scope paths or behaviors
+- Validation commands/checks
+- Known risks and open questions
+
+The planner does **not** create implementation branches or PRs. The implemented [`.agents/skills/implementation/SKILL.md`](../implementation/SKILL.md) should consume one selected slice and perform code changes.
+
+## Planning process
+
+1. Confirm source artifact and infer planner mode if not specified
+2. Read repo instructions and relevant durable artifacts (`AGENTS.md`, issue body, audit report, prior plans)
+3. Assess whether the work fits one PR or needs PR slicing
+4. Produce scope boundaries, acceptance criteria, and validation per slice
+5. For audit remediation, prioritize findings and defer Low/Info unless requested
+6. Output the plan package and confirm no files were changed
+
+## Relationship to runner prompts
+
+[`src/prompts/planning.md`](../../../src/prompts/planning.md) is the SDK runner implementation detail for cloud planning phases today. It is **not** the canonical harness skill. This skill defines the durable planner workflow contract; runner prompt migration is future work.
+
+## References
+
+- Skill architecture: [`docs/skills/skill-architecture.md`](../../../docs/skills/skill-architecture.md)
+- Implementation plan template: [`templates/implementation-plan.md`](../../../templates/implementation-plan.md)
+- Code health audit skill: [`.agents/skills/code-health-audit/SKILL.md`](../code-health-audit/SKILL.md)
+- Architecture evolution audit skill: [`.agents/skills/architecture-evolution-audit/SKILL.md`](../architecture-evolution-audit/SKILL.md)
+- Security audit skill: [`.agents/skills/security-audit/SKILL.md`](../security-audit/SKILL.md)
+- Linear automation state machine: [`docs/architecture/linear-automation-state-machine.md`](../../../docs/architecture/linear-automation-state-machine.md)
+- Agent guide: [`AGENTS.md`](../../../AGENTS.md)

package/workspace-snapshot/files/.agents/skills/security-audit/SKILL.md

@@ -0,0 +1,270 @@
+---
+name: security-audit
+description: >-
+  Conduct a report-only security audit focused on avoidable security risk from
+  secrets handling, trust boundaries, input validation, integration surfaces,
+  CI/CD permissions, data exposure, and deployment/configuration assumptions.
+  Use when an operator wants planner-consumable security findings before
+  planning remediation work.
+---
+
+# Security audit
+
+Conduct a practical, evidence-backed review of whether a repository exposes avoidable security risk through secrets handling, authentication/authorization boundaries, input validation, dependency posture, data exposure, workflow permissions, deployment/configuration assumptions, or unsafe integration surfaces. This skill is **report-only** — it inspects and produces findings; it does not modify code, create remediation plans, or open PRs.
+
+This skill focuses on **security risk**, not local code cleanliness, architecture evolution direction, performance/cost, or product quality.
+
+## When to use
+
+- Before planning remediation work on security hardening or trust-boundary gaps
+- After significant integration, setup, or automation work when the operator wants a structured security review
+- When onboarding to a repo and assessing security posture against documented baselines
+- When the operator wants planner-consumable security findings without implementation changes
+
+## Skill boundaries
+
+### Must do
+
+- Inspect security-relevant docs, workflows, configuration contracts, and source seams in the requested scope
+- Identify concrete, evidence-backed security findings with plausible risk scenarios
+- Distinguish real security risk from speculative hardening
+- Write findings so a planner can later turn them into remediation plans and reviewable PR slices
+- Clearly state what was inspected, what was not inspected, and what validation was or was not run
+- Redact secret-like values and report only safe path/context evidence
+- Confirm report-only and secret-safety boundaries in the output
+
+### Must not do
+
+- Modify files, create branches, commit, open PRs, or create remediation plans
+- Perform implementation fixes
+- Convert findings into sprint sequencing beyond planner-consumable grouping
+- Audit local maintainability, architecture evolution, performance/cost, or product/design quality except to mark them out of scope and route to the appropriate audit skill
+- Access, print, validate, rotate, or mutate real secrets
+- Attempt live attack testing, bypass authentication, or test against production systems unless explicitly authorized by the operator
+- Provide exploit steps that meaningfully enable abuse
+- Change permissions, disable workflows, or mutate remote systems
+
+## Relationship to other roles
+
+| Role | Responsibility |
+|------|----------------|
+| **This skill (security-audit)** | Inspect and report security findings |
+| **Planner** | Convert findings into remediation plans and reviewable PR slices |
+| **Implementation agent** | Make scoped code changes |
+
+Do not duplicate planner or implementation responsibilities.
+
+## Difference from other audit skills
+
+| Skill | Focus |
+|-------|-------|
+| **code-health-audit** | Local maintainability: naming, duplication, oversized files/functions, local modularity, and test confidence |
+| **architecture-evolution-audit** | Change amplification and ownership boundaries: whether likely future changes would require scattered edits or unclear coordination |
+| **security-audit** | Avoidable security risk: secrets, trust boundaries, validation, permissions, data exposure, and unsafe integration/configuration assumptions |
+| **performance-cost-audit** (planned) | Latency, polling, cloud/runtime cost, token usage, bundle size, and operational efficiency |
+
+Route out-of-scope observations to the appropriate skill rather than mixing them into security findings.
+
+## Inputs
+
+Ask for or infer:
+
+1. **Target repo path** and branch/ref
+2. **Audit objective** — what security surfaces or trust boundaries the operator wants reviewed
+3. **Audit scope** — whole repo, docs-only, integration seam, workflow surface, setup path, or recent diff
+4. **Include / exclude paths** — areas the operator wants emphasized or skipped
+5. **Operator authorization** — especially whether live systems, remote APIs, or production environments may be inspected
+6. **Validation commands** — only if the operator explicitly wants read-only or non-mutating checks run
+7. **Repo context** — `AGENTS.md`, `README.md`, `ARCHITECTURE.md`, security docs, setup docs, workflow files, config schema, package scripts, and relevant source files
+
+**Sensible default:** audit the current workspace and current branch using lightweight read-only inspection only. Do not access real secrets, mutate remote systems, or run live attack testing.
+
+## What to inspect
+
+Look for concrete security issues in these areas:
+
+- Secrets handling and accidental secret exposure in code, docs, examples, tests, fixtures, logs, artifacts, comments, or setup flows
+- Environment variable documentation and runtime assumptions for local, Vercel, GitHub Actions, and target-repo setup
+- Webhook verification, signature validation, timestamp tolerance, and dispatch trust boundaries
+- GitHub Actions permissions, pinned actions, repository dispatch behavior, workflow inputs, artifact retention, and token mapping
+- Linear, GitHub, Vercel, Cursor, and target-repo integration boundaries
+- Authentication and authorization boundaries across setup GUI, remote apply paths, and automation entry points
+- Input validation and untrusted payload handling in webhook handlers, dispatch payloads, CLI inputs, and setup forms
+- Data exposure in logs, artifacts, PR comments, Linear comments, setup previews, run manifests, and provider outputs
+- Dependency and package-script security posture at a high level
+- Configuration defaults that could fail open
+- Local setup instructions that could lead operators to leak credentials
+- Deployment or preview assumptions that expose sensitive data
+
+Suggested evidence sources for this harness repo:
+
+- Security baseline and token matrix: [`docs/security.md`](../../../docs/security.md)
+- Operator and setup docs: [`docs/operator-config.md`](../../../docs/operator-config.md), [`docs/gui-local.md`](../../../docs/gui-local.md), [`docs/gui-remote-setup.md`](../../../docs/gui-remote-setup.md)
+- Webhook bridge and watcher setup: [`api/linear-webhook.ts`](../../../api/linear-webhook.ts), `src/webhook/`, [`docs/linear-watcher-setup.md`](../../../docs/linear-watcher-setup.md)
+- GitHub Actions workflows: [`.github/workflows/harness-auto-runner.yml`](../../../.github/workflows/harness-auto-runner.yml), [`.github/workflows/ci.yml`](../../../.github/workflows/ci.yml), [`.github/workflows/codeql.yml`](../../../.github/workflows/codeql.yml)
+- Production sync and target-repo boundaries: [`docs/target-repo-branch-setup.md`](../../../docs/target-repo-branch-setup.md), [`docs/production-sync-automation.md`](../../../docs/production-sync-automation.md), workflow fixtures under `tests/fixtures/workflows/`
+- Redaction and artifact handling: `src/artifacts/redact.ts`, `src/webhook/redact-log.ts`, `src/setup/redact-secrets.ts`, workflow artifact upload paths
+- Setup and remote-write boundaries: `src/setup/`, especially local/remote apply actions, permission model, and preview fingerprinting
+- Provider and platform posture: [`ARCHITECTURE.md`](../../../ARCHITECTURE.md), [`docs/provider-portability.md`](../../../docs/provider-portability.md)
+- Dependency posture: `package.json`, lockfile, security docs on transitive vulnerabilities, package scripts that execute shell commands or touch remotes
+
+## Explicitly out of scope
+
+Do not audit for these categories. Note them in **Out Of Scope Observations** and route when relevant:
+
+| Category | Action |
+|----------|--------|
+| Local maintainability, duplication, naming, oversized files/functions, isolated test gaps | Out of scope — escalate to `code-health-audit` |
+| Architecture evolution, provider seam design, subsystem redesign, change amplification | Out of scope — escalate to `architecture-evolution-audit` |
+| Latency, token usage, cloud/runtime cost, polling waste, bundle size | Out of scope — escalate to `performance-cost-audit` |
+| Product/design quality, UI standards, copy quality | Out of scope |
+| Implementation fixes, remediation planning, or PR slicing decisions | Out of scope — planner responsibility |
+| Penetration testing, exploit development, bypass attempts, or unauthorized production testing | Out of scope |
+| Accessing, printing, validating, rotating, or mutating real secrets | Out of scope |
+
+## Severity model
+
+Use a security severity model, not code-health or architecture-evolution severity:
+
+| Severity | Meaning |
+|----------|---------|
+| **Critical** | Likely credential exposure, auth bypass, unauthorized write path, or production-impacting security failure with plausible exploitability |
+| **High** | Serious security weakness that could expose sensitive data, weaken trust boundaries, or permit unauthorized actions under realistic conditions |
+| **Medium** | Meaningful hardening gap, validation weakness, overly broad permission, or unclear secret/data handling with plausible misuse but limited direct impact |
+| **Low** | Minor hardening opportunity, documentation gap, or defense-in-depth improvement |
+| **Info** | Contextual observation, non-finding, or out-of-scope note |
+
+Every finding must also include confidence: **High**, **Medium**, or **Low**.
+
+## Finding categories
+
+| Category | Meaning |
+|----------|---------|
+| **secret exposure risk** | Committed, logged, previewed, or documented secret material or unsafe secret-handling patterns |
+| **authentication / authorization boundary** | Weak or missing authz checks across setup, automation, or integration entry points |
+| **input validation / untrusted payload handling** | Insufficient validation of external payloads, CLI inputs, or operator-supplied data |
+| **webhook or integration trust boundary** | Signature, dispatch, provider-boundary, or cross-system trust issues |
+| **CI/CD or GitHub Actions permission risk** | Overly broad workflow permissions, unsafe dispatch paths, or risky token usage |
+| **data exposure / logging / artifact retention** | Sensitive data in logs, artifacts, comments, previews, or retained outputs |
+| **dependency or package-script risk** | High-level dependency or script posture issues with security impact |
+| **configuration / deployment hardening** | Defaults, env assumptions, or deployment paths that could fail open |
+| **documentation gap** | Missing or misleading security guidance that could cause operator mistakes |
+
+## Finding writing rules
+
+Write findings for a planner, not for immediate implementation:
+
+- Prefer **specific, evidence-backed observations** over generic security advice
+- Include a plausible **risk scenario** and **impact**, phrased safely
+- State **confidence** when assumptions depend on operator configuration or unavailable evidence
+- Treat accepted risks documented in security baselines as context unless implementation or docs contradict them
+- Speculative improvements without clear impact should be **Low** or **Info**, or moved to out-of-scope observations
+- Group related findings into planner handoff themes when useful
+- Phrase planner handoff as remediation **shape**, not step-by-step code edits or exploit instructions
+
+Every finding must include:
+
+- Stable ID (`SEC-001`, `SEC-002`, …)
+- Severity
+- Category
+- Area / subsystem
+- Location / evidence with safe redaction only
+- Security concern
+- Risk scenario
+- Impact
+- Confidence
+- Planner handoff shape
+
+Planner handoff examples:
+
+- `one focused PR`
+- `multiple PRs`
+- `needs planning`
+- `needs human/security decision`
+
+**Good planner handoff:** "Candidate remediation slice: tighten webhook timestamp validation and document accepted replay window; one focused PR."
+
+**Bad planner handoff:** "Run this curl command with a forged signature to prove the bypass works."
+
+## Report safety rules
+
+- Never print real secrets, tokens, credentials, private keys, webhook secrets, API keys, or sensitive values
+- If a secret-like value is observed, redact it and report only file/path/context
+- Do not provide exploit steps that meaningfully enable abuse
+- Do not attempt live attack testing or bypass authentication
+- Do not change permissions, rotate secrets, disable workflows, alter settings, or mutate remote systems
+- Phrase findings as risk and remediation shape, not exploitation instructions
+
+## Output package
+
+Produce this artifact when the audit is complete. Do not create files unless the operator explicitly asks to save the report.
+
+```markdown
+# Security Audit Report
+
+## Scope
+
+- Repo:
+- Branch / ref:
+- Audit objective:
+- Paths / docs inspected:
+- Paths / docs intentionally skipped:
+- Constraints:
+- Report-only confirmation: no files changed
+- Secret safety confirmation: no secret values printed
+
+## Executive Summary
+
+- Overall security risk: Healthy / Mixed / Needs attention
+- Highest-risk theme:
+- Planner handoff summary:
+
+## Findings
+
+| ID | Severity | Category | Area | Location / evidence | Security concern | Risk scenario | Impact | Confidence | Planner handoff |
+|----|----------|----------|------|---------------------|------------------|---------------|--------|------------|-----------------|
+| SEC-001 | High | Webhook or integration trust boundary | ... | ... | ... | ... | ... | High / Medium / Low | ... |
+
+## Planner Handoff Themes
+
+- Theme:
+  - Related findings: SEC-001, SEC-003
+  - Suggested remediation shape: one focused PR / multiple PRs / needs planning
+  - Notes for planner:
+
+## Out Of Scope Observations
+
+- Code health:
+- Architecture evolution:
+- Performance/cost:
+- Product/design:
+- Implementation planning:
+
+## Coverage / Limits
+
+- Checked:
+- Skipped:
+- Evidence unavailable:
+- Residual risks:
+- Live systems not tested unless explicitly authorized:
+```
+
+## Audit process
+
+1. Confirm scope, authorization level, and constraints with the operator if not already clear
+2. Read repo security instructions (`AGENTS.md`, `docs/security.md`, architecture/setup docs) for documented baselines and accepted risks
+3. Inspect the scoped docs, workflows, configuration contracts, and source seams using lightweight read-only methods
+4. Record findings with safe evidence as you go — do not batch vague impressions at the end
+5. Sort findings by severity (Critical → High → Medium → Low → Info)
+6. Group related findings into planner handoff themes
+7. Note out-of-scope observations separately — do not mix them into security findings
+8. Produce the output package and confirm no files were changed and no secret values were printed
+
+## References
+
+- Skill architecture: [`docs/skills/skill-architecture.md`](../../../docs/skills/skill-architecture.md)
+- Security baseline: [`docs/security.md`](../../../docs/security.md)
+- Code health audit skill: [`.agents/skills/code-health-audit/SKILL.md`](../code-health-audit/SKILL.md)
+- Architecture evolution audit skill: [`.agents/skills/architecture-evolution-audit/SKILL.md`](../architecture-evolution-audit/SKILL.md)
+- Planner skill: [`.agents/skills/planner/SKILL.md`](../planner/SKILL.md)
+- Agent reporting contract: [`AGENTS.md`](../../../AGENTS.md)

package/workspace-snapshot/files/.env.example

@@ -0,0 +1,37 @@
+# Operator local setup — copy to .env.local via: npm run harness:operator:init
+# Do not commit .env.local (gitignored).
+
+# --- Local private harness config (local only) ---
+# Points at your structured target-repo config file.
+# Edit .harness/config.local.json after init; keep this path unchanged.
+HARNESS_CONFIG_PATH=.harness/config.local.json
+
+# --- GitHub Actions only (cloud runs) — do NOT put in .env.local ---
+# HARNESS_CONFIG_JSON_B64 replaces the whole harness config for that run.
+# It is NOT an overlay with committed harness.config.json.
+# Base64-encode your full .harness/config.local.json and set it as a
+# GitHub Actions secret on the harness repo. Include every repo you want
+# the harness to manage in repos[] and allowedTargetRepos[].
+
+# --- Live automation API keys (local CLI) ---
+# Fill these in .env.local for local doctor and harness runs.
+LINEAR_API_KEY=
+CURSOR_API_KEY=
+
+# Local CLI name for GitHub API access (doctor merge profile, handoff, merge).
+# In GitHub Actions the secret is named HARNESS_GITHUB_TOKEN (workflow maps it
+# to runtime GITHUB_TOKEN). Do not use HARNESS_GITHUB_TOKEN in .env.local.
+GITHUB_TOKEN=
+
+# --- GitHub Actions only — configure in repo Settings → Secrets, not .env.local ---
+# HARNESS_GITHUB_TOKEN=           # PAT with access to harness target repos
+# HARNESS_CONFIG_JSON_B64=        # base64 of full private harness config JSON
+
+# --- Vercel webhook bridge only (Milestone 8) — not used by local harness CLI ---
+# See docs/security.md for token scope and rotation policy
+# LINEAR_WEBHOOK_SECRET=
+# GITHUB_DISPATCH_TOKEN=          # Fine-grained: Contents: write on harness repo only
+# GITHUB_DISPATCH_REPOSITORY=     # optional; default owner/agentic-product-development-harness
+# GITHUB_DISPATCH_EVENT_TYPE=     # optional; default linear_issue_status_changed
+# LINEAR_WEBHOOK_TIMESTAMP_TOLERANCE_MS=  # optional; default 60000
+# HARNESS_TEAM_KEY=WES              # required in production Vercel

package/workspace-snapshot/files/.github/CODEOWNERS

@@ -0,0 +1,4 @@
+# Security-sensitive workflow and policy changes require owner review
+.github/workflows/ @weston-uribe
+.github/dependabot.yml @weston-uribe
+docs/security.md @weston-uribe

package/workspace-snapshot/files/.github/dependabot.yml

@@ -0,0 +1,12 @@
+version: 2
+updates:
+  - package-ecosystem: npm
+    directory: "/"
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5
+  - package-ecosystem: github-actions
+    directory: "/"
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5

package/workspace-snapshot/files/.github/workflows/ci.yml

@@ -0,0 +1,32 @@
+name: CI
+
+on:
+  pull_request:
+    branches: [main]
+  push:
+    branches: [main]
+
+permissions:
+  contents: read
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5
+
+      - name: Setup Node.js
+        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020
+        with:
+          node-version: "22"
+          cache: npm
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Build
+        run: npm run build
+
+      - name: Test
+        run: npm test

package/workspace-snapshot/files/.github/workflows/codeql.yml

@@ -0,0 +1,35 @@
+name: CodeQL
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+  schedule:
+    - cron: "0 6 * * 1"
+
+permissions:
+  actions: read
+  contents: read
+  security-events: write
+
+jobs:
+  analyze:
+    name: Analyze (javascript-typescript)
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5
+
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@641a925cfafe92d0fdf8b239ba4053e3f8d99d6d
+        with:
+          languages: javascript-typescript
+
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@641a925cfafe92d0fdf8b239ba4053e3f8d99d6d
+
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@641a925cfafe92d0fdf8b239ba4053e3f8d99d6d
+        with:
+          category: /language:javascript-typescript