@starlein/paperclip-plugin-company-wizard 0.4.17 → 0.4.18

package/package.json

@@ -1,25 +1,14 @@
 {
   "name": "@starlein/paperclip-plugin-company-wizard",
-  "version": "0.4.17",
+  "version": "0.4.18",
   "type": "module",
   "description": "AI-powered wizard to bootstrap paperclip agent companies from composable templates (for latest paperclip version)",
-  "repository": "https://github.com/starlein/paperclip-plugin-company-wizard",
-  "scripts": {
-    "build": "node ./esbuild.config.mjs",
-    "build:rollup": "rollup -c",
-    "dev": "node ./esbuild.config.mjs --watch",
-    "dev:ui": "paperclip-plugin-dev-server --root . --ui-dir dist/ui --port 4177",
-    "test": "vitest run --config ./vitest.config.ts",
-    "test:logic": "node --test src/logic/*.test.js src/api/*.test.js",
-    "typecheck": "tsc --noEmit",
-    "build:prod": "NODE_ENV=production node ./esbuild.config.mjs",
-    "publish:npm": "npm publish --access public",
-    "prepublishOnly": "pnpm build:prod",
-    "prepare": "husky"
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/starlein/paperclip-plugin-company-wizard"
   },
   "publishConfig": {
-    "access": "public",
-    "registry": "https://registry.npmjs.org/"
+    "access": "public"
   },
   "lint-staged": {
     "src/**/*.{ts,tsx,js,jsx}": [
@@ -79,5 +68,16 @@
     "@paperclipai/shared": ">=2026.529.0",
     "react": ">=18",
     "react-dom": ">=18"
+  },
+  "scripts": {
+    "build": "node ./esbuild.config.mjs",
+    "build:rollup": "rollup -c",
+    "dev": "node ./esbuild.config.mjs --watch",
+    "dev:ui": "paperclip-plugin-dev-server --root . --ui-dir dist/ui --port 4177",
+    "test": "vitest run --config ./vitest.config.ts",
+    "test:logic": "node --test src/logic/*.test.js src/api/*.test.js",
+    "typecheck": "tsc --noEmit",
+    "build:prod": "NODE_ENV=production node ./esbuild.config.mjs",
+    "publish:npm": "npm publish --access public"
   }
-}
+}

package/templates/bootstrap-instructions.md

@@ -29,11 +29,6 @@ Each section (Goals, Projects, Labels, Agents, Issues, Routines) contains object
 - Do not auto-reopen a `done` parent/subissue unless you have an explicit reason and record it in a comment.
 - Make workspace intent explicit at creation; never rely on implicit inheritance. A top-level issue (no `parentId`) created without `executionWorkspaceSettings` silently adopts the workspace of whatever issue the creator currently has checked out, which serializes work and corrupts branch state. Therefore: top-level issues set `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` (own worktree); subissues set `parentId` and omit `executionWorkspaceSettings` so they deliberately share the parent's workspace (safe because the parent cannot be completed/cleaned up while subissues are open). Keep `projectId` explicit on both.
 
-**Review workflow guardrail:**
-
-- Required PR reviews use the issue's `executionPolicy` review/approval stages, not @-mentions and not separate child review issues. When an engineer opens a PR, set the implementation issue to `in_review` with the resolved execution policy: QA review when present, Security review only for security-relevant changes, Product Owner approval for scope/intent, and a final Code Reviewer merge gate after verification is recorded. **Never list the issue's executor/author as a participant in any stage** — Paperclip excludes the original executor from review/approval, so a stage whose only participant is the author stalls the issue in `in_review` (`422 No eligible approval participant`); the merge gate is therefore a non-author (the Code Reviewer), not the engineer who wrote the code. Each active participant records their decision through the normal issue update route (`approved` by PATCHing toward `done`, `changes_requested` by PATCHing back to `in_progress`), which is the issue-level reviewed/approved audit trail (`reviewed_by` / `approved_by` metadata where Paperclip exposes it). The Code Reviewer merge gate must verify the PR base against the project/worktree base ref shown in `heartbeat-context`, merge before approving, close/archive any isolated worktree when one exists and close-readiness allows it, and only then record final approval. Follow `../../docs/pr-conventions.md` when the PR review module is active.
-- **One PR ⇒ one issue ⇒ its policy stages. Never fan a single PR out into separate per-role issues linked by `blocks`, and never model the merge as a standalone "Code review and merge PR #N" issue that is `blockedBy` the review issues.** That fan-out strands the merge: once the review issues reach `done`, Paperclip does not reliably re-wake the blocked merge issue (worker heartbeats are off, and the liveness watchdog ignores a `blocked` issue whose blockers are all `done`), so the PR is never merged even when it is green and approved. The review/approval/merge-gate steps are **stages on the one implementation issue** that advance in place — the merge gate is the last stage on that same issue, not a separate blocked issue. If you inherit a stranded fan-out, the CEO stall-detection recovers it (*Stranded blocked*), but do not create it.
-
 **Secrets guardrail:**
 
 - Never embed tokens, API keys, banking/SEPA credentials, provider keys, or connection strings in this file, in issue text, or in `adapterConfig`. Provision them as Paperclip company secrets and reference them via `secret_ref` / project `env`. If any secret was pasted in plaintext, rotate it.

