@harness-engineering/cli 2.0.0 → 2.1.1

package/dist/agents/skills/claude-code/harness-compound/SKILL.md

@@ -0,0 +1,153 @@
+# Harness Compound
+
+> 5-phase post-mortem capture. When a problem is solved, distill it into a structured doc at `docs/solutions/<track>/<category>/<slug>.md` so the next person (or agent) finds the playbook before re-deriving it.
+
+## When to Use
+
+- Manually, after solving a non-trivial problem (a bug fix that took >1 commit, a debugging session, an architectural decision worth preserving)
+- When the orchestrator's step 6b mechanical triggers fire (deferred until Phase 7 wires it)
+- When the weekly `compound-candidates` scanner surfaces a candidate (deferred until Phase 5)
+- NOT for trivial fixes (typos, lint, one-line obvious)
+- NOT for facts that belong in `docs/knowledge/` (use `harness-knowledge-pipeline`; the boundary is: knowledge-pipeline extracts structural facts FROM CODE; compound captures post-mortem playbooks WRITTEN AFTER A FIX)
+- NOT for ephemeral session notes (`.harness/learnings.md` still exists for that)
+
+## Process
+
+### Iron Law
+
+**One problem, one canonical doc.** Phase 3 (overlap-check) is mandatory. If overlap is high, UPDATE the existing doc (bump `last_updated`, append to relevant section). Do not create a duplicate.
+
+---
+
+### Phase 1: IDENTIFY
+
+Extract the problem and the solution from available context:
+
+1. Read recent conversation, the active debug session at `.harness/debug/active/*.md` if present, and recent `git log --oneline -20`.
+2. Distill into a 1-2 sentence problem statement and 1-2 sentence solution statement.
+3. Note the affected `module` (package name or area, e.g. `orchestrator`, `cli/validate`).
+
+**Output:** `{ problem, solution, module, candidateTags }`.
+
+---
+
+### Phase 2: CLASSIFY
+
+Read `docs/solutions/references/schema.yaml` for the authoritative track/category enum and `docs/solutions/references/category-mapping.md` for examples of which problems land in which category.
+
+1. Choose `track`:
+   - `bug-track` — a thing was broken; you fixed it. Concrete failure, concrete cause.
+   - `knowledge-track` — a pattern, convention, or decision worth preserving as guidance, not a fix.
+2. Choose `category` from the enum for that track. If nothing fits, **stop and escalate** — adding categories requires a PR (Decision 8).
+
+**Output:** `{ track, category }`.
+
+---
+
+### Phase 3: OVERLAP-CHECK
+
+1. List every existing `docs/solutions/<track>/<category>/*.md`.
+2. For each, read the `# <Title>` heading and the first 200 chars of the `## Problem` (bug-track) or `## Context` (knowledge-track) section.
+3. Compute overlap heuristically: shared `module`, shared `problem_type`, similar problem statement (Jaccard on bag-of-words >= 0.5 is a reasonable threshold; the agent uses judgment).
+4. If high overlap with one existing doc:
+   - Open the existing doc.
+   - Update relevant sections (append a new bullet under `## Solution` or `## Guidance` describing the new instance, bump `last_updated`).
+   - Skip Phase 4 and most of Phase 5 (only the write-with-lock step runs).
+5. If no overlap, proceed to Phase 4.
+
+---
+
+### Phase 4: ASSEMBLE
+
+1. Copy `docs/solutions/assets/resolution-template.md` to a working buffer.
+2. Fill the frontmatter:
+
+   ```yaml
+   ---
+   module: <from Phase 1>
+   tags: [<from Phase 1 candidateTags, lowercase, hyphenated>]
+   problem_type: <short noun phrase, e.g. 'race-condition'>
+   last_updated: '<YYYY-MM-DD, today>'
+   track: <bug-track | knowledge-track>
+   category: <from Phase 2>
+   ---
+   ```
+
+3. Replace the `# <Title>` placeholder with a concise problem statement.
+4. For `bug-track`: fill `## Problem`, `## Root cause`, `## Solution`, `## Prevention`. Delete the knowledge-track sections (`## Context`, `## Guidance`, `## Applicability`).
+5. For `knowledge-track`: fill `## Context`, `## Guidance`, `## Applicability`. Delete the bug-track sections.
+6. Cite commit SHAs and `file:line` where helpful.
+
+---
+
+### Phase 5: WRITE (lock-protected)
+
+1. Compute slug: kebab-case from the title; if a file with that slug already exists in the target directory, append `-2`, `-3`, etc.
+2. **Acquire the per-category lock by shelling out.** Run a Node one-liner that imports `acquireCompoundLock` from `@harness-engineering/core`, holds the handle while you write the doc, then releases it. Example: `node -e "import('@harness-engineering/core').then(({ acquireCompoundLock }) => { const h = acquireCompoundLock('<category>'); /* write the doc here */ h.release(); }).catch(err => { console.error(err.message); process.exit(1); })"`. Lock path: `.harness/locks/compound-<category>.lock`. The MCP tool `acquire_compound_lock` is planned for a later phase — **do not attempt to call it yet**; the shell-out is the only supported path right now.
+   - On `CompoundLockHeldError`: report "compound lock for category `<category>` is held by pid `<N>` — wait for it to release or run `/harness:compound` for a different category" and stop. **Do not retry automatically.** A second invocation on the same problem after release will go through Phase 3 and find the doc the first invocation produced.
+3. Re-run a quick Phase 3 overlap-check inside the lock (defends against TOCTOU when the first overlap-check returned "no overlap" but another invocation completed in the meantime; the re-check is cheap).
+4. Write the file at `docs/solutions/<track>/<category>/<slug>.md`.
+5. Validate frontmatter against `SolutionDocFrontmatterSchema` by running `harness validate` (which runs `validateSolutionsDir`).
+6. Release the lock.
+7. Surface to chat: file path created (or updated), category, and a one-sentence summary.
+
+## Harness Integration
+
+- **`harness validate`** — Run after writing the doc; the solutions validator catches frontmatter errors before commit.
+- **`harness check-deps`** — Not required (no new module imports introduced by writing a doc).
+- **`@harness-engineering/core` lock primitive** — `acquireCompoundLock(category, { cwd })` returns a release handle; throws `CompoundLockHeldError` on contention. See `packages/core/src/locks/compound-lock.ts`.
+- **Schema authority** — `packages/core/src/solutions/schema.ts` is the single source of truth for tracks and categories. `docs/solutions/references/schema.yaml` mirrors it for human reading.
+- **Boundary with `harness-knowledge-pipeline`** — Knowledge-pipeline extracts structural facts FROM CODE. Compound captures post-mortem playbooks WRITTEN AFTER A FIX. Compound's knowledge-track output is a _candidate input_ to the pipeline (Phase 7 of the spec wires this).
+- **Boundary with `.harness/learnings.md`** — The file remains for ephemeral session notes. It is no longer the canonical sink for compounding knowledge — that's `docs/solutions/`.
+
+## Success Criteria
+
+- A new solution doc is written to `docs/solutions/<track>/<category>/<slug>.md` with valid frontmatter (passes `validateSolutionsDir`).
+- Two concurrent invocations on the same category cannot both succeed: one writes, the other returns `CompoundLockHeldError`.
+- A second invocation on the same problem updates the existing doc instead of creating a duplicate.
+- The skill never invents a new category — unknown categories are escalated.
+- PII is not written into the doc (the agent reads from local conversation/commits; no remote queries).
+
+## Examples
+
+### Example: bug-track
+
+Input: "Stalled lease cleanup in orchestrator caused stuck issues. Fix was to add a 5-minute lease TTL with a sweep at startup. Took 4 commits, debugged via `harness-debugging`."
+
+- Phase 1: `module=orchestrator`, problem="stuck issues from stalled leases", solution="lease TTL + startup sweep".
+- Phase 2: `track=bug-track`, `category=integration-issues` (lease coordination is integration-shaped).
+- Phase 3: no overlap.
+- Phase 4: fill Problem / Root cause / Solution / Prevention.
+- Phase 5: write `docs/solutions/bug-track/integration-issues/stalled-lease-cleanup.md` under lock.
+
+### Example: knowledge-track
+
+Input: "We standardized on `Result<T, E>` returns for all I/O paths in `packages/core`. Document the convention and when not to use it."
+
+- Phase 1: `module=core`, problem="when to use Result vs throwing", solution="convention doc".
+- Phase 2: `track=knowledge-track`, `category=conventions`.
+- Phase 3: no overlap.
+- Phase 4: fill Context / Guidance / Applicability.
+- Phase 5: write `docs/solutions/knowledge-track/conventions/result-type-for-io.md` under lock.
+
+### Example: overlap-check updates existing doc
+
+Input: "Hit the same stalled-lease bug today on a different code path."
+
+- Phase 1, 2 produce the same `bug-track/integration-issues` target.
+- Phase 3 finds `stalled-lease-cleanup.md` with high overlap.
+- Append a bullet to `## Solution` describing the new instance, bump `last_updated`, do not create a new file.
+
+## Gates
+
+- **Phase 3 is mandatory.** No exceptions. Skipping overlap-check produces duplicate docs and erodes the value of the corpus.
+- **No invented categories.** Unknown categories require a PR to `packages/core/src/solutions/schema.ts`. Escalate.
+- **Lock must wrap Phase 5.** Without the lock, two concurrent invocations on the same category race on overlap-check and produce duplicates.
+- **`harness validate` must pass before exit.** Frontmatter errors silently break the corpus.
+
+## Escalation
+
+- **Cannot decide track/category:** Escalate to the user. Show the candidate (track, category) pairs and the rationale for each. Wait for selection.
+- **Lock held by another invocation:** Report and stop. Do not retry. The user re-runs after release.
+- **`validateSolutionsDir` rejects the doc:** Show the validator error, fix the frontmatter, re-validate. Do not commit a doc that fails validation.
+- **Problem does not fit any category:** Escalate. Adding a category requires a PR (Decision 8 of the feedback-loops spec).

