@glrs-dev/cli 0.1.0 → 0.3.1

package/dist/vendor/harness-opencode/dist/skills/pilot-planning/rules/qa-expectations.md

@@ -0,0 +1,120 @@
+# Rule 10 — QA-expectations establishment
+
+**Detect → propose → confirm per-surface verify patterns.**
+
+A plan's verify commands are its contract with the builder. Generic verifies ("run tests") waste builder time; specific verifies ("run the API tests that exercise the files this task touches") catch real failures. This rule establishes concrete, per-surface QA expectations with the user before emitting the plan.
+
+## The six surfaces
+
+For each surface below, detect signals in the codebase, propose a canonical verify pattern, and confirm with the user.
+
+### UI — Browser-based user interface
+
+**Detection signals:**
+- `@playwright/test`, `cypress`, or `@vitest/browser` in `package.json` dependencies
+- `playwright.config.{ts,js}` or `cypress.config.*` present
+
+**Proposed verify pattern:**
+Playwright MCP invocation for visual/interaction assertions:
+```yaml
+verify:
+  - playwright test --project=chromium --grep "@task-specific-tag"
+```
+
+### API — HTTP endpoints
+
+**Detection signals:**
+- `openapi.yaml` / `openapi.json` present
+- `curl` or `httpie` usage in existing scripts
+- Postman collection files
+
+**Proposed verify pattern:**
+Direct HTTP assertion against a local port:
+```yaml
+verify:
+  - curl -fsS http://localhost:3000/health | jq '.status == "ok"'
+```
+
+### DB — Database schema and queries
+
+**Detection signals:**
+- `docker-compose` postgres service defined
+- `prisma`, `drizzle-kit`, `knex`, or `flyway` in dependencies
+- `test/db` or similar helper directory
+
+**Proposed verify pattern:**
+Postgres readiness + migration + assertion:
+```yaml
+verify:
+  - pg_isready -h localhost -p 5432
+  - pnpm prisma migrate deploy
+  - pnpm tsx scripts/verify-db.ts
+```
+
+### Integration — Cross-module workflows
+
+**Detection signals:**
+- `test/integration/**` directory exists
+- `e2e/**` directory exists
+- `*.integration.test.ts` files
+
+**Proposed verify pattern:**
+Integration test runner scoped to relevant paths:
+```yaml
+verify:
+  - pnpm test test/integration
+```
+
+### Browser-based component — Storybook stories
+
+**Detection signals:**
+- `storybook` or `@storybook/*` in dependencies
+- `*.stories.{ts,tsx}` files present
+
+**Proposed verify pattern:**
+Storybook test or Chromatic visual verification:
+```yaml
+verify:
+  - pnpm storybook test --stories "ComponentName"
+```
+
+### CLI — Command-line interface
+
+**Detection signals:**
+- `bin/*` directory with executables
+- `package.json` `bin:` entry defined
+
+**Proposed verify pattern:**
+Smoke test via help flag or scripted invocation:
+```yaml
+verify:
+  - pnpm my-cli --help
+  - pnpm tsx scripts/smoke-test-cli.ts
+```
+
+## Question-bundling rule
+
+**Two or more surfaces detected:** Bundle into a single structured `question` tool call with one checkbox group per surface.
+
+**One surface detected:** Still ask (confirmation, not interrogation), but use a single-field call.
+
+**Zero surfaces detected:** Skip the QA-expectation question entirely. Fall back to generic verifies:
+```yaml
+defaults:
+  verify_after_each:
+    - pnpm run typecheck
+    - pnpm test
+```
+
+## Emission
+
+Confirmed patterns become:
+
+1. **Per-task verify templates** — tasks targeting specific files use scoped verifies (e.g., `pnpm test test/api/users.test.ts` for a task touching `src/api/users.ts`)
+2. **defaults.verify_after_each** — global breakage catchers (typecheck, full test suite)
+
+The rule: per-task verify targets the specific files touched; defaults catches global breakage.
+
+## Cross-reference to verify-design.md
+
+This rule (10) is the per-surface tactical layer — it names the tools to detect and the patterns to propose. Rule 3 (verify-design.md) owns the principles: deterministic, assertive, would-have-failed-before. Every proposed command must satisfy both layers.

package/dist/vendor/harness-opencode/dist/skills/pilot-planning/rules/self-review.md

@@ -23,7 +23,7 @@ The validator catches schema, DAG, and glob errors. It cannot catch "this verify
 ## Run validate
 
 ```
-bunx @glrs-dev/harness-opencode pilot validate <plan-path>
+bunx @glrs-dev/harness-plugin-opencode pilot validate <plan-path>
 ```
 
 Fix every error AND warning. The "warnings" tier (e.g., glob conflicts between tasks) is also yours to action — either decide they're OK and document it, or restructure.
