Two Trivy fixes:
1. Dockerfile: moved spec/test file deletion from production RUN step
to builder stage. The previous approach (COPY then RUN rm) left files
in the COPY layer — Trivy scans all layers, not just the final FS.
Now spec files are deleted in builder BEFORE COPY to production.
2. .trivyignore: added 3 tar CVEs (CVE-2026-23745/23950/24842) with
documented rationale. tar@7.5.2 is bundled inside npm which ships
with node:20-alpine. Not upgradeable — not our dependency. npm is
already removed from all production images.
Verified: local Trivy scan passes (exit code 0, 0 findings)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add build-shared step to web.yml so lint/typecheck/test can resolve
@mosaic/shared types (same fix previously applied to api.yml)
- Remove compiled .spec.js/.test.js files from orchestrator production
image to prevent Trivy secret scanning false positives from test
fixtures (fake AWS keys and RSA private keys in secret-scanner tests)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- docker/postgres/Dockerfile: build gosu from source with Go 1.26 via
multi-stage build (eliminates 1 CRITICAL + 5 HIGH Go stdlib CVEs)
- apps/{api,web,orchestrator}/Dockerfile: remove npm from production
images (eliminates 5 HIGH CVEs in npm's bundled cross-spawn/glob/tar)
- .trivyignore: trimmed from 16 to 5 CVEs (OpenBao only — 4 false
positives from Go pseudo-version + 1 real Go stdlib waiting on upstream)
Fixes#363
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
All 16 suppressed CVEs are in upstream binaries/packages we don't control:
- Go stdlib CVEs in openbao bin/bao (Go 1.25.6) and postgres gosu (Go 1.24.6)
- OpenBao CVE false positives (Trivy reads Go pseudo-version, we run 2.5.0)
- npm bundled cross-spawn/glob/tar CVEs in node:20-alpine base image
Updated all 6 Trivy scan steps across 5 pipelines to use --ignorefile.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Create docker-compose.openbao.yml for standalone OpenBao deployment
- Includes openbao and openbao-init services
- Auto-initialization on first run
- Connects to swarm's mosaic_internal network
- Binds to localhost:8200 for security
- Update docker-compose.swarm.yml
- Comment out OpenBao service (cannot run in swarm)
- Add clear note about standalone requirement
- Update volumes section
- Update header with current config
- Create docs/OPENBAO-DEPLOYMENT.md
- Comprehensive deployment guide
- 4 deployment options: standalone, bundled, external, fallback
- Clear explanation why OpenBao can't run in swarm
- Deployment workflows for each scenario
- Troubleshooting section
- Update docs/SWARM-DEPLOYMENT.md
- Add Step 1: Deploy OpenBao standalone FIRST
- Remove manual initialization (now automatic)
- Update expected services list
- Reference OpenBao deployment guide
- Update README.md
- Clarify OpenBao standalone requirement for swarm
- Update deployment steps
- Highlight critical requirement at top of notes
Key changes:
- OpenBao MUST be deployed standalone when using swarm
- Automatic initialization via openbao-init sidecar
- Clear documentation for all deployment options
- Swarm stack no longer includes OpenBao
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Update docker-compose.swarm.yml with external Authentik configuration
- Comment out Authentik services (using external OIDC provider)
- Comment out Authentik volumes
- Add header with deployment instructions and current configuration
- Create comprehensive SWARM-DEPLOYMENT.md guide
- Prerequisites and swarm initialization
- Manual OpenBao initialization (critical - no auto-init in swarm)
- External service configuration examples
- Scaling, updates, rollbacks
- Troubleshooting and maintenance procedures
- Backup and restore instructions
- Update .env.swarm.example
- Add note about external vs internal Authentik
- Update default OIDC_ISSUER to use https
- Clarify which variables are needed for internal Authentik
- Update README.md Docker Swarm section
- Fix deploy script path (./scripts/deploy-swarm.sh)
- Add note about manual OpenBao initialization
- Add warning about no profile support in swarm
- Update documentation references to docs/ directory
- Update documentation cross-references
- Add deprecation notice to old DOCKER-SWARM.md
- Add deployment guide reference to SWARM-QUICKREF.md
- Update DOCKER-COMPOSE-GUIDE.md See Also section
Key changes for swarm deployment:
- Swarm does NOT support docker-compose profiles
- External services must be manually commented out
- OpenBao requires manual initialization (no sidecar)
- All documentation updated with correct paths
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add OpenBao services to docker-compose.yml with profiles (openbao, full)
- Add docker-compose.build.yml for local builds vs registry pulls
- Make PostgreSQL and Valkey optional via profiles (database, cache)
- Create example compose files for common deployment scenarios:
- docker/docker-compose.example.turnkey.yml (all bundled)
- docker/docker-compose.example.external.yml (all external)
- docker/docker.example.hybrid.yml (mixed deployment)
- Update documentation:
- Enhance .env.example with profiles and external service examples
- Update README.md with deployment mode quick starts
- Add deployment scenarios to docs/OPENBAO.md
- Create docker/DOCKER-COMPOSE-GUIDE.md with comprehensive guide
- Clean up repository structure:
- Move shell scripts to scripts/ directory
- Move documentation to docs/ directory
- Move docker compose examples to docker/ directory
- Configure for external Authentik with internal services:
- Comment out Authentik services (using external OIDC)
- Comment out unused volumes for disabled services
- Keep postgres, valkey, openbao as internal services
This provides a flexible deployment architecture supporting turnkey,
production (all external), and hybrid configurations via Docker Compose
profiles.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implemented transparent encryption/decryption of LLM provider API keys
stored in llm_provider_instances.config JSON field using OpenBao Transit
encryption.
Implementation:
- Created llm-encryption.middleware.ts with encryption/decryption logic
- Auto-detects format (vault:v1: vs plaintext) for backward compatibility
- Idempotent encryption prevents double-encryption
- Registered middleware in PrismaService
- Created data migration script for active encryption
- Added migrate:encrypt-llm-keys command to package.json
Tests:
- 14 comprehensive unit tests
- 90.76% code coverage (exceeds 85% requirement)
- Tests create, read, update, upsert operations
- Tests error handling and backward compatibility
Migration:
- Lazy migration: New keys encrypted, old keys work until re-saved
- Active migration: pnpm --filter @mosaic/api migrate:encrypt-llm-keys
- No schema changes required
- Zero downtime
Security:
- Uses TransitKey.LLM_CONFIG from OpenBao Transit
- Keys never touch disk in plaintext (in-memory only)
- Transparent to LlmManagerService and providers
- Follows proven pattern from account-encryption.middleware.ts
Files:
- apps/api/src/prisma/llm-encryption.middleware.ts (new)
- apps/api/src/prisma/llm-encryption.middleware.spec.ts (new)
- apps/api/scripts/encrypt-llm-keys.ts (new)
- apps/api/prisma/migrations/20260207_encrypt_llm_api_keys/ (new)
- apps/api/src/prisma/prisma.service.ts (modified)
- apps/api/package.json (modified)
Note: The migration script (encrypt-llm-keys.ts) is not included in
tsconfig.json to avoid rootDir conflicts. It's executed via tsx which
handles TypeScript directly.
Refs #359
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add sprint archival instructions so completed tasks.md files are
retained in docs/tasks/ for post-mortem reference. Includes recovery
behavior when an orchestrator finds no active tasks.md.
Archive M6-AgentOrchestration-Fixes: 88/90 done, 2 deferred.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Worker limits and other orchestrator settings will be configurable
via the Coordinator service with DB-centric storage.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The debounced search useEffect accessed `filters` and `onFilterChange`
without including them in the dependency array. Fixed by:
- Using useRef for onFilterChange to maintain a stable reference
- Using functional state update (setFilters callback) to access
previous filters without needing it as a dependency
This prevents stale closures while avoiding infinite re-render loops
that would occur if these values were added directly to the dep array.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Orchestrator was editing source code directly instead of spawning workers.
Added CRITICAL section making it explicit:
- Orchestrator NEVER edits source code
- Orchestrator NEVER runs quality gates
- Orchestrator ONLY manages tasks.md and spawns workers
- No "quick fixes" — spawn a worker instead
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Parsed remaining medium-severity findings into 12 tasks + verification.
Created docs/deferred-errors.md for MS-MED-006 (CSP) and MS-MED-008 (Valkey SSOT).
Created Gitea issue #347 for Phase 4.
Estimated total: 117K tokens.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Addresses threshold-satisficing behavior where agent declared success
at 91% and moved on. New protocol requires:
- Bulk Phase (90%): Fast progress on tractable errors
- Polish Phase (100%): Triage remaining into categories
- Phase Boundary Rule: Must complete Polish before proceeding
- Documentation: All deferrals documented with rationale
Transforms "78 errors acceptable" into traceable technical decisions.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
These temporary remediation report files are no longer needed after
completing the security remediation work.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
CRITICAL finding: Agents cannot trigger compaction
- "compact and continue" does NOT work
- Only user typing /compact in CLI works
- Auto-compact at ~95% is too late
Updated protocol:
- Stop at 55-60% context usage
- Output COMPACTION REQUIRED checkpoint
- Wait for user to run /compact and say "continue"
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
New package providing CLI tools that work with both Gitea and GitHub:
Commands:
- mosaic-issue-{create,list,view,assign,edit,close,reopen,comment}
- mosaic-pr-{create,list,view,merge,review,close}
- mosaic-milestone-{create,list,close}
Features:
- Auto-detects platform (Gitea vs GitHub) from git remote
- Unified interface regardless of platform
- Available via `pnpm exec mosaic-*` in monorepo context
Updated docs/claude/orchestrator.md:
- Added CLI Tools section with usage examples
- Updated issue creation to use package commands
This makes Mosaic Stack fully self-contained for orchestration tooling.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Update CLAUDE.md to point to universal orchestrator guide
- Add docs/tasks.md with 28 tasks across 4 phases:
- Phase 1: Critical Security (MS-SEC-001 to MS-SEC-010)
- Phase 2: High Security (MS-HIGH-001 to MS-HIGH-006)
- Phase 3: Code Quality (MS-CQ-001 to MS-CQ-007)
- Phase 4: Test Coverage (MS-TEST-001 to MS-TEST-005)
- Add project-specific task-tracking.md reference
Based on comprehensive codebase review (124 findings).
- Add GET /agents endpoint to orchestrator controller
- Update AgentStatusWidget to fetch from real API instead of mock data
- Add comprehensive tests for listAgents endpoint
- Auto-refresh agent list every 30 seconds
- Display agent status with proper icons and formatting
- Show error states when API is unavailable
Fixes#233
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Remove 661 outdated files:
- 634 QA automation reports from docs/reports/qa-automation/
- 27 old milestone completion and status tracking files
Preserved core documentation structure and active project reports.