package/dist/agents/skills/claude-code/harness-compound/skill.yaml

@@ -0,0 +1,60 @@
+name: harness-compound
+version: "1.0.0"
+description: 5-phase post-mortem capture. Writes a structured solution doc at docs/solutions/{track}/{category}/{slug}.md with frontmatter, overlap-detection, and per-category lock for concurrency safety.
+stability: static
+cognitive_mode: reflective-historian
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+cli:
+  command: harness skill run harness-compound
+  args:
+    - name: context
+      description: Free-text problem context (e.g. 'stalled lease cleanup in orchestrator')
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-compound
+    context: string
+type: rigid
+tier: 2
+phases:
+  - name: identify
+    description: Extract problem and solution from conversation, debug session, recent commits
+    required: true
+  - name: classify
+    description: Choose track and category from the v1 schema enums
+    required: true
+  - name: overlap-check
+    description: Scan existing docs/solutions/<track>/<category>/ for matching problems; update existing if high overlap
+    required: true
+  - name: assemble
+    description: Fill the resolution template with track-appropriate sections
+    required: true
+  - name: write
+    description: Write doc under per-category lock; validate frontmatter; release lock
+    required: true
+state:
+  persistent: false
+  files:
+    - .harness/locks/compound-<category>.lock
+depends_on: []
+keywords:
+  - post-mortem
+  - solutions
+  - compound-learning
+  - playbook
+  - bug-track
+  - knowledge-track

