claude-comms 1.0.41 → 1.0.43

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.
@@ -569,6 +569,7 @@ def spawn_job(harness: str, assignment: str) -> dict:
569
569
  status: Optional[JobStatus] = None
570
570
  log_file = None
571
571
  buffered_lines: list[str] = [] # Lines read after job_id but before fork
572
+ first_lines: list[str] = [] # Capture first few lines for error reporting
572
573
 
573
574
  try:
574
575
  # Read stdout until we get the job ID
@@ -578,6 +579,10 @@ def spawn_job(harness: str, assignment: str) -> dict:
578
579
  break
579
580
  continue
580
581
 
582
+ # Capture first few lines for debugging if we fail
583
+ if len(first_lines) < 10:
584
+ first_lines.append(line.rstrip())
585
+
581
586
  # Try to parse as JSON
582
587
  event = try_parse_json(line)
583
588
 
@@ -660,7 +665,11 @@ def spawn_job(harness: str, assignment: str) -> dict:
660
665
  if log_file:
661
666
  log_file.close()
662
667
 
663
- return {"error": "Failed to extract job ID from harness output"}
668
+ return {
669
+ "error": "Failed to extract job ID from harness output",
670
+ "exit_code": process.poll(),
671
+ "output": first_lines,
672
+ }
664
673
 
665
674
  except Exception as e:
666
675
  # Clean up on error
@@ -824,7 +833,7 @@ def main():
824
833
  result = spawn_job(args.harness, assignment)
825
834
 
826
835
  if "error" in result:
827
- print(json.dumps(result))
836
+ print(json.dumps(result, indent=2))
828
837
  sys.exit(1)
829
838
 
830
839
  # Print user-friendly message with status command
@@ -17,22 +17,21 @@ You must manage and maintain Todos dynamically, refine Todos after every decisio
17
17
  Populate your initial Todos with your step by step WORKFLOW:
18
18
 
19
19
  [WORKFLOW]
20
- PLAN: ULTRATHINK about the UI/UX pages, features, user flows involved and the dependencies between. Break down ASSIGNMENT into dependency sequenced test scenarios.
20
+ PLAN: ULTRATHINK about the UI/UX pages, features, user flows involved and the dependencies between. Break down ASSIGNMENT into dependency sequenced test scenarios batches.
21
21
  ENABLE: ensure the dev server is running. you may need to kill an old process and start it again `.agents/repo.md`
22
22
 
23
- For each test scenario in the sequence:
24
- 1. FEEDBACK: Task a single UAT agent to manually execute the test scenario, visually inspect the UI/UX and provide feedback on: design allignment, expected functionality, issues encountered, error logs. This UAT agent is a proxy for the user. Their perspecttive matters!
25
- 2. IMPLEMENT: Launch a blended Implementation batch of engineers, codex and gemini consultants to implement changes based on UAT FEEDBACK.
26
- 3. REQUEST APPROVAL: Task a single UAT agent to manually execute the test scenario, and provide their assessment of changes, design allignment, expected functionality.
23
+ For each test scenario batch sequence:
24
+ 1. FEEDBACK: Launch a batch of multiple UAT agents and a support designer. Each UAT agent in the batch should be given a focused test scenario or portion of the app to review. they must visually inspect the UI/UX and provide feedback on: design allignment, expected functionality, issues encountered, error logs. These UAT agents are proxy for the user. Their perspecttive matters!
25
+ 2. IMPLEMENT: Launch a blended Implementation batch of engineers + codex consultants + gemini consultants to implement changes based on UAT FEEDBACK.
26
+ 3. REQUEST APPROVAL: Task a batch of one or more (depending on the number of impacted areas/changes) UAT agents. Each UAT agent in this batch should manually execute one of the test scenarios/areas impacted, and provide their assessment of changes, design allignment, expected functionality.
27
27
  - If UAT gives critical feedback, and DOES NOT APPROVE: itterate until approval awarded.
28
- - When UAT gives signoff approval for deployment, continue to the next test scenario
28
+ - When all UAT agents in the batch give signoff approval for deployment, continue to the next to the next batch of test scenarios
29
29
  [/WORKFLOW]
30
30
 
31
31
 
32
32
  ## 🎯 CRITICAL EXECUTION RULES
33
33
 
34
34
  ### Dependency Laws
35
- ⚡ **NEVER** batch multiple UAT agents together. Focus on one scenario at a time.
36
35
  ⚡ **ALWAYS** Take UAT feedback seriously. They are the user's representitive.
37
36
  ⚡ **ALWAYS** Add new todos if Approval is not awarded.
38
37
  ⚡ **ALWAYS** blend consultants + engineers for implementation/refinement tasks
@@ -80,9 +79,9 @@ Don't refer to prior batch agents by name. Instead, supply reference artifacts t
80
79
 
81
80
 
82
81
  ### Batch Composition Goals
83
- - **Minimum**: 5 agents per implementation batch
82
+ - **Minimum**: 5 agents per batch
84
83
  - **Target**: 8-10 agents including support roles
85
- - **Include**: Support Architect/Researcher for guidance
84
+ - **Include**: roughly equal number of gemini, codex, and engineer implementers, and a support architect for guidance/coordination.
86
85
  - **Follow with**: Verification batch always
87
86
 
88
87
  ### Phase Management
@@ -95,7 +94,7 @@ Don't refer to prior batch agents by name. Instead, supply reference artifacts t
95
94
 
96
95
  ## Consultant Agent
97
96
  Consultants come in two variants: Codex and Gemini. leverage them both liberally to diversify.
98
- When you are batching multple engineers across implementation Tasks, use some consultant agents in place of some engineers. Split the work between Engineers, Gemini consultants and Codex consultants.
97
+ For implementation batches, distribute the tasks across engineers, codex consultants, and gemini consultants. There should be a roughly equal number of engineer, gemini, codex in implementation batches.
99
98
  When you are tasking an agent with read+document type task, recruit a codex and gemini Consultant with the exact same instructions (except a different names). Include the consultants in the same batch. This will net you diverse perspectives on the same research/plan/architect assignment.
100
99
 
101
100
 
package/CLAUDE.md CHANGED
@@ -221,7 +221,7 @@ When you are tasking an agent with read+document type task, recruit a codex and
221
221
  - **designer**: Creates UI/UX specifications, component libraries
222
222
  - **engineer**: Implements features end-to-end with code, writes comprehensive test suites, and documentation. Reviews code for quality, security, and standards compliance. Ensures all builds, tests, and checks pass. Visually inspects the running application against UI/UX design/guide.
223
223
  - **gemini|codex consultant**: diverse multi-hat. same read/doc tasks as planner, architect, designer for perspective roll up. seperate implementation task to engineer, and review engineer implmentation.
224
- - **uat**: uses browser automation to manually test user flows. Collaborates with engineer/consultant in refinement batch, always included in verification batch. Max 1 UAT agent per batch.
224
+ - **uat**: uses browser automation to manually test user flows. Collaborates with engineer/consultant in refinement batch, always included in verification batch.
225
225
 
226
226
  ## Critical Reminders
227
227
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "claude-comms",
3
- "version": "1.0.41",
3
+ "version": "1.0.43",
4
4
  "description": "NPX installer for Claude Code hooks and observability setup",
5
5
  "main": "src/index.js",
6
6
  "bin": {