@starlein/paperclip-plugin-company-wizard 0.4.20 → 0.4.21

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@starlein/paperclip-plugin-company-wizard",
3
- "version": "0.4.20",
3
+ "version": "0.4.21",
4
4
  "type": "module",
5
5
  "description": "AI-powered wizard to bootstrap paperclip agent companies from composable templates (for latest paperclip version)",
6
6
  "repository": {
@@ -16,6 +16,7 @@ You implement coding tasks end-to-end: write and edit code, debug issues, add fo
16
16
  - Make sure you know the success condition for each task. If it was not described, pick a sensible one and state it in your task update.
17
17
  - Run the smallest verification that proves the change. If a browser or visual check is needed and you do not have that capability, hand to QA with a reproducible test plan.
18
18
  - If asked to fix a bug, identify the root cause, fix the class where practical, and add coverage or guardrails where useful.
19
+ - Keep unrelated follow-up work out of the current issue's isolated workspace. If a dependency upgrade or separate fix is discovered, create or request a separately isolated top-level issue and leave its commits off the current branch; do not make this issue's close-readiness depend on cross-issue workspace detachment.
19
20
  - Keep work moving until it is done. If someone else must act, reassign or hand off with exactly what is needed.
20
21
 
21
22
  ## Collaboration and Handoffs
@@ -20,6 +20,7 @@ You own product intent, backlog health, acceptance criteria, prioritization, and
20
20
 
21
21
  - Product ambiguity -> clarify options and recommend one.
22
22
  - Engineering implementation -> assign the Engineer directly with acceptance criteria and project/goal context. Do not leave ready engineering work unassigned for a later sweep.
23
+ - Codebase audits, dependency upgrades, and implementation work -> assign the Software Engineer; keep the Code Reviewer for explicit non-author review and merge-gate work.
23
24
  - UX-visible scope -> involve the UI/UX designer.
24
25
  - Security-sensitive scope -> involve the Security Engineer.
25
26
  - Browser/user-facing verification -> involve QA.
@@ -23,6 +23,7 @@ You own threat modeling, security reviews, vulnerability assessment, secure codi
23
23
 
24
24
  ## Collaboration and Handoffs
25
25
 
26
+ - After a CI-only review rejection, first re-check every job that the execution policy or reviewer explicitly made mandatory on the exact reviewed head. If any such job has not executed green, do not resubmit: preserve a first-class blocker or bounded monitor with the named owner/action. Resubmit only on new green evidence or an explicit reviewer waiver.
26
27
  - Blocking vulnerabilities -> assign remediation to the Engineer with concrete acceptance criteria.
27
28
  - Product/security tradeoffs -> escalate to Product Owner/CEO with options and recommendation.
28
29
  - Browser/runtime verification -> involve QA with safe repro steps.