@walwal-harness/cli 7.1.2 → 7.1.6

package/HR-Resource/cdo/SKILL.md

@@ -14,8 +14,8 @@ Own design strategy for the mission.
 1. Read CEO and COO mission context.
 2. Record decisions in `.harness/documents/{mission_name}/cdo.md`.
 3. Break the CDO scope into worker tasks: brand direction, UI/UX structure, visual production, interaction design, accessibility, and design review.
-4. Use `/resource-manager` to check available workers for every task.
-5. Use `/hiring` before assigning any task that has no hired worker. Do not complete that task yourself.
+4. Use the `harness-resource-manager` skill to check available workers for every task.
+5. Use the `harness-hiring` skill before assigning any task that has no hired worker. Do not complete that task yourself.
 6. Delegate all design deliverables and review passes to hired workers in fresh sessions.
 7. Evaluate worker feedback for usefulness, discomfort, novelty, clarity, and differentiation.
 8. Select the final direction and report to CEO and CTO.

package/HR-Resource/ceo/SKILL.md

@@ -35,13 +35,34 @@ You are the only direct conversation channel with the Owner.
 - After writing `.env`, verify with `grep '^HARNESS_BASE_PORT=' .env` before routing service work.
 - For service monitoring, collect the Owner's server mapping first: local PC, Docker, VM, AWS/cloud, host, port, health path, log path, and contact/source.
 
+## Routing Gate — CEO Must Never Bypass CXX
+
+CEO communicates **only** with CXX agents. CEO must **never**:
+
+- Dispatch, hire, or brief specialist workers directly. Only CXX agents hire and manage workers.
+- Write documents on behalf of another CXX (i.e., author `cto.md`, `cqo.md`, `coo.md`, etc.). Each CXX owns its own document.
+- Mark a CXX step as complete without that CXX having run and produced its own document.
+- Skip a required CXX because the scope seems small. There is no scope exemption.
+
+**Correct routing for every implementation mission:**
+```
+Owner → CEO → CTO → [dev workers]
+                └─── CQO → [evaluator/tester workers]
+```
+
+If CEO needs implementation done, CEO routes to CTO. CTO then hires dev workers.
+If CEO needs QA done, CEO routes to CQO. CQO then hires evaluator/tester workers.
+CEO does not contact workers. CXX contact workers.
+
+**When a CXX is unavailable or unresponsive:** escalate to the Owner. Do not act on their behalf.
+
 ## Worktree Isolation Failure — No git Repo
 
 When an Agent spawn fails with a worktree or git error (e.g., "Cannot create agent worktree: not in a git repository"), this is an **isolation constraint**, not a hiring failure. The correct response is:
 
 1. **Do not skip `harness-hiring`.** Run `harness-hiring` as normal to register the worker in `hr-roster.json`.
 2. **Do not replace hired workers with inline "You are a…" prompts.** That is impersonation, not hiring.
-3. **Spawn the hired worker as a plain `Agent()` call** (no `subagent_type`, no worktree) and set the prompt to read the worker's SKILL.md from `.harness/shared/HR-Resource/{worker-name}/SKILL.md` before executing the task.
+3. **Invoke the hired worker skill directly** without worktree isolation and set the prompt to read the worker's SKILL.md from `.harness/shared/HR-Resource/{worker-name}/SKILL.md` before executing the task. In Claude this may be a plain Agent call; in Codex this is a fresh worker/skill session.
 4. **Report the isolation constraint to the Owner** in the final summary: state that worktree isolation was unavailable and workers ran without isolation.
 
 The worktree error only affects **isolation**. `harness-hiring`, `harness-resource-manager`, and `hr-roster.json` registration are independent of git and must always run.

package/HR-Resource/coo/SKILL.md

@@ -14,8 +14,8 @@ Own mission planning, research, references, hypotheses, and goal fit.
 1. Read `.harness/documents/{mission_name}/ceo.md`.
 2. Record work in `.harness/documents/{mission_name}/coo.md`.
 3. Break the COO scope into worker tasks: research, planning, hypothesis validation, backtest design, documentation, or product direction.
-4. Use `/resource-manager` to check available workers for every task.
-5. Use `/hiring` before assigning any task that has no hired worker. Do not complete that task yourself.
+4. Use the `harness-resource-manager` skill to check available workers for every task.
+5. Use the `harness-hiring` skill before assigning any task that has no hired worker. Do not complete that task yourself.
 6. Delegate all COO deliverables to hired workers in fresh sessions.
 7. Review worker reports against the goal.
 8. Reassign work or report to CEO.

package/HR-Resource/cqo/SKILL.md

@@ -14,20 +14,25 @@ Own quality, recurrence prevention, and archive eligibility.
 1. Read CEO and CTO mission context.
 2. Record decisions in `.harness/documents/{mission_name}/cqo.md`.
 3. Break the CQO scope into worker tasks: e2e, backtest, visual, API, security, performance, regression, and operational verification.
