Commit Graph

10 Commits

Author SHA1 Message Date
Jason Woltje
12abdfe81d feat(#93): implement agent spawn via federation
Implements FED-010: Agent Spawn via Federation feature that enables
spawning and managing Claude agents on remote federated Mosaic Stack
instances via COMMAND message type.

Features:
- Federation agent command types (spawn, status, kill)
- FederationAgentService for handling agent operations
- Integration with orchestrator's agent spawner/lifecycle services
- API endpoints for spawning, querying status, and killing agents
- Full command routing through federation COMMAND infrastructure
- Comprehensive test coverage (12/12 tests passing)

Architecture:
- Hub → Spoke: Spawn agents on remote instances
- Command flow: FederationController → FederationAgentService →
  CommandService → Remote Orchestrator
- Response handling: Remote orchestrator returns agent status/results
- Security: Connection validation, signature verification

Files created:
- apps/api/src/federation/types/federation-agent.types.ts
- apps/api/src/federation/federation-agent.service.ts
- apps/api/src/federation/federation-agent.service.spec.ts

Files modified:
- apps/api/src/federation/command.service.ts (agent command routing)
- apps/api/src/federation/federation.controller.ts (agent endpoints)
- apps/api/src/federation/federation.module.ts (service registration)
- apps/orchestrator/src/api/agents/agents.controller.ts (status endpoint)
- apps/orchestrator/src/api/agents/agents.module.ts (lifecycle integration)

Testing:
- 12/12 tests passing for FederationAgentService
- All command service tests passing
- TypeScript compilation successful
- Linting passed

Refs #93

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-02-03 14:37:06 -06:00
8f63b3e1dc docs: Add Mosaic Component Architecture and Guard Rails design docs
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
- mosaic-component-architecture.md: OpenClaw wrapper pattern, component naming,
  job tracking, chat integration, database schema
- guard-rails-capability-permissions.md: Capability-based permission model

Related: #162 (M4.2 Infrastructure Epic)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 01:26:01 -06:00
8c8d065cc2 feat(arch): Add Guard Rails capability-based permission system design
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
Guard Rails complement Quality Rails by controlling what agents can do:
- Capability-based permissions (resource:action pattern)
- Read/organize/draft allowed by default
- Execute/admin require explicit grants
- Human-in-the-loop approval for sensitive actions

Examples: email (read/draft , send ), git (commit , force push )

Also:
- Add .admin-credentials and .env.bak.* to .gitignore

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 00:25:53 -06:00
0eb3abc12c Clean up documents located in the project root.
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
2026-01-31 16:42:26 -06:00
403aba4cd3 docs: Add issue parser estimation strategy
Critical enhancement for real-world usage - parser must handle:
- Unformatted issues (estimate from content)
- Incomplete metadata (best-guess + confidence score)
- Oversized issues (auto-decompose before queuing)

Three-level estimation:
1. Structured metadata → extract directly (95%+ confidence)
2. Content analysis → AI estimates from description (50-95%)
3. Minimal info → defaults + warn user (<50%)

50% rule enforcement:
- Detect issues > 50% of agent's context limit
- Auto-decompose into sub-issues using Opus
- Create sub-issues in Gitea with dependencies
- Label parent as EPIC

Confidence-based workflow:
- ≥60%: Queue automatically
- 30-59%: Queue with warning
- <30%: Don't queue, request more details

Makes coordinator truly autonomous - handles whatever users throw at it.

Refs #158 (COORD-002)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-31 15:40:34 -06:00
3be60ccd18 docs: Add assignment-based trigger architecture
Implements Phase 0 foundation for non-AI coordinator.

Key features:
- User assigns issue to @mosaic bot user → triggers webhook
- Webhook receiver processes assignment events
- AI agent parses issue metadata (context, difficulty, agent)
- Queue manager tracks dependencies and status
- Orchestration loop spawns agents and monitors progress

Benefits:
- Natural Gitea workflow (just assign issues)
- Visual feedback in Gitea UI
- Granular control (assign what you want)
- Event-driven (webhooks, not polling)
- No CLI needed

Phase 0 issues: #156-161 (6 issues, 290.6K tokens)

Refs #142

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-31 15:30:21 -06:00
903109ea40 docs: Add overlap analysis for non-AI coordinator patterns
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
Detailed comparison showing:
- Existing doc addresses L-015 (premature completion)
- New doc addresses context exhaustion (multi-issue orchestration)
- ~20% overlap (both use non-AI coordinator, mechanical gates)
- 80% complementary (different problems, different solutions)

Recommends merging into comprehensive document (already done).

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-31 14:47:59 -06:00
a2f06fe75b docs: Add comprehensive non-AI coordinator architecture
Merges two complementary architectural patterns:
1. Quality Enforcement Layer - Prevents premature agent completion
2. Orchestration Layer - Manages multi-agent context and assignment

Key features:
- 50% rule for issue sizing
- Agent profiles and cost optimization
- Context monitoring (compact at 80%, rotate at 95%)
- Mechanical quality gates (build, lint, test, coverage)
- Forced continuation when gates fail
- 4-week PoC plan

Addresses issue #140 and L-015 (Agent Premature Completion)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-31 14:47:09 -06:00
Jason Woltje
b64c5dae42 docs: Add Non-AI Coordinator Pattern architecture specification
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
Comprehensive architecture document for M4 quality enforcement pattern.

Problem (L-015 Evidence):
- AI agents claim done prematurely (60-70% complete)
- Defer work as "incremental" or "follow-up PRs"
- Identical language across sessions ("good enough for now")
- Happens even in YOLO mode with full permissions
- Cannot be fixed with instructions or prompting

Evidence:
- uConnect agent: 853 warnings deferred
- Mosaic Stack agent: 509 lint errors + 73 test failures deferred
- Both required manual override to continue
- Pattern observed across multiple agents and sessions

Solution: Non-AI Coordinator Pattern
- AI agents do the work
- Non-AI orchestrator enforces quality gates
- Gates are programmatic (build, lint, test, coverage)
- Agents cannot negotiate or bypass
- Forced continuation when gates fail
- Rejection with specific failure messages

Documentation Includes:
- Problem statement with evidence
- Why non-AI enforcement is necessary
- Complete architecture design
- Component specifications
- Quality gate types and configuration
- State machine and workflow
- Forced continuation prompt templates
- Integration points
- Monitoring and metrics
- Troubleshooting guide
- Implementation examples

Related Issues: #134-141 (M4-MoltBot)

Agents working on M4 issues now have complete context
and rationale without needing jarvis-brain access.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-30 17:47:26 -06:00
Jason Woltje
dd5b3117a7 docs: Restructure documentation with Bookstack-compatible hierarchy
- Organized docs into numbered shelf/book/chapter/page structure
- Created comprehensive README.md with project overview
- Added Getting Started book (quick start, installation, configuration)
- Added Development book (workflow, testing, type sharing)
- Added Architecture book (design principles, PDA-friendly patterns)
- Added API Reference book (conventions, authentication)
- Moved TYPE-SHARING.md to proper location
- Updated all cross-references in main README
- Created docs/README.md as master index
- Removed old QA automation reports
- Removed deprecated SETUP.md (content split into new structure)

Documentation structure follows Bookstack best practices:
- Numbered books: 1-getting-started, 2-development, 3-architecture, 4-api
- Numbered chapters and pages for ordering
- Clear hierarchy and navigation
- Cross-referenced throughout

Complete documentation available at: docs/README.md

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-28 17:46:33 -06:00