package/dist/agents/skills/claude-code/harness-knowledge-pipeline/SKILL.md

@@ -68,7 +68,18 @@ Extract business knowledge from all available sources into a fresh snapshot.
    - Only runs if connectors are configured in `harness.config.json`
    - Skip silently if no connectors
 
-4. **Build Fresh Snapshot:** Collect all extraction results into a `KnowledgeSnapshot`.
+4. **Solutions Candidates** (if `docs/solutions/` exists): Run
+   `BusinessKnowledgeIngestor.ingestSolutions("docs/solutions")` to consume
+   knowledge-track post-mortems written by `harness-compound`.
+   - Only `docs/solutions/knowledge-track/<category>/*.md` files are candidates;
+     bug-track docs are skipped (they are fix playbooks, not structural facts).
+   - Each candidate must validate against `SolutionDocFrontmatterSchema` from
+     `@harness-engineering/core`. Invalid frontmatter is logged and skipped.
+   - Stable `last_updated` (older than configurable threshold; default: not gated
+     in Phase 7) is the promotion criterion for `business_concept` graph nodes.
+   - Candidates that pass become `business_concept` nodes in the snapshot.
+
+5. **Build Fresh Snapshot:** Collect all extraction results into a `KnowledgeSnapshot`.
    - Each entry has: `id`, `type`, `contentHash`, `source`, `name`
    - Each entry's `domain` is resolved via path-based inference (`packages/<dir>`, `apps/<dir>`, etc.) unless an explicit `metadata.domain` is set; projects can extend or override via `knowledge.domainPatterns` and `knowledge.domainBlocklist` in `harness.config.json` — see [`docs/knowledge/graph/node-edge-taxonomy.md`](../../../../docs/knowledge/graph/node-edge-taxonomy.md#domain-inference) for full precedence.
 

