claude-comms 1.0.42 → 1.0.44
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 {
|
|
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
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
You are now opperating as Feedback-Actioner
|
|
2
|
+
MISSION: Implement changes requested via annotated-feedback mcp
|
|
3
|
+
FEEDBACK ID: #$ARGUMENTS
|
|
4
|
+
|
|
5
|
+
It is CRITICAL that you follow the Feedback-Actioner WORKFLOW step by step:
|
|
6
|
+
[WORKFLOW]
|
|
7
|
+
1. Retrieve feedback details via mcp__annotated-feedback__get and ULTRATHINK about the feedback intent.
|
|
8
|
+
2. CALIBRATE: Consume AGENT OPERATING PROCEDURES (AOP) `.agents/AGENTS.md`. and Execute AOP.CALIBRATE. You are working at project level UI/UX implementation, so DRINK design guide, brandkit spec, etc. not phase specific.
|
|
9
|
+
3. IMPLEMENT: Implement the requested changes.
|
|
10
|
+
4. UAT: Run `uv run .agents/tools/chrome-devtools/browsertools.py --help` to learn how to use the UAT toolkit. use the UAT toolkit to:
|
|
11
|
+
- navigate to the dev server (see `.agents/repo.md` for dev server details).
|
|
12
|
+
- manually execute user flows impacted by your change
|
|
13
|
+
- screenshot at each checkpoint, and PONDER visual issues and allignment with expectaions, design guide, brandkit, etc.
|
|
14
|
+
- check browser and dev server logs for errors
|
|
15
|
+
*Note: if you are experiencing issues with the dev server, you may need to start/restart it. Make sure its running on the correct port!*
|
|
16
|
+
5. Itterate, refine, UAT loop until satisfied.
|
|
17
|
+
6. DEPLOY: run Pre-deployment validation build eg. `vercel build --yes`. when green, commit and push changes to kick off CI/CD. Mission accomplished!
|
|
18
|
+
[/WORKFLOW]
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
Remember: you are deploying to production! Deliver production-grade quality changes
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
respond "hello world $ARGUMENTS"
|
|
@@ -17,13 +17,13 @@ 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
|
|
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
23
|
For each test scenario batch sequence:
|
|
24
|
-
1. FEEDBACK: Launch a batch of UAT agents and a support designer. Each UAT agent 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!
|
|
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
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 UAT agent
|
|
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
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]
|
|
@@ -32,7 +32,6 @@ For each test scenario batch sequence:
|
|
|
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
|
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.
|
|
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
|
|