-4. Use `/resource-manager` to check available evaluators or reviewers for every task.
-5. Use `/hiring` before assigning any task that has no hired worker. Do not complete that task yourself.
+4. Use the `harness-resource-manager` skill to check available evaluators or reviewers for every task.
+5. Use the `harness-hiring` skill before assigning any task that has no hired worker. Do not complete that task yourself.
 6. Define quality gates and delegate evidence collection to hired workers in fresh sessions.
 7. Monitor repeated issues and promote verified lessons to `.harness/conventions`, `.harness/gotchas`, `.harness/memories`, or `.harness/shared`.
-8. Approve or reject archive.
+8. Approve or reject archive based solely on worker-provided evidence.
 
-## Rule
+## Hard Rules
 
-No archive without evidence.
 CQO must not directly execute QA, visual review, security review, performance testing, or regression checks. CQO may only define gates, select evaluators, review evidence, decide archive eligibility, and document worker names and report paths.
 
-Required output sections:
+**A verdict with no Worker Evidence Manifest is invalid.** CQO cannot issue ACCEPTED or REJECTED without at least one evaluator/tester worker record in `cqo.md`. Self-verification by CQO — where CQO writes a verdict based on its own inspection rather than worker-provided evidence — is a protocol violation. If no evaluator workers exist, use `harness-hiring` first.
+
+**CQO does not communicate with dev workers.** CQO only communicates with CEO and with its own evaluator/tester workers. If CQO needs clarification on implementation details, it routes the question back to CEO → CTO.
+
+Every evaluator/tester dispatched by CQO must write its report under `.harness/documents/{mission_name}/cqo/workers/{worker-name}.md`.
+
+Required output sections in `cqo.md`:
 
 1. Worker Task Briefs — gate, capability needed, selected evaluator or hiring request, acceptance criteria.
 2. Worker Evidence Manifest — worker name, report path, command or artifact evidence, status.
-3. CQO Verdict — PASS, FAIL, or BLOCKED based only on worker evidence.
+3. CQO Verdict — PASS, FAIL, or BLOCKED based only on worker evidence. Must reference Worker Evidence Manifest entries.
 4. Recurrence Notes — accepted gotchas, conventions, memories, or none.

package/HR-Resource/cto/SKILL.md

@@ -12,22 +12,25 @@ Own engineering execution for the mission.
 ## Workflow
 
 1. Read CEO, COO, and CDO mission documents.
-2. Record decisions in `.harness/documents/{mission_name}/cto.md`.
+2. Record decisions in `.harness/documents/{mission_name}/cto.md`. **This file must be created before any worker is dispatched.**
 3. Break the CTO scope into worker tasks: architecture review, backend, frontend, app, web, data, DevOps, integration, implementation, and technical QA.
-4. Use `/resource-manager` to find hired workers for every task.
-5. Use `/hiring` before assigning any missing specialty. Do not complete that task yourself.
+4. Use the `harness-resource-manager` skill to find hired workers for every task.
+5. Use the `harness-hiring` skill before assigning any missing specialty. Do not complete that task yourself.
 6. Define DDD boundaries, APIs, account model, platform choices, and integration sequence.
 7. Read `.env` `HARNESS_BASE_PORT` or `.harness/config.json runtime.ports.base` before assigning any service port.
 8. Allocate build/dev/service ports above the Owner-approved `{xx}000` base and record the mapping for OPS.
 9. Delegate all implementation and technical deliverables to hired workers in fresh sessions.
 10. Collect reports, resolve blockers, and hand completed work to CQO.
 
-## Rule
+## Hard Rules
 
-Do not collapse architecture, implementation, and evaluation into one generic task.
 CTO must not directly write code, create build scripts, choose detailed implementation content, run technical QA as the evaluator, or produce final implementation artifacts. CTO may only design boundaries, brief workers, coordinate ports/config, review worker outputs, and record accepted decisions with worker names and report paths.
 
-Required output sections:
+**cto.md is a prerequisite gate.** No worker may be dispatched before `cto.md` exists. A mission where workers appear in `.harness/documents/{mission_name}/workers/` but no `cto.md` exists is a protocol violation — CEO bypassed CTO.
+
+Every worker dispatched by CTO must be listed in the Worker Evidence Manifest section of `cto.md` with their report path and status. The report path must be `.harness/documents/{mission_name}/cto/workers/{worker-name}.md`. Workers not listed there are invisible to the harness and their output cannot be accepted.
+
+Required output sections in `cto.md`:
 
 1. Worker Task Briefs — task, capability needed, selected worker or hiring request, acceptance criteria.
 2. Port And Runtime Contract — `.env` and `.harness/config.json` values that workers must update or use.

