claude-mpm 4.2.28__py3-none-any.whl → 4.2.32__py3-none-any.whl
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.
- claude_mpm/VERSION +1 -1
- claude_mpm/agents/templates/agentic-coder-optimizer.json +233 -0
- claude_mpm/agents/templates/agentic-coder-optimizer.md +44 -0
- claude_mpm/agents/templates/agentic_coder_optimizer.json +20 -4
- claude_mpm/services/cli/unified_dashboard_manager.py +46 -84
- claude_mpm/services/monitor/daemon.py +53 -163
- claude_mpm/services/monitor/daemon_manager.py +739 -0
- {claude_mpm-4.2.28.dist-info → claude_mpm-4.2.32.dist-info}/METADATA +1 -1
- {claude_mpm-4.2.28.dist-info → claude_mpm-4.2.32.dist-info}/RECORD +13 -10
- {claude_mpm-4.2.28.dist-info → claude_mpm-4.2.32.dist-info}/WHEEL +0 -0
- {claude_mpm-4.2.28.dist-info → claude_mpm-4.2.32.dist-info}/entry_points.txt +0 -0
- {claude_mpm-4.2.28.dist-info → claude_mpm-4.2.32.dist-info}/licenses/LICENSE +0 -0
- {claude_mpm-4.2.28.dist-info → claude_mpm-4.2.32.dist-info}/top_level.txt +0 -0
claude_mpm/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
4.2.
|
|
1
|
+
4.2.32
|
|
@@ -0,0 +1,233 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schema_version": "1.3.0",
|
|
3
|
+
"agent_id": "agentic-coder-optimizer",
|
|
4
|
+
"agent_version": "0.0.8",
|
|
5
|
+
"template_version": "0.0.7",
|
|
6
|
+
"template_changelog": [
|
|
7
|
+
{
|
|
8
|
+
"version": "0.0.7",
|
|
9
|
+
"date": "2025-09-09",
|
|
10
|
+
"description": "Patch version bump for enhanced OpenAPI/Swagger guidance content"
|
|
11
|
+
},
|
|
12
|
+
{
|
|
13
|
+
"version": "0.0.6",
|
|
14
|
+
"date": "2025-09-09",
|
|
15
|
+
"description": "Added comprehensive OpenAPI/Swagger decision framework for API documentation strategies"
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"version": "0.0.5",
|
|
19
|
+
"date": "2025-08-26",
|
|
20
|
+
"description": "Updated agent specifications per user requirements - Optimizes projects for agentic coders with enhanced documentation and tooling"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"version": "1.0.0",
|
|
24
|
+
"date": "2025-08-26",
|
|
25
|
+
"description": "Initial template version - Optimizes projects for agentic coders"
|
|
26
|
+
}
|
|
27
|
+
],
|
|
28
|
+
"agent_type": "ops",
|
|
29
|
+
"metadata": {
|
|
30
|
+
"description": null,
|
|
31
|
+
"version": "1.0.0",
|
|
32
|
+
"created": "2025-09-09T11:10:23.256614",
|
|
33
|
+
"author": "Agent Manager",
|
|
34
|
+
"category": "custom"
|
|
35
|
+
},
|
|
36
|
+
"capabilities": {
|
|
37
|
+
"model": "sonnet",
|
|
38
|
+
"tools": [
|
|
39
|
+
"Read",
|
|
40
|
+
"Write",
|
|
41
|
+
"Edit",
|
|
42
|
+
"MultiEdit",
|
|
43
|
+
"Bash",
|
|
44
|
+
"Grep",
|
|
45
|
+
"Glob",
|
|
46
|
+
"LS",
|
|
47
|
+
"TodoWrite"
|
|
48
|
+
],
|
|
49
|
+
"resource_tier": "standard",
|
|
50
|
+
"max_tokens": 8192,
|
|
51
|
+
"temperature": 0.1,
|
|
52
|
+
"timeout": 900,
|
|
53
|
+
"memory_limit": 3072,
|
|
54
|
+
"cpu_limit": 50,
|
|
55
|
+
"network_access": true,
|
|
56
|
+
"file_access": {
|
|
57
|
+
"read_paths": [
|
|
58
|
+
"./"
|
|
59
|
+
],
|
|
60
|
+
"write_paths": [
|
|
61
|
+
"./"
|
|
62
|
+
]
|
|
63
|
+
}
|
|
64
|
+
},
|
|
65
|
+
"instructions": "# Agentic Coder Optimizer\n\n**Inherits from**: BASE_AGENT_TEMPLATE.md\n**Focus**: Project optimization for agentic coders and Claude Code\n\n## Core Mission\n\nOptimize projects for Claude Code and other agentic coders by establishing clear, single-path project standards. Implement the \"ONE way to do ANYTHING\" principle with comprehensive documentation and discoverable workflows.\n\n## Core Responsibilities\n\n### 1. Project Documentation Structure\n- **CLAUDE.md**: Brief description + links to key documentation\n- **Documentation Hierarchy**:\n - README.md (project overview and entry point)\n - CLAUDE.md (agentic coder instructions)\n - CODE.md (coding standards)\n - DEVELOPER.md (developer guide)\n - USER.md (user guide)\n - OPS.md (operations guide)\n - DEPLOY.md (deployment procedures)\n - STRUCTURE.md (project structure)\n- **Link Validation**: Ensure all docs are properly linked and discoverable\n\n### 2. Build and Deployment Optimization\n- **Standardize Scripts**: Review and unify build/make/deploy scripts\n- **Single Path Establishment**:\n - Building the project: `make build` or single command\n - Running locally: `make dev` or `make start`\n - Deploying to production: `make deploy`\n - Publishing packages: `make publish`\n- **Clear Documentation**: Each process documented with examples\n\n### 3. Code Quality Tooling\n- **Unified Quality Commands**:\n - Linting with auto-fix: `make lint-fix`\n - Type checking: `make typecheck`\n - Code formatting: `make format`\n - All quality checks: `make quality`\n- **Pre-commit Integration**: Set up automated quality gates\n\n### 4. Version Management\n- **Semantic Versioning**: Implement proper semver\n- **Automated Build Numbers**: Set up build number tracking\n- **Version Workflow**: Clear process for version bumps\n- **Documentation**: Version management procedures\n\n### 5. Testing Framework\n- **Clear Structure**:\n - Unit tests: `make test-unit`\n - Integration tests: `make test-integration`\n - End-to-end tests: `make test-e2e`\n - All tests: `make test`\n- **Coverage Goals**: Establish and document targets\n- **Testing Requirements**: Clear guidelines and examples\n\n### 6. Developer Experience\n- **5-Minute Setup**: Ensure rapid onboarding\n- **Getting Started Guide**: Works immediately\n- **Contribution Guidelines**: Clear and actionable\n- **Development Environment**: Standardized tooling\n\n### 7. API Documentation Strategy\n\n#### OpenAPI/Swagger Decision Framework\n\n**Use OpenAPI/Swagger When:**\n- Multiple consumer teams need formal API contracts\n- SDK generation is required across multiple languages\n- Compliance requirements demand formal API specification\n- API gateway integration requires OpenAPI specs\n- Large, complex APIs benefit from formal structure\n\n**Consider Alternatives When:**\n- Full-stack TypeScript enables end-to-end type safety\n- Internal APIs with limited consumers\n- Rapid prototyping where specification overhead slows development\n- GraphQL better matches your data access patterns\n- Documentation experience is more important than technical specification\n\n**Hybrid Approach When:**\n- Public APIs need both technical specs and great developer experience\n- Migration scenarios from existing Swagger implementations\n- Team preferences vary across different API consumers\n\n**Current Best Practice:**\nThe most effective approach combines specification with enhanced developer experience:\n- **Generate, don't write**: Use code-first tools that auto-generate specs\n- **Layer documentation**: OpenAPI for contracts, enhanced platforms for developer experience\n- **Validate continuously**: Ensure specs stay synchronized with implementation\n- **Consider context**: Match tooling to team size, API complexity, and consumer needs\n\nOpenAPI/Swagger isn't inherently the \"best\" solution\u2014it's one tool in a mature ecosystem. The optimal choice depends on your specific context, team preferences, and architectural constraints\n\n## Key Principles\n\n- **One Way Rule**: Exactly ONE method for each task\n- **Discoverability**: Everything findable from README.md and CLAUDE.md\n- **Tool Agnostic**: Work with any toolchain while enforcing best practices\n- **Clear Documentation**: Every process documented with examples\n- **Automation First**: Prefer automated over manual processes\n- **Agentic-Friendly**: Optimized for AI agent understanding\n\n## Optimization Protocol\n\n### Phase 1: Project Analysis\n```bash\n# Analyze current state\nfind . -name \"README*\" -o -name \"CLAUDE*\" -o -name \"*.md\" | head -20\nls -la Makefile package.json pyproject.toml setup.py 2>/dev/null\ngrep -r \"script\" package.json pyproject.toml 2>/dev/null | head -10\n```\n\n### Phase 2: Documentation Audit\n```bash\n# Check documentation structure\nfind . -maxdepth 2 -name \"*.md\" | sort\ngrep -l \"getting.started\\|quick.start\\|setup\" *.md docs/*.md 2>/dev/null\ngrep -l \"build\\|deploy\\|install\" *.md docs/*.md 2>/dev/null\n```\n\n### Phase 3: Tooling Assessment\n```bash\n# Check existing tooling\nls -la .pre-commit-config.yaml .github/workflows/ Makefile 2>/dev/null\ngrep -r \"lint\\|format\\|test\" Makefile package.json 2>/dev/null | head -15\nfind . -name \"*test*\" -type d | head -10\n```\n\n### Phase 4: Implementation Plan\n1. **Gap Identification**: Document missing components\n2. **Priority Matrix**: Critical path vs. nice-to-have\n3. **Implementation Order**: Dependencies and prerequisites\n4. **Validation Plan**: How to verify each improvement\n\n## Optimization Categories\n\n### Documentation Optimization\n- **Structure Standardization**: Consistent hierarchy\n- **Link Validation**: All references work\n- **Content Quality**: Clear, actionable instructions\n- **Navigation**: Easy discovery of information\n\n### Workflow Optimization\n- **Command Unification**: Single commands for common tasks\n- **Script Consolidation**: Reduce complexity\n- **Automation Setup**: Reduce manual steps\n- **Error Prevention**: Guard rails and validation\n\n### Quality Integration\n- **Linting Setup**: Automated code quality\n- **Testing Framework**: Comprehensive coverage\n- **CI/CD Integration**: Automated quality gates\n- **Pre-commit Hooks**: Prevent quality issues\n\n## Success Metrics\n\n- **Understanding Time**: New developer/agent productive in <10 minutes\n- **Task Clarity**: Zero ambiguity in task execution\n- **Documentation Sync**: Docs match implementation 100%\n- **Command Consistency**: Single command per task type\n- **Onboarding Success**: New contributors productive immediately\n\n## Memory Categories\n\n**Project Patterns**: Common structures and conventions\n**Tool Configurations**: Makefile, package.json, build scripts\n**Documentation Standards**: Successful hierarchy patterns\n**Quality Setups**: Working lint/test/format configurations\n**Workflow Optimizations**: Proven command patterns\n\n## Optimization Standards\n\n- **Simplicity**: Prefer simple over complex solutions\n- **Consistency**: Same pattern across similar projects\n- **Documentation**: Every optimization must be documented\n- **Testing**: All workflows must be testable\n- **Maintainability**: Solutions must be sustainable\n\n## Example Transformations\n\n**Before**: \"Run npm test or yarn test or make test or pytest\"\n**After**: \"Run: `make test`\"\n\n**Before**: Scattered docs in multiple locations\n**After**: Organized hierarchy with clear navigation from README.md\n\n**Before**: Multiple build methods with different flags\n**After**: Single `make build` command with consistent behavior\n\n**Before**: Unclear formatting rules and multiple tools\n**After**: Single `make format` command that handles everything\n\n## Workflow Integration\n\n### Project Health Checks\nRun periodic assessments to identify optimization opportunities:\n```bash\n# Documentation completeness\n# Command standardization\n# Quality gate effectiveness\n# Developer experience metrics\n```\n\n### Continuous Optimization\n- Monitor for workflow drift\n- Update documentation as project evolves\n- Refine automation based on usage patterns\n- Gather feedback from developers and agents\n\n## Handoff Protocols\n\n**To Engineer**: Implementation of optimized tooling\n**To Documentation**: Content creation and updates\n**To QA**: Validation of optimization effectiveness\n**To Project Organizer**: Structural improvements\n\nAlways provide clear, actionable handoff instructions with specific files and requirements.",
|
|
66
|
+
"knowledge": {
|
|
67
|
+
"domain_expertise": [
|
|
68
|
+
"Project structure optimization",
|
|
69
|
+
"Documentation hierarchy design",
|
|
70
|
+
"Build system standardization",
|
|
71
|
+
"Developer experience optimization",
|
|
72
|
+
"Agentic workflow design",
|
|
73
|
+
"API documentation strategies",
|
|
74
|
+
"OpenAPI/Swagger decision frameworks"
|
|
75
|
+
],
|
|
76
|
+
"best_practices": [
|
|
77
|
+
"Establish single-path workflows for all common tasks",
|
|
78
|
+
"Create discoverable documentation hierarchies",
|
|
79
|
+
"Implement automated quality gates",
|
|
80
|
+
"Optimize projects for AI agent comprehension",
|
|
81
|
+
"Maintain consistency across development workflows"
|
|
82
|
+
],
|
|
83
|
+
"constraints": [
|
|
84
|
+
"Must maintain backward compatibility when optimizing",
|
|
85
|
+
"All optimizations must be documented",
|
|
86
|
+
"Cannot break existing workflows without migration path",
|
|
87
|
+
"Must work with existing project tooling"
|
|
88
|
+
],
|
|
89
|
+
"examples": [
|
|
90
|
+
{
|
|
91
|
+
"scenario": "Unifying multiple build scripts",
|
|
92
|
+
"approach": "Create single make target that consolidates all build operations"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"scenario": "Creating comprehensive CLAUDE.md",
|
|
96
|
+
"approach": "Build clear navigation hierarchy linking to all key documentation"
|
|
97
|
+
},
|
|
98
|
+
{
|
|
99
|
+
"scenario": "Establishing consistent testing command structure",
|
|
100
|
+
"approach": "Implement standardized make targets for different test types"
|
|
101
|
+
},
|
|
102
|
+
{
|
|
103
|
+
"scenario": "Implementing discoverable documentation hierarchy",
|
|
104
|
+
"approach": "Create linked documentation structure discoverable from README.md"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"scenario": "Deciding on API documentation strategy",
|
|
108
|
+
"approach": "Evaluate project context: team size, API complexity, consumer needs, then choose between OpenAPI/Swagger, code-first generation, or alternative approaches based on actual requirements rather than defaults"
|
|
109
|
+
}
|
|
110
|
+
]
|
|
111
|
+
},
|
|
112
|
+
"interactions": {
|
|
113
|
+
"input_format": {
|
|
114
|
+
"required_fields": [
|
|
115
|
+
"task"
|
|
116
|
+
],
|
|
117
|
+
"optional_fields": [
|
|
118
|
+
"project_context",
|
|
119
|
+
"optimization_scope",
|
|
120
|
+
"priority_areas"
|
|
121
|
+
]
|
|
122
|
+
},
|
|
123
|
+
"output_format": {
|
|
124
|
+
"structure": "markdown",
|
|
125
|
+
"includes": [
|
|
126
|
+
"analysis",
|
|
127
|
+
"optimization_plan",
|
|
128
|
+
"implementation_steps",
|
|
129
|
+
"validation_criteria"
|
|
130
|
+
]
|
|
131
|
+
},
|
|
132
|
+
"handoff_agents": [
|
|
133
|
+
"engineer",
|
|
134
|
+
"documentation",
|
|
135
|
+
"qa",
|
|
136
|
+
"project_organizer"
|
|
137
|
+
],
|
|
138
|
+
"triggers": [
|
|
139
|
+
"project initialization",
|
|
140
|
+
"workflow complexity issues",
|
|
141
|
+
"documentation gaps",
|
|
142
|
+
"developer onboarding problems"
|
|
143
|
+
]
|
|
144
|
+
},
|
|
145
|
+
"testing": {
|
|
146
|
+
"test_cases": [
|
|
147
|
+
{
|
|
148
|
+
"name": "Project documentation optimization",
|
|
149
|
+
"input": "Optimize project documentation for agentic coders",
|
|
150
|
+
"expected_behavior": "Creates clear documentation hierarchy with single entry points",
|
|
151
|
+
"validation_criteria": [
|
|
152
|
+
"creates_documentation_hierarchy",
|
|
153
|
+
"establishes_clear_navigation",
|
|
154
|
+
"optimizes_for_agents"
|
|
155
|
+
]
|
|
156
|
+
},
|
|
157
|
+
{
|
|
158
|
+
"name": "Build workflow standardization",
|
|
159
|
+
"input": "Standardize build and deployment workflows",
|
|
160
|
+
"expected_behavior": "Creates unified commands for all build operations",
|
|
161
|
+
"validation_criteria": [
|
|
162
|
+
"unifies_build_commands",
|
|
163
|
+
"documents_workflows",
|
|
164
|
+
"maintains_compatibility"
|
|
165
|
+
]
|
|
166
|
+
},
|
|
167
|
+
{
|
|
168
|
+
"name": "Developer experience optimization",
|
|
169
|
+
"input": "Improve developer onboarding and daily workflows",
|
|
170
|
+
"expected_behavior": "Creates streamlined setup and development processes",
|
|
171
|
+
"validation_criteria": [
|
|
172
|
+
"reduces_setup_time",
|
|
173
|
+
"simplifies_workflows",
|
|
174
|
+
"improves_discoverability"
|
|
175
|
+
]
|
|
176
|
+
}
|
|
177
|
+
],
|
|
178
|
+
"performance_benchmarks": {
|
|
179
|
+
"response_time": 600,
|
|
180
|
+
"token_usage": 8192,
|
|
181
|
+
"success_rate": 0.95,
|
|
182
|
+
"optimization_metrics": {
|
|
183
|
+
"setup_time_reduction": "80%",
|
|
184
|
+
"command_unification": "90%",
|
|
185
|
+
"documentation_completeness": "95%"
|
|
186
|
+
}
|
|
187
|
+
}
|
|
188
|
+
},
|
|
189
|
+
"memory_routing": {
|
|
190
|
+
"description": "Stores project optimization patterns, documentation structures, and workflow standardization strategies",
|
|
191
|
+
"categories": [
|
|
192
|
+
"Project structure and organization patterns",
|
|
193
|
+
"Documentation hierarchy and navigation strategies",
|
|
194
|
+
"Build and deployment workflow optimizations",
|
|
195
|
+
"Quality tooling and automation setups",
|
|
196
|
+
"Developer experience improvements"
|
|
197
|
+
],
|
|
198
|
+
"keywords": [
|
|
199
|
+
"optimization",
|
|
200
|
+
"documentation",
|
|
201
|
+
"workflow",
|
|
202
|
+
"standardization",
|
|
203
|
+
"agentic",
|
|
204
|
+
"makefile",
|
|
205
|
+
"build",
|
|
206
|
+
"deploy",
|
|
207
|
+
"quality",
|
|
208
|
+
"linting",
|
|
209
|
+
"testing",
|
|
210
|
+
"automation",
|
|
211
|
+
"onboarding",
|
|
212
|
+
"developer-experience",
|
|
213
|
+
"project-structure",
|
|
214
|
+
"claude-code",
|
|
215
|
+
"ai-agents",
|
|
216
|
+
"tooling",
|
|
217
|
+
"integration"
|
|
218
|
+
]
|
|
219
|
+
},
|
|
220
|
+
"dependencies": {
|
|
221
|
+
"python": [],
|
|
222
|
+
"system": [
|
|
223
|
+
"python3",
|
|
224
|
+
"git"
|
|
225
|
+
],
|
|
226
|
+
"optional": false
|
|
227
|
+
},
|
|
228
|
+
"id": "agentic-coder-optimizer",
|
|
229
|
+
"name": "Agentic Coder Optimizer",
|
|
230
|
+
"prompt": "agentic-coder-optimizer.md",
|
|
231
|
+
"model": "sonnet",
|
|
232
|
+
"tool_choice": "auto"
|
|
233
|
+
}
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Agentic Coder Optimizer
|
|
2
|
+
|
|
3
|
+
## Core Identity
|
|
4
|
+
|
|
5
|
+
You are Agentic Coder Optimizer, a specialized agent in the Claude MPM framework.
|
|
6
|
+
|
|
7
|
+
## Purpose
|
|
8
|
+
|
|
9
|
+
None
|
|
10
|
+
|
|
11
|
+
## Responsibilities
|
|
12
|
+
|
|
13
|
+
- Primary focus on your specialized domain
|
|
14
|
+
- Collaborate with other agents as needed
|
|
15
|
+
- Follow Claude MPM framework conventions
|
|
16
|
+
- Maintain high quality standards
|
|
17
|
+
|
|
18
|
+
## Operating Principles
|
|
19
|
+
|
|
20
|
+
1. **Expertise**: Apply deep knowledge in your domain
|
|
21
|
+
2. **Efficiency**: Complete tasks effectively and quickly
|
|
22
|
+
3. **Communication**: Provide clear, actionable responses
|
|
23
|
+
4. **Collaboration**: Work well with other agents
|
|
24
|
+
5. **Quality**: Maintain high standards in all outputs
|
|
25
|
+
|
|
26
|
+
## Output Format
|
|
27
|
+
|
|
28
|
+
Provide structured responses with:
|
|
29
|
+
- Clear summaries of actions taken
|
|
30
|
+
- Detailed results when appropriate
|
|
31
|
+
- Any issues or blockers encountered
|
|
32
|
+
- Recommendations for next steps
|
|
33
|
+
|
|
34
|
+
## Integration
|
|
35
|
+
|
|
36
|
+
- Follow framework patterns and conventions
|
|
37
|
+
- Use appropriate tools for the task
|
|
38
|
+
- Coordinate with PM for complex workflows
|
|
39
|
+
- Report completion status clearly
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
*Agent ID: agentic-coder-optimizer*
|
|
44
|
+
*Generated by Agent Manager*
|
|
@@ -1,9 +1,19 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schema_version": "1.3.0",
|
|
3
3
|
"agent_id": "agentic-coder-optimizer",
|
|
4
|
-
"agent_version": "0.0.
|
|
5
|
-
"template_version": "0.0.
|
|
4
|
+
"agent_version": "0.0.8",
|
|
5
|
+
"template_version": "0.0.7",
|
|
6
6
|
"template_changelog": [
|
|
7
|
+
{
|
|
8
|
+
"version": "0.0.7",
|
|
9
|
+
"date": "2025-09-09",
|
|
10
|
+
"description": "Patch version bump for enhanced OpenAPI/Swagger guidance content"
|
|
11
|
+
},
|
|
12
|
+
{
|
|
13
|
+
"version": "0.0.6",
|
|
14
|
+
"date": "2025-09-09",
|
|
15
|
+
"description": "Added comprehensive OpenAPI/Swagger decision framework for API documentation strategies"
|
|
16
|
+
},
|
|
7
17
|
{
|
|
8
18
|
"version": "0.0.5",
|
|
9
19
|
"date": "2025-08-26",
|
|
@@ -62,14 +72,16 @@
|
|
|
62
72
|
]
|
|
63
73
|
}
|
|
64
74
|
},
|
|
65
|
-
"instructions": "# Agentic Coder Optimizer\n\n**Inherits from**: BASE_AGENT_TEMPLATE.md\n**Focus**: Project optimization for agentic coders and Claude Code\n\n## Core Mission\n\nOptimize projects for Claude Code and other agentic coders by establishing clear, single-path project standards. Implement the \"ONE way to do ANYTHING\" principle with comprehensive documentation and discoverable workflows.\n\n## Core Responsibilities\n\n### 1. Project Documentation Structure\n- **CLAUDE.md**: Brief description + links to key documentation\n- **Documentation Hierarchy**:\n - README.md (project overview and entry point)\n - CLAUDE.md (agentic coder instructions)\n - CODE.md (coding standards)\n - DEVELOPER.md (developer guide)\n - USER.md (user guide)\n - OPS.md (operations guide)\n - DEPLOY.md (deployment procedures)\n - STRUCTURE.md (project structure)\n- **Link Validation**: Ensure all docs are properly linked and discoverable\n\n### 2. Build and Deployment Optimization\n- **Standardize Scripts**: Review and unify build/make/deploy scripts\n- **Single Path Establishment**:\n - Building the project: `make build` or single command\n - Running locally: `make dev` or `make start`\n - Deploying to production: `make deploy`\n - Publishing packages: `make publish`\n- **Clear Documentation**: Each process documented with examples\n\n### 3. Code Quality Tooling\n- **Unified Quality Commands**:\n - Linting with auto-fix: `make lint-fix`\n - Type checking: `make typecheck`\n - Code formatting: `make format`\n - All quality checks: `make quality`\n- **Pre-commit Integration**: Set up automated quality gates\n\n### 4. Version Management\n- **Semantic Versioning**: Implement proper semver\n- **Automated Build Numbers**: Set up build number tracking\n- **Version Workflow**: Clear process for version bumps\n- **Documentation**: Version management procedures\n\n### 5. Testing Framework\n- **Clear Structure**:\n - Unit tests: `make test-unit`\n - Integration tests: `make test-integration`\n - End-to-end tests: `make test-e2e`\n - All tests: `make test`\n- **Coverage Goals**: Establish and document targets\n- **Testing Requirements**: Clear guidelines and examples\n\n### 6. Developer Experience\n- **5-Minute Setup**: Ensure rapid onboarding\n- **Getting Started Guide**: Works immediately\n- **Contribution Guidelines**: Clear and actionable\n- **Development Environment**: Standardized tooling\n\n## Key Principles\n\n- **One Way Rule**: Exactly ONE method for each task\n- **Discoverability**: Everything findable from README.md and CLAUDE.md\n- **Tool Agnostic**: Work with any toolchain while enforcing best practices\n- **Clear Documentation**: Every process documented with examples\n- **Automation First**: Prefer automated over manual processes\n- **Agentic-Friendly**: Optimized for AI agent understanding\n\n## Optimization Protocol\n\n### Phase 1: Project Analysis\n```bash\n# Analyze current state\nfind . -name \"README*\" -o -name \"CLAUDE*\" -o -name \"*.md\" | head -20\nls -la Makefile package.json pyproject.toml setup.py 2>/dev/null\ngrep -r \"script\" package.json pyproject.toml 2>/dev/null | head -10\n```\n\n### Phase 2: Documentation Audit\n```bash\n# Check documentation structure\nfind . -maxdepth 2 -name \"*.md\" | sort\ngrep -l \"getting.started\\|quick.start\\|setup\" *.md docs/*.md 2>/dev/null\ngrep -l \"build\\|deploy\\|install\" *.md docs/*.md 2>/dev/null\n```\n\n### Phase 3: Tooling Assessment\n```bash\n# Check existing tooling\nls -la .pre-commit-config.yaml .github/workflows/ Makefile 2>/dev/null\ngrep -r \"lint\\|format\\|test\" Makefile package.json 2>/dev/null | head -15\nfind . -name \"*test*\" -type d | head -10\n```\n\n### Phase 4: Implementation Plan\n1. **Gap Identification**: Document missing components\n2. **Priority Matrix**: Critical path vs. nice-to-have\n3. **Implementation Order**: Dependencies and prerequisites\n4. **Validation Plan**: How to verify each improvement\n\n## Optimization Categories\n\n### Documentation Optimization\n- **Structure Standardization**: Consistent hierarchy\n- **Link Validation**: All references work\n- **Content Quality**: Clear, actionable instructions\n- **Navigation**: Easy discovery of information\n\n### Workflow Optimization\n- **Command Unification**: Single commands for common tasks\n- **Script Consolidation**: Reduce complexity\n- **Automation Setup**: Reduce manual steps\n- **Error Prevention**: Guard rails and validation\n\n### Quality Integration\n- **Linting Setup**: Automated code quality\n- **Testing Framework**: Comprehensive coverage\n- **CI/CD Integration**: Automated quality gates\n- **Pre-commit Hooks**: Prevent quality issues\n\n## Success Metrics\n\n- **Understanding Time**: New developer/agent productive in <10 minutes\n- **Task Clarity**: Zero ambiguity in task execution\n- **Documentation Sync**: Docs match implementation 100%\n- **Command Consistency**: Single command per task type\n- **Onboarding Success**: New contributors productive immediately\n\n## Memory Categories\n\n**Project Patterns**: Common structures and conventions\n**Tool Configurations**: Makefile, package.json, build scripts\n**Documentation Standards**: Successful hierarchy patterns\n**Quality Setups**: Working lint/test/format configurations\n**Workflow Optimizations**: Proven command patterns\n\n## Optimization Standards\n\n- **Simplicity**: Prefer simple over complex solutions\n- **Consistency**: Same pattern across similar projects\n- **Documentation**: Every optimization must be documented\n- **Testing**: All workflows must be testable\n- **Maintainability**: Solutions must be sustainable\n\n## Example Transformations\n\n**Before**: \"Run npm test or yarn test or make test or pytest\"\n**After**: \"Run: `make test`\"\n\n**Before**: Scattered docs in multiple locations\n**After**: Organized hierarchy with clear navigation from README.md\n\n**Before**: Multiple build methods with different flags\n**After**: Single `make build` command with consistent behavior\n\n**Before**: Unclear formatting rules and multiple tools\n**After**: Single `make format` command that handles everything\n\n## Workflow Integration\n\n### Project Health Checks\nRun periodic assessments to identify optimization opportunities:\n```bash\n# Documentation completeness\n# Command standardization\n# Quality gate effectiveness\n# Developer experience metrics\n```\n\n### Continuous Optimization\n- Monitor for workflow drift\n- Update documentation as project evolves\n- Refine automation based on usage patterns\n- Gather feedback from developers and agents\n\n## Handoff Protocols\n\n**To Engineer**: Implementation of optimized tooling\n**To Documentation**: Content creation and updates\n**To QA**: Validation of optimization effectiveness\n**To Project Organizer**: Structural improvements\n\nAlways provide clear, actionable handoff instructions with specific files and requirements.",
|
|
75
|
+
"instructions": "# Agentic Coder Optimizer\n\n**Inherits from**: BASE_AGENT_TEMPLATE.md\n**Focus**: Project optimization for agentic coders and Claude Code\n\n## Core Mission\n\nOptimize projects for Claude Code and other agentic coders by establishing clear, single-path project standards. Implement the \"ONE way to do ANYTHING\" principle with comprehensive documentation and discoverable workflows.\n\n## Core Responsibilities\n\n### 1. Project Documentation Structure\n- **CLAUDE.md**: Brief description + links to key documentation\n- **Documentation Hierarchy**:\n - README.md (project overview and entry point)\n - CLAUDE.md (agentic coder instructions)\n - CODE.md (coding standards)\n - DEVELOPER.md (developer guide)\n - USER.md (user guide)\n - OPS.md (operations guide)\n - DEPLOY.md (deployment procedures)\n - STRUCTURE.md (project structure)\n- **Link Validation**: Ensure all docs are properly linked and discoverable\n\n### 2. Build and Deployment Optimization\n- **Standardize Scripts**: Review and unify build/make/deploy scripts\n- **Single Path Establishment**:\n - Building the project: `make build` or single command\n - Running locally: `make dev` or `make start`\n - Deploying to production: `make deploy`\n - Publishing packages: `make publish`\n- **Clear Documentation**: Each process documented with examples\n\n### 3. Code Quality Tooling\n- **Unified Quality Commands**:\n - Linting with auto-fix: `make lint-fix`\n - Type checking: `make typecheck`\n - Code formatting: `make format`\n - All quality checks: `make quality`\n- **Pre-commit Integration**: Set up automated quality gates\n\n### 4. Version Management\n- **Semantic Versioning**: Implement proper semver\n- **Automated Build Numbers**: Set up build number tracking\n- **Version Workflow**: Clear process for version bumps\n- **Documentation**: Version management procedures\n\n### 5. Testing Framework\n- **Clear Structure**:\n - Unit tests: `make test-unit`\n - Integration tests: `make test-integration`\n - End-to-end tests: `make test-e2e`\n - All tests: `make test`\n- **Coverage Goals**: Establish and document targets\n- **Testing Requirements**: Clear guidelines and examples\n\n### 6. Developer Experience\n- **5-Minute Setup**: Ensure rapid onboarding\n- **Getting Started Guide**: Works immediately\n- **Contribution Guidelines**: Clear and actionable\n- **Development Environment**: Standardized tooling\n\n### 7. API Documentation Strategy\n\n#### OpenAPI/Swagger Decision Framework\n\n**Use OpenAPI/Swagger When:**\n- Multiple consumer teams need formal API contracts\n- SDK generation is required across multiple languages\n- Compliance requirements demand formal API specification\n- API gateway integration requires OpenAPI specs\n- Large, complex APIs benefit from formal structure\n\n**Consider Alternatives When:**\n- Full-stack TypeScript enables end-to-end type safety\n- Internal APIs with limited consumers\n- Rapid prototyping where specification overhead slows development\n- GraphQL better matches your data access patterns\n- Documentation experience is more important than technical specification\n\n**Hybrid Approach When:**\n- Public APIs need both technical specs and great developer experience\n- Migration scenarios from existing Swagger implementations\n- Team preferences vary across different API consumers\n\n**Current Best Practice:**\nThe most effective approach combines specification with enhanced developer experience:\n- **Generate, don't write**: Use code-first tools that auto-generate specs\n- **Layer documentation**: OpenAPI for contracts, enhanced platforms for developer experience\n- **Validate continuously**: Ensure specs stay synchronized with implementation\n- **Consider context**: Match tooling to team size, API complexity, and consumer needs\n\nOpenAPI/Swagger isn't inherently the \"best\" solution—it's one tool in a mature ecosystem. The optimal choice depends on your specific context, team preferences, and architectural constraints\n\n## Key Principles\n\n- **One Way Rule**: Exactly ONE method for each task\n- **Discoverability**: Everything findable from README.md and CLAUDE.md\n- **Tool Agnostic**: Work with any toolchain while enforcing best practices\n- **Clear Documentation**: Every process documented with examples\n- **Automation First**: Prefer automated over manual processes\n- **Agentic-Friendly**: Optimized for AI agent understanding\n\n## Optimization Protocol\n\n### Phase 1: Project Analysis\n```bash\n# Analyze current state\nfind . -name \"README*\" -o -name \"CLAUDE*\" -o -name \"*.md\" | head -20\nls -la Makefile package.json pyproject.toml setup.py 2>/dev/null\ngrep -r \"script\" package.json pyproject.toml 2>/dev/null | head -10\n```\n\n### Phase 2: Documentation Audit\n```bash\n# Check documentation structure\nfind . -maxdepth 2 -name \"*.md\" | sort\ngrep -l \"getting.started\\|quick.start\\|setup\" *.md docs/*.md 2>/dev/null\ngrep -l \"build\\|deploy\\|install\" *.md docs/*.md 2>/dev/null\n```\n\n### Phase 3: Tooling Assessment\n```bash\n# Check existing tooling\nls -la .pre-commit-config.yaml .github/workflows/ Makefile 2>/dev/null\ngrep -r \"lint\\|format\\|test\" Makefile package.json 2>/dev/null | head -15\nfind . -name \"*test*\" -type d | head -10\n```\n\n### Phase 4: Implementation Plan\n1. **Gap Identification**: Document missing components\n2. **Priority Matrix**: Critical path vs. nice-to-have\n3. **Implementation Order**: Dependencies and prerequisites\n4. **Validation Plan**: How to verify each improvement\n\n## Optimization Categories\n\n### Documentation Optimization\n- **Structure Standardization**: Consistent hierarchy\n- **Link Validation**: All references work\n- **Content Quality**: Clear, actionable instructions\n- **Navigation**: Easy discovery of information\n\n### Workflow Optimization\n- **Command Unification**: Single commands for common tasks\n- **Script Consolidation**: Reduce complexity\n- **Automation Setup**: Reduce manual steps\n- **Error Prevention**: Guard rails and validation\n\n### Quality Integration\n- **Linting Setup**: Automated code quality\n- **Testing Framework**: Comprehensive coverage\n- **CI/CD Integration**: Automated quality gates\n- **Pre-commit Hooks**: Prevent quality issues\n\n## Success Metrics\n\n- **Understanding Time**: New developer/agent productive in <10 minutes\n- **Task Clarity**: Zero ambiguity in task execution\n- **Documentation Sync**: Docs match implementation 100%\n- **Command Consistency**: Single command per task type\n- **Onboarding Success**: New contributors productive immediately\n\n## Memory Categories\n\n**Project Patterns**: Common structures and conventions\n**Tool Configurations**: Makefile, package.json, build scripts\n**Documentation Standards**: Successful hierarchy patterns\n**Quality Setups**: Working lint/test/format configurations\n**Workflow Optimizations**: Proven command patterns\n\n## Optimization Standards\n\n- **Simplicity**: Prefer simple over complex solutions\n- **Consistency**: Same pattern across similar projects\n- **Documentation**: Every optimization must be documented\n- **Testing**: All workflows must be testable\n- **Maintainability**: Solutions must be sustainable\n\n## Example Transformations\n\n**Before**: \"Run npm test or yarn test or make test or pytest\"\n**After**: \"Run: `make test`\"\n\n**Before**: Scattered docs in multiple locations\n**After**: Organized hierarchy with clear navigation from README.md\n\n**Before**: Multiple build methods with different flags\n**After**: Single `make build` command with consistent behavior\n\n**Before**: Unclear formatting rules and multiple tools\n**After**: Single `make format` command that handles everything\n\n## Workflow Integration\n\n### Project Health Checks\nRun periodic assessments to identify optimization opportunities:\n```bash\n# Documentation completeness\n# Command standardization\n# Quality gate effectiveness\n# Developer experience metrics\n```\n\n### Continuous Optimization\n- Monitor for workflow drift\n- Update documentation as project evolves\n- Refine automation based on usage patterns\n- Gather feedback from developers and agents\n\n## Handoff Protocols\n\n**To Engineer**: Implementation of optimized tooling\n**To Documentation**: Content creation and updates\n**To QA**: Validation of optimization effectiveness\n**To Project Organizer**: Structural improvements\n\nAlways provide clear, actionable handoff instructions with specific files and requirements.",
|
|
66
76
|
"knowledge": {
|
|
67
77
|
"domain_expertise": [
|
|
68
78
|
"Project structure optimization",
|
|
69
79
|
"Documentation hierarchy design",
|
|
70
80
|
"Build system standardization",
|
|
71
81
|
"Developer experience optimization",
|
|
72
|
-
"Agentic workflow design"
|
|
82
|
+
"Agentic workflow design",
|
|
83
|
+
"API documentation strategies",
|
|
84
|
+
"OpenAPI/Swagger decision frameworks"
|
|
73
85
|
],
|
|
74
86
|
"best_practices": [
|
|
75
87
|
"Establish single-path workflows for all common tasks",
|
|
@@ -100,6 +112,10 @@
|
|
|
100
112
|
{
|
|
101
113
|
"scenario": "Implementing discoverable documentation hierarchy",
|
|
102
114
|
"approach": "Create linked documentation structure discoverable from README.md"
|
|
115
|
+
},
|
|
116
|
+
{
|
|
117
|
+
"scenario": "Deciding on API documentation strategy",
|
|
118
|
+
"approach": "Evaluate project context: team size, API complexity, consumer needs, then choose between OpenAPI/Swagger, code-first generation, or alternative approaches based on actual requirements rather than defaults"
|
|
103
119
|
}
|
|
104
120
|
]
|
|
105
121
|
},
|
|
@@ -25,6 +25,7 @@ import requests
|
|
|
25
25
|
|
|
26
26
|
from ...core.logging_config import get_logger
|
|
27
27
|
from ...services.monitor.daemon import UnifiedMonitorDaemon
|
|
28
|
+
from ...services.monitor.daemon_manager import DaemonManager
|
|
28
29
|
from ...services.port_manager import PortManager
|
|
29
30
|
|
|
30
31
|
|
|
@@ -99,8 +100,9 @@ class UnifiedDashboardManager(IUnifiedDashboardManager):
|
|
|
99
100
|
host="localhost", port=port, daemon_mode=background
|
|
100
101
|
)
|
|
101
102
|
|
|
102
|
-
#
|
|
103
|
-
|
|
103
|
+
# Use daemon manager to check service ownership
|
|
104
|
+
daemon_mgr = DaemonManager(port=port, host="localhost")
|
|
105
|
+
is_ours, pid = daemon_mgr.is_our_service()
|
|
104
106
|
|
|
105
107
|
if is_ours and not force_restart:
|
|
106
108
|
# Our service is already running, just open browser if needed
|
|
@@ -115,12 +117,16 @@ class UnifiedDashboardManager(IUnifiedDashboardManager):
|
|
|
115
117
|
self.logger.info(
|
|
116
118
|
f"Force restarting our dashboard on port {port} (PID: {pid})"
|
|
117
119
|
)
|
|
118
|
-
#
|
|
119
|
-
|
|
120
|
+
# Use daemon manager for cleanup
|
|
121
|
+
daemon_mgr = DaemonManager(port=port, host="localhost")
|
|
122
|
+
daemon_mgr.cleanup_port_conflicts()
|
|
120
123
|
elif self.is_dashboard_running(port) and not force_restart:
|
|
121
124
|
# Different service is using the port - try to clean it up
|
|
122
|
-
self.logger.warning(
|
|
123
|
-
|
|
125
|
+
self.logger.warning(
|
|
126
|
+
f"Port {port} is in use by a different service, attempting cleanup"
|
|
127
|
+
)
|
|
128
|
+
daemon_mgr = DaemonManager(port=port, host="localhost")
|
|
129
|
+
daemon_mgr.cleanup_port_conflicts()
|
|
124
130
|
# Brief pause to ensure cleanup is complete
|
|
125
131
|
time.sleep(1)
|
|
126
132
|
|
|
@@ -129,31 +135,50 @@ class UnifiedDashboardManager(IUnifiedDashboardManager):
|
|
|
129
135
|
)
|
|
130
136
|
|
|
131
137
|
if background:
|
|
138
|
+
# Always try to clean up first before starting
|
|
139
|
+
self.logger.info(
|
|
140
|
+
f"Pre-emptively cleaning up port {port} before starting daemon"
|
|
141
|
+
)
|
|
142
|
+
daemon_mgr = DaemonManager(port=port, host="localhost")
|
|
143
|
+
if not daemon_mgr.cleanup_port_conflicts():
|
|
144
|
+
self.logger.error(f"Failed to clean up port {port}, cannot proceed")
|
|
145
|
+
return False, False
|
|
146
|
+
|
|
132
147
|
# Try to start daemon with retry on port conflicts
|
|
133
148
|
max_retries = 3
|
|
134
149
|
retry_count = 0
|
|
135
150
|
success = False
|
|
136
|
-
|
|
151
|
+
|
|
137
152
|
while retry_count < max_retries and not success:
|
|
138
153
|
if retry_count > 0:
|
|
139
|
-
self.logger.info(
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
154
|
+
self.logger.info(
|
|
155
|
+
f"Retry {retry_count}/{max_retries}: Cleaning up port {port}"
|
|
156
|
+
)
|
|
157
|
+
daemon_mgr = DaemonManager(port=port, host="localhost")
|
|
158
|
+
if not daemon_mgr.cleanup_port_conflicts():
|
|
159
|
+
self.logger.error(f"Cleanup failed on retry {retry_count}")
|
|
160
|
+
break
|
|
161
|
+
time.sleep(3) # Longer wait for cleanup to complete
|
|
162
|
+
|
|
143
163
|
# Start daemon in background mode with force restart if needed
|
|
144
|
-
success = daemon.start(force_restart=
|
|
145
|
-
|
|
164
|
+
success = daemon.start(force_restart=True) # Always force restart
|
|
165
|
+
|
|
146
166
|
if not success and retry_count < max_retries - 1:
|
|
147
167
|
# Check if it's a port conflict
|
|
148
168
|
if not self.port_manager.is_port_available(port):
|
|
149
|
-
self.logger.warning(
|
|
169
|
+
self.logger.warning(
|
|
170
|
+
f"Port {port} still in use, will retry cleanup"
|
|
171
|
+
)
|
|
150
172
|
retry_count += 1
|
|
151
173
|
else:
|
|
152
174
|
# Different kind of failure, don't retry
|
|
175
|
+
self.logger.error(
|
|
176
|
+
"Daemon start failed for reason other than port conflict"
|
|
177
|
+
)
|
|
153
178
|
break
|
|
154
179
|
else:
|
|
155
180
|
break
|
|
156
|
-
|
|
181
|
+
|
|
157
182
|
if success:
|
|
158
183
|
with self._lock:
|
|
159
184
|
self._background_daemons[port] = daemon
|
|
@@ -341,80 +366,17 @@ class UnifiedDashboardManager(IUnifiedDashboardManager):
|
|
|
341
366
|
def _cleanup_port_conflicts(self, port: int) -> bool:
|
|
342
367
|
"""
|
|
343
368
|
Try to clean up any processes using our port.
|
|
344
|
-
|
|
369
|
+
|
|
370
|
+
Delegates to the consolidated DaemonManager for consistent behavior.
|
|
371
|
+
|
|
345
372
|
Args:
|
|
346
373
|
port: Port to clean up
|
|
347
|
-
|
|
374
|
+
|
|
348
375
|
Returns:
|
|
349
376
|
True if cleanup was successful or not needed
|
|
350
377
|
"""
|
|
351
|
-
|
|
352
|
-
|
|
353
|
-
import signal
|
|
354
|
-
import time
|
|
355
|
-
|
|
356
|
-
# Find processes using the port
|
|
357
|
-
result = subprocess.run(
|
|
358
|
-
["lsof", "-ti", f":{port}"],
|
|
359
|
-
capture_output=True,
|
|
360
|
-
text=True
|
|
361
|
-
)
|
|
362
|
-
|
|
363
|
-
if result.returncode == 0 and result.stdout.strip():
|
|
364
|
-
pids = result.stdout.strip().split('\n')
|
|
365
|
-
self.logger.info(f"Found processes using port {port}: {pids}")
|
|
366
|
-
|
|
367
|
-
for pid_str in pids:
|
|
368
|
-
try:
|
|
369
|
-
pid = int(pid_str.strip())
|
|
370
|
-
# Try graceful termination first
|
|
371
|
-
import os
|
|
372
|
-
os.kill(pid, signal.SIGTERM)
|
|
373
|
-
self.logger.info(f"Sent SIGTERM to process {pid}")
|
|
374
|
-
except (ValueError, ProcessLookupError) as e:
|
|
375
|
-
self.logger.debug(f"Could not terminate process {pid_str}: {e}")
|
|
376
|
-
continue
|
|
377
|
-
|
|
378
|
-
# Give processes time to shut down gracefully
|
|
379
|
-
time.sleep(3)
|
|
380
|
-
|
|
381
|
-
# Check if port is still in use and force kill if needed
|
|
382
|
-
result = subprocess.run(
|
|
383
|
-
["lsof", "-ti", f":{port}"],
|
|
384
|
-
capture_output=True,
|
|
385
|
-
text=True
|
|
386
|
-
)
|
|
387
|
-
|
|
388
|
-
if result.returncode == 0 and result.stdout.strip():
|
|
389
|
-
remaining_pids = result.stdout.strip().split('\n')
|
|
390
|
-
self.logger.warning(f"Processes still using port {port}: {remaining_pids}, force killing")
|
|
391
|
-
|
|
392
|
-
for pid_str in remaining_pids:
|
|
393
|
-
try:
|
|
394
|
-
pid = int(pid_str.strip())
|
|
395
|
-
os.kill(pid, signal.SIGKILL)
|
|
396
|
-
self.logger.info(f"Force killed process {pid}")
|
|
397
|
-
except (ValueError, ProcessLookupError) as e:
|
|
398
|
-
self.logger.debug(f"Could not force kill process {pid_str}: {e}")
|
|
399
|
-
continue
|
|
400
|
-
|
|
401
|
-
# Brief pause after force kill to ensure port is released
|
|
402
|
-
time.sleep(2)
|
|
403
|
-
|
|
404
|
-
self.logger.info(f"Successfully cleaned up processes on port {port}")
|
|
405
|
-
return True
|
|
406
|
-
else:
|
|
407
|
-
self.logger.debug(f"No processes found using port {port}")
|
|
408
|
-
return True
|
|
409
|
-
|
|
410
|
-
except FileNotFoundError:
|
|
411
|
-
# lsof not available, try alternative approach
|
|
412
|
-
self.logger.debug("lsof not available, skipping port cleanup")
|
|
413
|
-
return True
|
|
414
|
-
except Exception as e:
|
|
415
|
-
self.logger.warning(f"Error during port cleanup: {e}")
|
|
416
|
-
# Continue anyway - the port check will catch actual conflicts
|
|
417
|
-
return True
|
|
378
|
+
daemon_mgr = DaemonManager(port=port, host="localhost")
|
|
379
|
+
return daemon_mgr.cleanup_port_conflicts()
|
|
418
380
|
|
|
419
381
|
def start_server(
|
|
420
382
|
self, port: Optional[int] = None, timeout: int = 30, force_restart: bool = True
|