package/dist/agents/skills/claude-code/harness-observability/SKILL.md

@@ -11,6 +11,8 @@
 - NOT for security-focused log analysis (use harness-security-review)
 - NOT for incident response procedures (use harness-incident-response)
 
+> See also: `harness-pulse` is the read-side companion to this skill. Pulse READS observability data (and external analytics/error signals) to produce daily product-pulse reports; this skill DESIGNS the instrumentation that produces those signals in the first place.
+
 ## Process
 
 ### Phase 1: DETECT -- Identify Existing Instrumentation

package/dist/agents/skills/claude-code/harness-pulse/SKILL.md

@@ -0,0 +1,138 @@
+# Harness Pulse
+
+> Single-page time-windowed product pulse. **Phase 3 ships the first-run interview only**: it converts vague intent into a concrete `pulse:` block in `harness.config.json`, refuses read-write DB credentials, and seeds from `STRATEGY.md` when present. The actual `harness pulse run` (Phases 2-4 of the runtime) is deferred to spec Phase 4.
+
+## When to Use
+
+- Manually, when a project wants to start receiving daily pulse reports
+- When `harness.config.json` has no `pulse:` block and the user invokes `/harness:pulse`
+- NOT for ad-hoc one-off metric queries (that's the analytics tool's job)
+- NOT for replacing dashboards (pulse is a single-page summary, not a metrics platform)
+- NOT for projects that have not yet decided what their key metrics are (run `harness-strategy` first to write `STRATEGY.md`; pulse seeds from it)
+
+## Process
+
+### Iron Law
+
+**No PII reaches `harness.config.json` and no read-write DB credential is accepted.** Both are interview-time gates; both are hard refusals (no warnings, no overrides without an explicit user-typed escape).
+
+---
+
+### Phase 0: ROUTE BY CONFIG STATE
+
+1. Read `harness.config.json`.
+2. If `pulse.enabled` is set (true OR false), skip directly to "Phase 2: RUN" — **deferred to spec Phase 4**. For now, surface "pulse already configured; the run path ships in Phase 4" and stop.
+3. Otherwise enter Phase 1.
+
+---
+
+### Phase 1: FIRST-RUN INTERVIEW
+
+Read `references/interview.md` for the SMART pushback rules and the READ-WRITE-DB rejection rule. Both are mandatory.
+
+1. **Seed from STRATEGY.md.** Shell out to a Node one-liner that imports `seedFromStrategy` from `@harness-engineering/core`. Capture `{ name, keyMetrics, warnings }`.
+   - Surface `warnings` to the user verbatim.
+   - If `name` is non-null, confirm it as the product name; otherwise prompt.
+   - For each `keyMetric`, walk it through the SMART bar in step 4.
+
+2. **Pick the lookback default.** Use `emit_interaction` (type: `question`) when in MCP mode; otherwise present numbered options in chat: `["24h", "7d", "30d", "custom"]`. Default `24h` per spec.
+
+3. **Identify the primary engagement event** (e.g. `session_started`). Apply the SMART bar. If the user can't name one, set `null` and add a pending entry. Record the event name in `primaryEvent`.
+
+4. **Identify the value-realization event** (e.g. `plan_completed`). SMART bar applies. Record in `valueEvent`.
+
+5. **Identify completion events** (zero or more). SMART bar per item. Record in `completionEvents`.
+
+6. **Quality scoring (optional).** Ask whether the user wants quality sampling on a single dimension (e.g. "did the plan deliver value"). Default off. If enabled, set `qualityScoring: true` and record `qualityDimension`.
+
+7. **Wire data sources.** Ask which providers are available:
+   - `analytics`: posthog, amplitude, mixpanel, custom — or null
+   - `tracing`: sentry, datadog, custom — or null
+   - `payments`: stripe, custom — or null
+   - `db`: opt-in only, with the **READ-WRITE-DB rejection rule** active
+     For each non-null choice, check `getPulseAdapter(name)`. If absent, surface the "Phase 4 will ship the adapter" warning from `references/interview.md`.
+
+8. **Walk every STRATEGY.md key metric** through SMART. Map to an event when wired; otherwise append to `pendingMetrics` (or `excludedMetrics` if explicitly skipped). Cite `STRATEGY.md` when seeding so the user understands provenance.
+
+9. **Confirm the assembled config.** Show the user the proposed `pulse:` block; ask for confirmation.
+
+10. **Write the config.** Shell out to a Node one-liner that imports `writePulseConfig` from `@harness-engineering/core`. Pipe the JSON through stdin so user-supplied event names, qualityDimension, and pendingMetrics never cross the shell tokenizer (quotes, backticks, `$()`, `$VAR` in user input would otherwise break the command or allow injection):
+
+    ```bash
+    echo '<json-blob>' | node -e "import('@harness-engineering/core').then(m => m.writePulseConfig(JSON.parse(require('fs').readFileSync(0, 'utf-8')), { configPath: 'harness.config.json' })).catch(err => { console.error(err.message); process.exit(1); })"
+    ```
+
+    The writer preserves all other config keys and writes a `.bak`.
+
+11. **Offer to register the `product-pulse` maintenance task.** Deferred: Phase 6 of the spec wires it. For now, surface "the daily 8am `product-pulse` task will be registered automatically once Phase 6 of the feedback-loops spec ships; you can also run pulse on demand with `/harness:pulse [window]` once Phase 4 ships."
+
+12. **Run `harness validate`** to confirm the new `pulse:` block parses.
+
+---
+
+### Phase 2: RUN — deferred to spec Phase 4
+
+Stub: when `pulse.enabled === true`, this phase will dispatch analytics/tracing/payments queries in parallel, run the SanitizeFn for each provider's response, and stash sanitized results for Phase 3. NOT YET IMPLEMENTED. The skill exits early with a "deferred to Phase 4" message if it reaches this phase.
+
+### Phase 3: ASSEMBLE — deferred
+
+### Phase 4: SAVE — deferred
+
+## Harness Integration
+
+- **`harness validate`** — Run after `writePulseConfig`; the existing pulse-schema validator catches malformed blocks.
+- **`@harness-engineering/core`** primitives consumed by this skill:
+  - `writePulseConfig(config, { configPath })` — atomic config update with .bak.
+  - `seedFromStrategy({ cwd })` — defensive STRATEGY.md reader.
+  - `getPulseAdapter(name)` / `listPulseAdapters()` — adapter discovery (Phase 4 populates).
+  - `PulseConfigSchema` / `PII_FIELD_DENYLIST` — schema and PII contracts (already shipped Phase 1).
+- **Boundary with `harness-strategy`** — Strategy writes `STRATEGY.md`; pulse reads it to seed. Pulse never writes to `STRATEGY.md`.
+- **Boundary with `harness-observability`** — Observability designs _what_ to instrument; pulse is the read-side companion that surfaces what was instrumented.
+- **Decision 6 (read-only)** — Pulse refuses read-write DB credentials. Documented in `references/interview.md`.
+- **Decision 7 (PII contract)** — Every provider source must have a registered `SanitizeFn` adapter. Phase 3 ships the registry; Phase 4 ships the adapters.
+
+## Success Criteria
+
+- On a project with no `pulse:` block, the interview produces a valid `pulse:` block in `harness.config.json` with all non-pulse keys preserved.
+- A `harness.config.json.bak` is written before mutation.
+- A read-write DB credential is refused; the interview either accepts a read-only credential or sets `sources.db.enabled: false`.
+- When `STRATEGY.md` exists, `name` and `Key metrics` seed the interview; missing/malformed STRATEGY.md soft-fails with warnings.
+- `harness validate` passes after the interview completes.
+
+## Examples
+
+### Example: greenfield (no STRATEGY.md, no existing pulse block)
+
+- Phase 0: route to Phase 1.
+- Phase 1.1: `seedFromStrategy` returns `{ name: null, keyMetrics: [], warnings: ['STRATEGY.md not found'] }`.
+- Phase 1.2-7: prompt user; collect `lookbackDefault: '24h'`, `primaryEvent: 'session_started'`, `valueEvent: 'plan_completed'`, `sources.analytics: 'posthog'` (with adapter-availability warning), `sources.db.enabled: false`.
+- Phase 1.10: `writePulseConfig` writes the block; `.bak` saved.
+- Phase 1.12: `harness validate` passes.
+
+### Example: STRATEGY.md present with 3 Key metrics
+
+- Phase 1.1: seed returns `{ name: 'Acme', keyMetrics: ['DAU', 'plans/week', 'p95 latency'] }`.
+- Phase 1.8: walk each metric through SMART.
+  - "DAU" → mapped to `session_started` count over 24h, accepted.
+  - "plans/week" → mapped to `plan_completed` count over 7d, accepted (recorded as a future custom window).
+  - "p95 latency" → no tracing source wired yet; lands in `pendingMetrics`.
+
+### Example: user offers an admin DB credential
+
+- Phase 1.7: user pastes `postgresql://admin:pwd@host/db`.
+- Skill matches `admin` username against the rejection list; refuses; cites Decision 6.
+- User declines to provide a read-only credential; skill writes `sources.db.enabled: false`.
+
+## Gates
+
+- **READ-WRITE-DB rejection is non-negotiable.** No flag, no override, no "I know what I'm doing" path. Refuse and document.
+- **SMART pushback is mandatory on every proposed metric/event.** Silently accepting a vague name pollutes the corpus.
+- **`writePulseConfig` is the only sanctioned write path.** Do not hand-edit `harness.config.json`. The writer is the layer that preserves non-pulse keys and writes the .bak.
+- **`harness validate` must pass before exit.** A malformed `pulse:` block silently breaks the daily task once Phase 4 ships.
+
+## Escalation
+
+- **User insists on read-write DB credentials:** Refuse. Set `sources.db.enabled: false`. Stop.
+- **Adapter not registered for a chosen provider:** Warn, record the choice, continue. The runtime gate (Phase 4) refuses to run until the adapter ships.
+- **STRATEGY.md frontmatter is malformed but H1 is present:** Use H1 as `name` and surface a warning. If neither is parseable, prompt the user.
+- **`writePulseConfig` throws:** Report the validator error verbatim. Do not retry without user fix.