package/templates/modules/dependency-management/agents/security-engineer/skills/dependency-audit.fallback.md

@@ -0,0 +1,18 @@
+# Skill: Dependency Audit (Security Fallback)
+
+DevOps primarily owns dependency management. You are the security fallback: step in when DevOps is absent or unavailable, and focus on vulnerability and supply-chain risk.
+
+## Dependency Audit (Fallback)
+
+1. If no `../../docs/DEPENDENCY-AUDIT.md` exists or the last audit is stale:
+   - Run the package manager's vulnerability audit (`npm audit`, `pip-audit`, `go vuln check`, or equivalent).
+   - Identify Critical/High CVEs, abandoned packages, suspicious transitive dependencies, and risky license or provenance issues.
+   - Document findings and risk level in `../../docs/DEPENDENCY-AUDIT.md`.
+   - Apply safe security patch updates only when tests pass.
+2. If DevOps is active and already running the audit, review their findings for security completeness instead of duplicating the work.
+
+## Rules
+
+- This is a safety net. Prioritize exploitable vulnerabilities and supply-chain risk.
+- Do not perform broad major-version migrations without a dedicated issue.
+- Every dependency change must include test output and a clear rollback note.

package/templates/modules/game-design/agents/engineer/skills/game-design.fallback.md

@@ -0,0 +1,17 @@
+# Skill: Game Design (Engineer Fallback)
+
+The Game Designer primarily owns the game design. You are the engineering fallback: define enough structure for implementation to move without pretending the design is final.
+
+## Game Design (Fallback)
+
+1. If no `../../docs/GDD.md` exists and no Game Designer is active:
+   - Write a minimal Game Design Document covering concept, core mechanic, game loop, platform, controls, and technical constraints.
+   - Identify implementation risks: physics, input, asset pipeline, save state, performance, and browser/device support.
+   - Mark open design questions explicitly so a Game Designer or CEO can resolve them later.
+2. If a Game Designer is active, do not overwrite their design direction. Add implementation notes or feasibility concerns as comments/issues.
+
+## Rules
+
+- This is a safety net. Keep the GDD implementable and provisional.
+- Do not over-spec detailed balance, progression, or narrative unless required to unblock engineering.
+- Convert unclear design risks into small prototype or research issues.

package/templates/modules/triage/agents/engineer/skills/issue-triage.fallback.md

@@ -0,0 +1,20 @@
+# Skill: Issue Triage (Engineer Fallback)
+
+The Product Owner primarily owns issue triage. You are the engineering fallback: keep technical reports moving when Product Owner coverage is absent.
+
+## Issue Triage (Fallback)
+
+1. Use this only when assigned a GitHub issue triage task or routine.
+2. Check untriaged GitHub issues: `gh issue list --state open --label "" --json number,title,body,labels,createdAt`.
+3. For each technical issue:
+   - Reproduce or inspect enough to classify it as bug, feature, question, duplicate, invalid, or needs-info.
+   - Apply labels and priority based on user impact and technical severity.
+   - Create Paperclip issues for actionable bugs or engineering work. Top-level Paperclip issues should include `executionWorkspaceSettings: { "mode": "isolated_workspace" }`; subissues set `parentId` and omit workspace settings.
+   - Ask concise follow-up questions when reproduction details are missing.
+4. Leave product-priority and roadmap tradeoffs for the Product Owner or CEO.
+
+## Rules
+
+- This is a safety net. Focus on technical correctness and clear routing.
+- Do not close feature requests as invalid because they are out of scope; label and route them.
+- Link GitHub issues and Paperclip issues in both directions when you create follow-up work.

