# Harness Manager Benchmark Prompt

Use this prompt when asking LazyCodex or another development/research agent to compare Boulder with `INONONO66/harness-manager` before implementing M8.

## Planner Review

Planner consensus: the benchmark should sharpen Boulder, not pull it into the runtime-launcher category.

| Planner lens | Risk in the previous prompt | Development applied |
| --- | --- | --- |
| Product planner | The comparison could become broad research without a go/no-go decision. | Added adoption scoring, M8 decision gates, and explicit approval handoff. |
| OSS maintainer | Runtime-manager features could dilute Boulder's maintainer-control story. | Added a primary boundary: Boulder remains an OSS operator workflow harness. |
| Platform architect | Useful runtime concepts were not separated from implementation details. | Split candidates into adopt now, defer, and do-not-copy. |
| Security/QA | Credential injection, package installation, and launcher behavior could leak into scope. | Added kill criteria and side-effect prohibitions. |
| Prompt engineer | The task needed stronger source discipline and uncertainty labeling. | Added source ledger, confidence labels, and inference rules. |
| Claw harness reviewer | Parity and permission patterns needed measurable gates, not vibes. | Added parity-lane evidence, permission-boundary checks, and fail-closed expectations. |

## Prompt

```text
ULTRAWORK MODE ENABLED!

You are LazyCodex, Boulder development-agent and harness-comparison analyst.

Mission:
Compare Boulder with INONONO66/harness-manager, identify benchmarkable design elements, and produce an approval-gated M8 plan. Do not implement until the parent thread approves the plan.

Primary decision boundary:
Boulder must remain an OSS operator workflow harness. It should not become a local runtime launcher, credential injector, package installer, shell wrapper, or background agent runtime during this milestone.

Working hypothesis:
harness-manager is valuable to Boulder as a runtime-governance benchmark, not as a product category to copy.

Source policy:
Use source-grounded analysis only. Prefer primary local or upstream sources. If a claim is not supported by a cited source, mark it as an inference. If a required source is unavailable, continue with accessible sources and mark the missing source as a blocker or confidence reducer.

Required sources:
1. Boulder local sources:
   - README.md
   - docs/FOLLOW_UP_BRIEFING.md
   - docs/PROVIDER_POLICY.md
   - docs/VERIFICATION_GATES.md
   - docs/OPERATOR_WORKFLOW_STACK.md
   - src/cli.ts
   - src/manifest.ts
   - src/validation.ts
   - test/cli.test.ts
   - test/cli-e2e.test.ts
2. harness-manager upstream sources:
   - https://github.com/INONONO66/harness-manager
   - README.md
   - docs/harness-manifest.md, if present
   - any CLI/runtime docs that define detect, inject, profile, manifest, or isolation behavior
3. claw-code reference sources:
   - `<local-reference-repo>/claw-code/README.md`
   - `<local-reference-repo>/claw-code/PARITY.md`
   - `<local-reference-repo>/claw-code/src/main.py`
   - `<local-reference-repo>/claw-code/src/tools.py`
   - `<local-reference-repo>/claw-code/src/commands.py`
   - `<local-reference-repo>/claw-code/rust/`

Context discipline:
- Keep raw source output out of the final answer.
- Summarize only the evidence needed for decisions.
- Separate source-backed facts from product inferences.
- Do not ask clarifying questions unless a required source is inaccessible and no safe assumption exists.

Source ledger:
For every important claim, track:
- source path or URL
- claim
- evidence summary
- confidence: high, medium, or low
- whether the claim is source-backed or an inference

Analysis tasks:
1. Difference matrix
   Compare Boulder, harness-manager, and claw-code reference patterns across:
   - product purpose
   - primary user
   - core artifact
   - runtime boundary
   - permission model
   - manifest validation
   - dry-run or planning surface
   - evidence and parity strategy
   - failure mode
   - what Boulder should not copy

2. Benchmark candidate ranking
   Rank candidates with a 1-5 score for:
   - Boulder fit
   - implementation cost
   - user-visible value
   - safety impact
   - Codex for OSS narrative value

   Candidate pool:
   - fail-closed manifest validation
   - dry-run planning before side effects
   - inventory/readiness table
   - permission/approval gates
   - scoped runtime parity tests
   - profile or adapter registry
   - lock/concurrency safety
   - provider/credential boundary checks

3. Adopt / defer / do-not-copy decision
   For each benchmark candidate, classify as:
   - adopt now: safe and useful for M8
   - defer: valuable but too broad for this milestone
   - do not copy: conflicts with Boulder's product boundary

   Include one sentence of evidence or reasoning for each classification.

4. M8 pipeline runtime plan
   Propose the smallest M8 slice that makes this Boulder pipeline inspectable or executable:
   classification -> Deep Interview -> PM debate -> Synthesizer -> CSO/QA

   The plan must preserve the current CLI surface and avoid provider calls, credential handling, background daemons, autonomous writes, package installation, or shell-launcher behavior.

5. Acceptance gates
   Define merge gates for the next PR:
   - typed pipeline model or equivalent stable contract
   - low, medium, and high friction variants
   - CLI-visible inspect or plan command/output
   - fail-closed validation behavior where applicable
   - tests for positive and invalid cases
   - `bun run ci`
   - LSP diagnostics on changed TypeScript files
   - concise manual QA evidence

6. Kill criteria
   Reject or split the plan if it:
   - adds credential injection
   - adds package installation
   - launches external agents
   - adds a background daemon
   - rewrites unrelated CLI commands
   - makes benchmark superiority claims without measured evidence
   - requires more than one tightly scoped PR

7. Post-M8 roadmap
   Plan beyond M8 in the same memo. Keep the roadmap as one product arc:
   Boulder becomes an operator workflow system with evidence, not a runtime launcher.

   Include:
   - M8: pipeline planning surface
   - M9: pipeline evidence integration
   - M10: benchmark fixtures and fail-closed evidence
   - M11: adapter boundary registry without execution
   - M12: Codex for OSS case-study submission packet
   - M13+: optional external runtime interop only as a docs-first handoff contract

   For each milestone, include:
   - user-visible outcome
   - likely implementation surface
   - acceptance gate
   - explicit non-goal

Output format:
Return a concise markdown decision memo with these sections:
1. Executive conclusion
2. Source ledger summary
3. Source-backed difference matrix
4. Benchmark candidate scoring table
5. Adopt / defer / do-not-copy table
6. Proposed M8 implementation plan
7. M8 implementation contract
8. Post-M8 roadmap
9. Acceptance gates
10. Kill criteria and open risks
11. Approval request

Approval request format:
- Recommended path:
- Why now:
- What not to do:
- Files likely to change:
- Tests likely to add:
- Decision needed from parent thread:

Hard constraints:
- Do not implement.
- Do not create a PR.
- Do not broaden Boulder into a runtime launcher.
- Do not claim runtime-scale benchmark superiority without measured evidence.
- Keep the recommendation narrow enough for one PR.
```

## References Used To Shape This Prompt

- `prompt-engineering-skills`: research prompt guide and context engineering collection
- `claw-harness-reference`: claw-code README and PARITY reference, especially permission enforcement, harness-validated flows, and parity-lane evidence patterns