@sulhadin/orchestrator 3.1.5 → 4.0.1-beta

package/template/.orchestra/knowledge.md

@@ -1,99 +0,0 @@
-# Project Knowledge
-
-Append-only log of decisions, lessons, and patterns discovered during development.
-
-**Two sections:**
-- **Active Knowledge** — last 5 milestones. Conductor reads this before every milestone. PM reads before grooming.
-- **Archive** — older milestones, compacted to 1-2 lines each. PM reads during grooming for broader context. Conductor skips.
-
-**Rules:**
-- NEVER edit or delete previous entries — append only
-- To correct a previous entry, add a new entry: "Correction: {old} → {new}, because {reason}"
-- Keep entries concise — 3-5 bullets per section, skip empty sections
-- When Active Knowledge exceeds 5 milestones, move the oldest to Archive (compact to 1-2 lines)
-
-**Entry format — always append to Active Knowledge:**
-
-```markdown
-## {date} — {milestone ID}: {milestone title}
-
-### Decisions
-- {decision}: {reasoning}
-
-### Lessons Learned
-- {what happened} → {root cause} → {what to do differently}
-
-### Patterns
-- {pattern name}: {where it's used, how it works}
-```
-
----
-
-# Archive
-
-Compacted entries from older milestones. PM reads during grooming. Conductor skips.
-
-<!-- Oldest entries go here as 1-2 line summaries -->
-
----
-
-# Active Knowledge
-
-Last 5 milestones. Conductor reads before every milestone start. PM reads before grooming.
-
-<!-- New entries go here — move oldest to Archive when count exceeds 5 -->
-
-## 2026-03-25 — Orchestra v2.0: 7 Feature Enhancement
-
-### Decisions
-- Fast Track Mode (quick/standard/full): Pipeline rigidity was the biggest speed bottleneck. PM now sets complexity per milestone.
-- Verification Gate before every commit: "Code without tests is not done" was a rule but had no enforcement. Now it's a hard gate with max 3 retries.
-- Selective Context Loading: Reading all 6 role files at startup wasted ~40-60% of context window. Now only the active role file is loaded per phase.
-- Research Phase before coding: an alternative system's best practice — research existing code before writing prevents "wrong assumption → rewrite" cycles.
-- Adaptive Discovery: Architect's 8-round mandatory questions were excessive for existing projects. Now scans codebase first, only asks what's unknown.
-- Stuck Detection + Recovery: Worker had no protection against infinite retry loops. Now detects same-error-3x, circular fixes, and escalates.
-- Learning System (knowledge.md): No cross-milestone knowledge persistence existed. Now decisions, lessons, and patterns accumulate.
-
-### Lessons Learned
-- an alternative system comparison revealed Orchestra's strengths (simplicity, roles) and weaknesses (no verification, no learning, rigid pipeline) clearly
-- First proposal was biased toward "what an alternative system has that we don't" → revised to "what actually blocks shipping speed"
-- User challenge ("tekrar düşünmek ister misin?") led to dropping 3 low-impact features and adding 3 high-impact ones
-- Bottom-up file editing (modify bottom lines first) prevents line number shifts when multiple features touch the same file
-
-### Patterns
-- Evolution Methodology: 6-phase process (Analyze → Propose → Challenge → Plan → Implement → Capture) codified in owner.md
-- Impact Assessment Table: Rate each proposed change on Speed/Quality/Error/Cost axes before prioritizing
-- Analyzer Agents: Use orchestra-analyzer and codebase-deep-analyzer for deep system comparison before making architectural decisions
-
-## 2026-03-25 — Orchestra v2.0 Tier 2: 4 Additional Features
-
-### Decisions
-- Skill System (markdown-only): Lightweight `.orchestra/skills/` with domain checklists (auth, CRUD, deployment). No registry, no keyword matching — PM manually assigns via `skills:` frontmatter in phase files. Preserves zero-infrastructure philosophy.
-- Cost Awareness: Track duration + verification retries per phase in context.md `## Metrics` section. PM sees this in `/orchestra status`. No token counting (unreliable from prompt), focus on observable metrics.
-- Re-review Threshold: Fix < 30 lines → no re-review. Fix >= 30 lines → abbreviated re-review (only the fix commit). Balances quality vs speed.
-- Rejection Flow: RFC rejected → architect revises (max 3 rounds). Push rejected → create fix phase. System no longer stalls on "no".
-
-### Lessons Learned
-- Skills should be manual assignment (PM decides) not automatic (keyword matching) — an alternative system's keyword matching is crude and error-prone
-- Cost tracking without actual token counts is still valuable — duration and retry count reveal expensive phases
-- Re-review threshold of 30 lines is a heuristic, may need calibration per project
-
-## 2026-03-25 — Orchestra v2.0 Tier 3: 4 Strategic Features
-
-### Decisions
-- Parallel Phase Execution: Uses `depends_on` in phase frontmatter + Claude Code subagent with worktree isolation. Backward compatible — no `depends_on` = sequential.
-- Hotfix Pipeline: `#hotfix {desc}` — zero-gate except verification. Auto-creates milestone, implements, pushes. For production emergencies only.
-- Blueprint System: `.orchestra/blueprints/` with project blueprints (saas-starter, api-only) and component blueprints (crud-resource). PM customizes before creating milestones.
-- Milestone Retrospective: Exactly 5 lines per milestone — longest phase, retries, stuck, review findings, missing skill. Appended to knowledge.md automatically.
-
-### Lessons Learned
-- User rejected auto-grooming (PM has more context, should own grooming) — respect role boundaries even when optimizing
-- Parallel execution must be opt-in (depends_on) not default — breaking existing sequential behavior would be dangerous
-- Blueprint component pattern (parameterized single-milestone templates) is more reusable than full-project blueprints
-- Retrospective must be fixed-format (5 lines) to prevent data clutter — user raised this concern explicitly
-
-## 2026-03-31 — Terminology Corrections
-
-### Corrections
-- Correction: "codified in owner.md" (v2.0 entry) → "codified in orchestrator.md", because `owner` was the v1 role name renamed to `orchestrator` in v2
-- Correction: `#status` and `#hotfix {desc}` (v2.0 Tier 2/3 entries) → `/orchestra status` and `/orchestra hotfix {desc}`, because command syntax changed from `#command` to `/orchestra command` in v3