package/templates/roles/engineer/HEARTBEAT.md

@@ -35,7 +35,7 @@ Run this checklist on every heartbeat. The Paperclip skill is the source of trut
 - Upload or attach user-inspectable outputs as work products/artifacts/documents; local filesystem paths alone are not enough.
 - Use issue documents for long plans, specs, QA reports, security reviews, or hiring drafts; comments should summarize and link.
 - Handoffs should use assignment/status/executionPolicy and a concrete next action. Do not rely on generic @-mentions.
-- **Review path applies only when the pr-review module is active.** Without pr-review there is no PR review flow and no `in_review` step — you follow the Direct-to-Base Flow in `skills/git-workflow.md` (verify locally, commit, push to the base ref; open a PR only if branch protection rejects the direct push). The rest of this bullet applies only when pr-review is active. Before moving work to `in_review`, verify a review path exists. If a Code Reviewer is on the team, set the `executionPolicy` stages (at least one non-author stage) **before** moving to `in_review` — an `in_review` issue with `executionPolicy: null` has no eligible participant and stalls forever (`422 No eligible approval participant`). The **first** stage must be a non-author stage: never list yourself (the issue's assignee/executor — whoever did the work) as a participant in any stage. The runtime excludes the original executor from every stage, so a first stage listing only you has no eligible participant and the issue stalls at stage 1 (`422 Only the active reviewer or approver can advance the current execution stage`) — even if later stages have non-author participants. After moving to `in_review`, `GET /api/issues/{id}` (the list endpoint omits `executionPolicy`) and confirm `stages[0].participants` is not just you; if it is, `PATCH /api/issues/{id}` `{"executionPolicy":null}` to return to `in_progress`, then re-set stages with a non-author first stage. If no Code Reviewer is on the team, do not move to `in_review` at all: open the PR and merge it yourself via `gh pr merge <N> --merge` in the same heartbeat (self-merge path), then mark `done`. If you find an issue already `in_review` with `executionPolicy: null` or an author-only first stage, it is a stall — recover by nulling the policy (`PATCH {"executionPolicy":null}` → `in_progress`), then either set `executionPolicy` stages with a non-author first stage (Code Reviewer present) or self-merge the PR (no Code Reviewer). Never leave finished work in `in_review` assigned to yourself.
+- **Review path applies only when the pr-review module is active.** Without pr-review there is no PR review flow and no `in_review` step. If the github-repo module installed `skills/git-workflow.md`, follow its Direct-to-Base Flow (verify locally, commit, push to the base ref; open a PR only if branch protection rejects the direct push). Otherwise follow the project workspace instructions and record the verification/commit evidence. The rest of this bullet applies only when pr-review is active. Before moving work to `in_review`, verify a review path exists. If a Code Reviewer is on the team, set the `executionPolicy` stages (at least one non-author stage) **before** moving to `in_review` — an `in_review` issue with `executionPolicy: null` has no eligible participant and stalls forever (`422 No eligible participant`). The **first** stage must be a non-author stage: never list yourself (the issue's assignee/executor — whoever did the work) as a participant in any stage. The runtime excludes the original executor from every stage, so a first stage listing only you has no eligible participant and the issue stalls at stage 1 (`422 Only the active reviewer or approver can advance the current execution stage`) — even if later stages have non-author participants. After moving to `in_review`, `GET /api/issues/{id}` (the list endpoint omits `executionPolicy`) and confirm `stages[0].participants` is not just you; if it is, `PATCH /api/issues/{id}` `{"executionPolicy":null}` to return to `in_progress`, then re-set stages with a non-author first stage. If no Code Reviewer is on the team, do not move to `in_review` at all: open the PR and merge it yourself via `gh pr merge <N> --merge` in the same heartbeat (self-merge path), then mark `done`. If you find an issue already `in_review` with `executionPolicy: null` or an author-only first stage, it is a stall — recover by nulling the policy (`PATCH {"executionPolicy":null}` → `in_progress`), then either set `executionPolicy` stages with a non-author first stage (Code Reviewer present) or self-merge the PR (no Code Reviewer). Never leave finished work in `in_review` assigned to yourself.
 
 ## 6. Exit