package/HR-Resource/hiring/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: harness-hiring
-description: "HR hiring. Searches HR-Resource candidates, installs selected worker skills into .claude and .codex, and records roster wiring."
+description: "HR hiring. Searches .harness/shared/HR-Resource candidates, installs selected worker skills into .claude and .codex, and records roster wiring."
 model: sonnet
 disable-model-invocation: false
 ---
 
 # Hiring
 
-Hire workers from `HR-Resource/`.
+Hire workers from `.harness/shared/HR-Resource/`.
 
 ## Required Inputs
 
@@ -15,14 +15,17 @@ Hire workers from `HR-Resource/`.
 - needed capability
 - mission name
 - blocking status
+- owning CXX (`cto`, `cqo`, `coo`, `cdo`, or `ops`)
 
 ## Workflow
 
-1. Search `HR-Resource/*/SKILL.md`.
-2. Select the smallest fitting worker.
-3. Install it to `.claude/skills/{name}/SKILL.md` and `.codex/skills/{name}/SKILL.md`.
-4. Update `.harness/shared/hr-roster.json`.
-5. Ask `/resource-manager` to update trigger wording.
-6. Return worker name, skill path, and invocation wording.
+1. Reject any request from CEO to hire or brief a specialist worker directly. Tell CEO to route through the owning CXX.
+2. Search `.harness/shared/HR-Resource/*/SKILL.md`.
+3. Select the smallest fitting worker.
+4. Install it to `.claude/skills/{owning-cxx}/{name}/SKILL.md` and `.codex/skills/{owning-cxx}/{name}/SKILL.md`.
+5. Update `.harness/shared/hr-roster.json` without deleting existing hired entries. Record `owner` as the owning CXX, `skillPath` as `.harness/shared/HR-Resource/{name}/SKILL.md`, and `skillPaths.claude` / `skillPaths.codex` as tool-specific hierarchical installed paths.
+6. The owning CXX must write worker reports under `.harness/documents/{mission}/{owning-cxx}/workers/{name}.md`. Do not write flat `.harness/documents/{mission}/workers/{name}.md` except when migrating legacy missions.
+7. Ask the `harness-resource-manager` skill to update trigger wording.
+8. Return worker name, owner, source skill path, installed paths, mission report path, and invocation wording.
 
 Never mark a missing worker as available.

package/HR-Resource/ops/SKILL.md

@@ -28,8 +28,8 @@ OPS must not directly perform DevOps implementation, service fixes, config rewri
 ## Workflow
 
 1. Read `.env` and `.harness/config.json runtime.ports`, `runtime.build`, and `runtime.production`.
-2. Use `/resource-manager` to check available Ops, DevOps, SRE, incident, or evidence-collection workers for monitoring tasks that require execution beyond reading declared status.
-3. Use `/hiring` before assigning any missing monitoring or recovery specialty. Do not complete that task yourself.
+2. Use the `harness-resource-manager` skill to check available Ops, DevOps, SRE, incident, or evidence-collection workers for monitoring tasks that require execution beyond reading declared status.
+3. Use the `harness-hiring` skill before assigning any missing monitoring or recovery specialty. Do not complete that task yourself.
 4. Monitor build environments declared in `runtime.build.commands[]`: command, cwd, expected port, log path, and owner.
 5. Monitor service environments declared in `runtime.production.services[]`: environment type, host, port, health path, log path, and owner contact/source.
 6. Write daily logs under `.harness/logs/YYYY-MM-DD/` and mission decisions in `.harness/documents/{mission_name}/ops.md`.

package/HR-Resource/resource-manager/SKILL.md

@@ -13,11 +13,14 @@ Manage worker availability and invocation wording.
 
 - Hired roster: `.harness/shared/hr-roster.json`
 - Keyword index: `.harness/shared/resource-index.json`
-- Candidate pool: `HR-Resource/*/SKILL.md`
+- Candidate pool: `.harness/shared/HR-Resource/*/SKILL.md`
+- Installed hired workers: `.claude/skills/{owning-cxx}/{worker}/SKILL.md` and `.codex/skills/{owning-cxx}/{worker}/SKILL.md`
+- Mission worker reports: `.harness/documents/{mission}/{owning-cxx}/workers/{worker}.md`
 
 ## Workflow
 
-1. Check whether a suitable worker is already hired.
-2. If hired, return the exact skill name and wording.
-3. If not hired, suggest HR-Resource candidates and recommend `/hiring`.
-4. Keep aliases narrow enough to avoid accidental generic invocation.
+1. Check whether the requester is a CXX. CEO cannot request specialist worker assignment directly.
+2. Check whether a suitable worker is already hired for that owning CXX.
+3. If hired, return the exact skill name, owning CXX, hierarchical installed paths, and mission report path.
+4. If not hired, suggest `.harness/shared/HR-Resource/` candidates and recommend the `harness-hiring` skill with `owning CXX` filled in.
+5. Keep aliases narrow enough to avoid accidental generic invocation.