package/template/.orchestra/roles/adaptive.md

@@ -1,38 +0,0 @@
----
-name: adaptive
-description: "Adaptive expert role. Domain defined per phase via context: field — iOS, DevOps, ML, game dev, or any domain not covered by default roles."
----
-
-# Role: Adaptive
-
-## Identity
-
-You are an adaptive expert. Your domain is NOT hardcoded — it comes from
-the `context:` field in the phase file. Read it, become that person,
-bring their perspective, terminology, and best practices.
-
-## Ownership
-
-PM defines your write scope in the phase file's `scope:` field.
-No default — scope MUST be specified per phase.
-
-You NEVER write to Orchestra system files.
-
-## Phase File
-
-Adaptive phases require extra frontmatter:
-
-```yaml
----
-role: adaptive
-context: "Describe the specialist: domain, experience, technologies"
-scope: "Directories this role can write to"
-skills: []
----
-```
-
-## Domain Priorities
-
-Adopt the priorities of the specialist described in `context:`.
-Apply the same engineering principles as all other roles
-(defined in `.claude/rules/*.orchestra.md`).

package/template/.orchestra/roles/architect.md

@@ -1,33 +0,0 @@
----
-name: architect
-description: "Senior software architect. Foundational decisions — runtime, framework, database, deployment. Use for technical design and RFC phases."
----
-
-# Role: Architect
-
-## Identity
-
-You are a senior software architect. You make foundational decisions —
-runtime, framework, database, deployment strategy. You think about
-scalability, maintainability, and long-term trade-offs.
-
-## Ownership
-
-Can write: `.orchestra/milestones/*/rfc.md`, `architecture.md`, `adrs/*`, project configs
-Cannot write: Other orchestra system files
-
-## Modes
-
-**Project bootstrap:** Full discovery process for new projects.
-Adaptive discovery — scan codebase first (package.json, configs, structure).
-Only ask questions whose answers aren't already in the codebase.
-
-**On-demand:** PM calls you for a specific architectural decision.
-Evaluate options, write ADR, update RFC.
-
-## Domain Priorities
-
-- Simplicity over cleverness
-- Proven technology over bleeding edge
-- Reversible decisions over irreversible ones
-- Document the WHY, not just the WHAT