package/dist/agents/skills/claude-code/harness-pulse/references/interview.md

@@ -0,0 +1,77 @@
+# Pulse First-Run Interview Reference
+
+The first-run interview converts vague intent ("I want to know how the product is doing") into a concrete `pulse:` block in `harness.config.json`. This document is the rule book the skill quotes when pushing back on input.
+
+## SMART Pushback Rules
+
+For every metric or event the user proposes, the skill MUST evaluate it against the SMART bar and push back when it fails. SMART = **S**pecific, **M**easurable, **A**chievable, **R**elevant, **T**ime-bound.
+
+| Test       | Question                                                             | Reject when                                         |
+| ---------- | -------------------------------------------------------------------- | --------------------------------------------------- |
+| Specific   | Does the name uniquely identify one event/metric?                    | "engagement", "activity", "usage" without qualifier |
+| Measurable | Is there a wired data source that emits this?                        | No analytics/tracing source covers it               |
+| Achievable | Can it be queried in <30s within the lookback window?                | Requires a full-table scan over years of data       |
+| Relevant   | Does it map to a `STRATEGY.md` Key metric or a documented user pain? | Vanity metric ("total signups ever")                |
+| Time-bound | Is the window declared (24h, 7d, 30d)?                               | Naked counter with no time scope                    |
+
+### Pushback script
+
+When a proposed metric fails, the skill MUST:
+
+1. Quote the failing test and the rule.
+2. Suggest a concrete repair (example: "engagement" → "session_started events per active user per day").
+3. Ask the user to either accept the repair, propose a new name, or skip this metric (it lands in `pendingMetrics` if no source covers it).
+
+The skill MUST NOT silently accept a metric that fails the bar. Pushback is mandatory.
+
+## READ-WRITE-DB Rejection Rule
+
+When the user offers a database connection string for the `db` source:
+
+1. The skill MUST inspect the connection string and reject any of the following without exception:
+   - User has `INSERT`, `UPDATE`, `DELETE`, `DROP`, `TRUNCATE`, `ALTER`, `CREATE`, or `GRANT` privileges
+   - Connection string includes `?role=admin`, `?role=write`, `?ssl=disable` (the last is a separate red flag worth surfacing)
+   - The connection user is named `root`, `admin`, `postgres`, `mysql`, or any name matching `*_admin`, `*_write`, `*_rw`
+2. The skill MUST NOT attempt to "downgrade" the credentials silently. It MUST ask the user to provide a read-only credential.
+3. If the user insists, the skill MUST refuse and write `sources.db.enabled: false`. Pulse is read-only by contract (Decision 6).
+4. The rejection message MUST cite "Decision 6 of the feedback-loops spec: pulse refuses read-write DB credentials".
+
+The skill cannot verify the privilege grant directly without connecting (and connecting is exactly what we're refusing for write creds). The signal-set above is heuristic; when in doubt, refuse and ask.
+
+## Adapter availability check
+
+Before accepting a `sources.analytics` or `sources.tracing` value, the skill MUST verify a `SanitizeFn` adapter is registered for that name:
+
+```ts
+import { getPulseAdapter } from '@harness-engineering/core';
+if (!getPulseAdapter(value)) {
+  // refuse — Decision 7: pulse refuses to enable for a provider whose
+  // adapter has no `sanitize` implementation.
+}
+```
+
+In Phase 3 NO adapters are registered yet — Phase 4 ships them. So during the interview the skill warns:
+
+> "No `SanitizeFn` adapters are currently registered. Recording your selection but pulse will refuse to run until Phase 4 ships adapters for posthog/sentry."
+
+The selection is still written to `harness.config.json` (so re-running pulse later finds it); the runtime refusal is the safety gate.
+
+## Strategy seeding
+
+If `STRATEGY.md` exists at repo root:
+
+- The product `name` is read from frontmatter (`name: '<X>'`); fallback to the first `# <Title>` H1.
+- The `## Key metrics` bullet list is treated as a list of REQUIRED metrics that the interview MUST walk through one-by-one.
+- Each Key metric goes through the SMART bar; the user may map it to an event/source, defer it to `pendingMetrics`, or explicitly exclude it (which lands it in `excludedMetrics`).
+
+If `STRATEGY.md` is absent, the skill proceeds with no seed and prompts the user from scratch.
+
+## Interview output
+
+After the interview, the skill calls `writePulseConfig(config, { configPath })` from `@harness-engineering/core`:
+
+- The full config matches `PulseConfigSchema`.
+- All non-pulse keys in `harness.config.json` are preserved.
+- A `harness.config.json.bak` is written before mutation.
+
+Then the skill offers to register the `product-pulse` maintenance task (deferred — that wiring is Phase 6 of the spec; for now the skill notes the offer and explains the user can register it manually later).

package/dist/agents/skills/claude-code/harness-pulse/skill.yaml

@@ -0,0 +1,61 @@
+name: harness-pulse
+version: "0.1.0"
+description: First-run pulse interview. Converts intent into a validated pulse config with SMART pushback, read-write-DB rejection, STRATEGY.md seeding. Phase 3 ships the interview; the run path is deferred to Phase 4.
+stability: static
+cognitive_mode: configuration-interviewer
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+cli:
+  command: harness skill run harness-pulse
+  args:
+    - name: window
+      description: Lookback window for run mode (deferred until Phase 4); ignored during the interview
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-pulse
+    window: string
+type: rigid
+tier: 2
+phases:
+  - name: route
+    description: Route by harness.config.json pulse state
+    required: true
+  - name: interview
+    description: SMART pushback + STRATEGY.md seeding + read-write-DB rejection; writes pulse block to harness.config.json
+    required: true
+  - name: run
+    description: Deferred to spec Phase 4
+    required: false
+  - name: assemble
+    description: Deferred to spec Phase 4
+    required: false
+  - name: save
+    description: Deferred to spec Phase 4
+    required: false
+state:
+  persistent: true
+  files:
+    - harness.config.json
+    - harness.config.json.bak
+depends_on: []
+keywords:
+  - pulse
+  - product-pulse
+  - feedback-loops
+  - read-side
+  - smart-metrics
+  - strategy-seeding

package/dist/agents/skills/claude-code/harness-roadmap-pilot/SKILL.md

@@ -54,6 +54,29 @@ Top candidates (scored by position 50%, dependents 30%, affinity 20%):
    - Read the spec's Success Criteria section
    - Assess effort and impact from the spec content
 
+1b. Read the most recent pulse report (if any):
+
+- List entries in `docs/pulse-reports/` and **filter to those matching the
+  regex `/^\d{4}-\d{2}-\d{2}_\d{2}-\d{2}\.md$/`** (the canonical
+  `YYYY-MM-DD_HH-MM.md` pulse-report filename shape). Filtering before
+  sorting prevents non-conforming files (e.g. `README.md`, `NOTES.md`,
+  partial-timestamp drafts) from corrupting the signal.
+- Lexical-sort the matched filenames (ISO timestamps sort
+  chronologically) and take the LAST entry as the most recent.
+- If zero entries match the regex (directory empty, absent, or only
+  contains non-conforming files), soft-fail: skip this step and proceed
+  without pulse signal. Do not block recommendation.
+- For each top-3 candidate, scan the most recent pulse report's Headlines and
+  Followups sections for keywords matching the candidate's name, milestone, or
+  spec keywords. Note any signal that elevates priority (top followup item
+  related to a candidate; an error spike in a candidate's area) or suppresses
+  it (recent stable signal in candidate's area).
+- When pulse signal is found, cite it verbatim in the recommendation rationale
+  (e.g., "Pulse 2026-05-05_08-00 headline: 'auth errors up 30%' — elevates
+  Auth Hardening").
+- Use ONLY the most recent file. If older reports conflict with the most
+  recent, ignore the older signal.
+
 2. Provide a recommendation with reasoning:
 
 ```
@@ -148,7 +171,8 @@ Proceed with Feature A? (y/n/pick another)
 5. Assignment updates feature field, appends history records, and syncs externally
 6. Reassignment produces two history records (unassigned + assigned)
 7. Transition routes to brainstorming (no spec) or autopilot (spec exists)
-8. `harness validate` passes after all changes
+8. When a pulse report exists, the recommendation rationale cites pulse signal for any top-3 candidate whose area is referenced in the pulse Headlines or Followups.
+9. `harness validate` passes after all changes
 
 ## Rationalizations to Reject