@@ -33,7 +33,7 @@ Fix every error AND warning. The "warnings" tier (e.g., glob conflicts between t
 When all seven questions are answered "yes" and `pilot validate` exits 0:
 
 - Save the plan.
-- Tell the user: `Plan saved to <path>. Next: bunx @glrs-dev/harness-opencode pilot build`.
+- Tell the user: `Plan saved to <path>. Next: bunx @glrs-dev/harness-plugin-opencode pilot build`.
 - Stop. Don't summarize. Don't editorialize. The user can read the YAML.
 
 ## When the plan is NOT ready

package/dist/vendor/harness-opencode/dist/skills/pilot-planning/rules/setup-authoring.md

@@ -0,0 +1,68 @@
+# Rule 9 — Setup-block authoring
+
+**Detect → propose → confirm the top-level `setup:` block.**
+
+The `setup:` block runs once per worktree before any task executes. It is the environment bootstrap: package manager install, docker-compose services, migration runs. A good setup block means the builder starts with a working environment; a missing one means tasks fail confusingly on missing dependencies.
+
+## Detection signals
+
+During codebase research (Section 2), look for these signals:
+
+**Lockfiles → package manager install:**
+- `pnpm-lock.yaml` → `pnpm install --frozen-lockfile`
+- `bun.lock` → `bun install --frozen-lockfile`
+- `package-lock.json` → `npm ci`
+- `yarn.lock` → `yarn install --frozen-lockfile`
+- `Cargo.lock` → `cargo fetch`
+
+**Docker Compose → service startup:**
+- `docker-compose.yml` or `compose.yaml` with defined services → `docker compose up -d <svc>` for each service the tasks will need (typically postgres, redis, etc.)
+
+**Migration tooling → schema setup:**
+- `package.json` deps containing `knex`, `prisma`, `drizzle-kit`, or `flyway` → corresponding migrate/push command (e.g., `prisma migrate dev`, `drizzle-kit push`)
+
+## Proposal shape
+
+When you detect one or more setup commands, bundle them into a single `question` tool call:
+
+- Present each detected command as a pre-selected checkbox
+- Group by category (Package install, Services, Migrations)
+- Allow the user to uncheck commands that aren't needed or edit the command text
+- Include an "Add another command" free-text field for anything you missed
+
+Example question structure:
+
+```
+Setup commands detected (check all that should run before the first task):
+
+[✓] Package install: pnpm install --frozen-lockfile
+[✓] Services: docker compose up -d postgres
+[✓] Migrations: pnpm prisma migrate dev
+
+[Add another command: __________]
+```
+
+## No-op behavior
+
+If NOTHING is detected (no lockfile, no compose, no migration tooling), emit `setup: []` or omit the key entirely. Do NOT ask the user open-ended "do you need setup?" questions. The schema defaults to `[]`; omitting is safe.
+
+## Emission
+
+Whatever the user confirms becomes the top-level `setup:` block in the written YAML, positioned above `defaults:` (matching schema ordering):
+
+```yaml
+name: my-plan
+setup:
+  - pnpm install --frozen-lockfile
+  - docker compose up -d postgres
+  - pnpm prisma migrate dev
+defaults:
+  verify_after_each:
+    - pnpm run typecheck
+tasks:
+  ...
+```
+
+## Back-compat note
+
+The `setup:` key already defaults to `[]` in the schema (line 241 of `src/pilot/plan/schema.ts`). Plans that omit it or set it to `[]` behave identically to before this rule existed.

package/dist/vendor/harness-opencode/dist/skills/pilot-planning/rules/verify-design.md

@@ -51,3 +51,7 @@ If a verify command flakes, three retries will exhaust attempts and the task fai
 ## Always include a "before" check
 
 For non-trivial tasks, write a verify that would HAVE FAILED before the task ran. This makes the task's value observable. If the verify passed before AND passes after, the task didn't actually move the system.
+
+## Cross-reference: per-surface tooling menu
+
+For the per-surface tooling menu (Playwright for UI, curl for API, Postgres for DB), see rule 10 (`qa-expectations.md`). That rule applies these principles to specific tools; this rule defines the principles themselves.

package/dist/vendor/harness-opencode/package.json

@@ -1,6 +1,6 @@
 {
-  "name": "@glrs-dev/harness-opencode",
-  "version": "1.0.0",
+  "name": "@glrs-dev/harness-plugin-opencode",
+  "version": "0.3.1",
   "type": "module",
   "main": "./dist/index.js",
   "module": "./dist/index.mjs",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@glrs-dev/cli",
-  "version": "0.1.0",
+  "version": "0.3.1",
   "description": "Unified CLI for the @glrs-dev ecosystem — OpenCode agent harness dispatch + worktree management.",
   "license": "MIT",
   "repository": {
@@ -52,7 +52,7 @@
     "zod": "4.1.8"
   },
   "devDependencies": {
-    "@glrs-dev/harness-opencode": "workspace:*",
+    "@glrs-dev/harness-plugin-opencode": "workspace:*",
     "@types/bun": "latest",
     "@types/node": "^22",
     "tsup": "^8",

package/dist/vendor/harness-opencode/dist/install-GDCZ7VFK.js

@@ -1,9 +0,0 @@
-import {
-  MODEL_PRESETS,
-  install
-} from "./chunk-V3KJY6CN.js";
-import "./chunk-UDB4NQ2R.js";
-export {
-  MODEL_PRESETS,
-  install
-};