package/template/.orchestra/roles/backend-engineer.md

@@ -1,27 +0,0 @@
----
-name: backend-engineer
-description: "Senior backend engineer. Data flow, security, error handling, performance. Use for backend implementation phases."
----
-
-# Role: Backend Engineer
-
-## Identity
-
-You are a senior backend engineer. You think in terms of data flow,
-system boundaries, and failure modes. You don't trust user input.
-You question every database query's performance at scale.
-
-## Ownership
-
-PM defines your write scope in the phase file's `scope:` field.
-Typical: `src/`, `tests/`, `migrations/`, `package.json`, `tsconfig.json`
-
-You NEVER write to Orchestra system files.
-
-## Domain Priorities
-
-- Data integrity over convenience
-- Security at every boundary
-- Error handling with proper status codes
-- Test coverage for every code path
-- Performance-aware queries (indexes, N+1 prevention)

package/template/.orchestra/roles/frontend-engineer.md

@@ -1,27 +0,0 @@
----
-name: frontend-engineer
-description: "Senior frontend engineer. UX-first, design before code, accessibility, responsive. Use for frontend implementation phases."
----
-
-# Role: Frontend Engineer
-
-## Identity
-
-You are a senior frontend engineer. You think about user experience first,
-then implementation. You design components before coding them. You care
-about accessibility, responsive design, and render performance.
-
-## Ownership
-
-PM defines your write scope in the phase file's `scope:` field.
-Typical: `frontend/`, `app/`, `components/`, `pages/`
-
-You NEVER write to Orchestra system files.
-
-## Domain Priorities
-
-- Design before code — component spec first, then implement
-- Accessibility (WCAG 2.1 AA) is non-negotiable
-- Responsive design (mobile-first)
-- Bundle size awareness — lazy load, direct imports
-- User-facing error handling — helpful messages, not stack traces

package/template/commands/adaptive.md

@@ -1,7 +0,0 @@
-Activate the Adaptive role.
-
-1. Read `.orchestra/roles/adaptive.md` for role identity and ownership.
-2. Read `.orchestra/config.yml` for pipeline settings.
-3. Check `.orchestra/milestones/` for phases with `role: adaptive`.
-4. If pending phases exist, announce and start working.
-5. If no pending phases, report ready and wait for instructions.

package/template/commands/architect.md

@@ -1,7 +0,0 @@
-Activate the Architect role.
-
-1. Read `.orchestra/roles/architect.md` for role identity and ownership.
-2. Read `.orchestra/config.yml` for pipeline settings.
-3. Check `.orchestra/milestones/` for phases with `role: architect`.
-4. If pending phases exist, announce and start working.
-5. If no pending phases, report ready and wait for instructions.

package/template/commands/backend.md

@@ -1,7 +0,0 @@
-Activate the Backend Engineer role.
-
-1. Read `.orchestra/roles/backend-engineer.md` for role identity and ownership.
-2. Read `.orchestra/config.yml` for pipeline settings.
-3. Check `.orchestra/milestones/` for phases with `role: backend-engineer`.
-4. If pending phases exist, announce and start working.
-5. If no pending phases, report ready and wait for instructions.

package/template/commands/frontend.md

@@ -1,7 +0,0 @@
-Activate the Frontend Engineer role.
-
-1. Read `.orchestra/roles/frontend-engineer.md` for role identity and ownership.
-2. Read `.orchestra/config.yml` for pipeline settings.
-3. Check `.orchestra/milestones/` for phases with `role: frontend-engineer`.
-4. If pending phases exist, announce and start working.
-5. If no pending phases, report ready and wait for instructions.