# External Baseline Applicability Review Date: 2026-05-14 ## Scope Review recent external baseline issues and local engineering standards to decide what should be adopted by Open Orchestra. Sources reviewed: - Open Orchestra issue #317 - External baseline issues #198-#211, with emphasis on #211, #209, #208, #205, #204, #203, #202, #201, #200, #199, #198 - Local developer profile and generated Developer standards from the external baseline - Open Orchestra external artifact import bridge and standards rules ## Applies Directly ### Visual Post-Write Validation Source: external baseline #211 and Open Orchestra #317. This applies directly. Open Orchestra is the orchestrator and should own the generic gate contract: - external visual write manifest from agents or MCP integrations - export/snapshot evidence - fresh fetch of target state - duplicate, overlap, fallback-text, orphan, and bounds assertions - remediation loop where safe - blocking gate when non-remediable defects remain The Lucid-specific assertions belong in adapters or skills, but the gate type, evidence attachment, and workflow blocking behavior belong in Open Orchestra. ### External Import Role Mapping Open Orchestra currently imports role aliases from external artifact payloads. Core Open Orchestra roles are `product_owner` and `product_manager`. Imported tasks should map aliases to canonical role IDs. This is a bug-sized Open Orchestra fix. ### Workflow Benchmark Feedback Into Estimates Source: external baseline #205. Open Orchestra already has estimates and benchmark concepts. Historical calibration belongs in Open Orchestra so every stack benefits. The useful contract is: - estimates read completed run benchmark data when available - output includes historical median and variance - warning when historical estimates deviate materially - `--ignore-history` bypass - JSON output exposes calibration fields ### Playbook Scaffolding And Playbook Authoring Docs Sources: external baseline #204 and #201. Open Orchestra has phase playbooks and task-scoped workflow rendering. A scaffold command would reduce friction for teams adapting phases by stack without reading source. This applies cross-stack. ### Gate vs Clarify Documentation Source: external baseline #202. Open Orchestra exposes gates, reviews, decisions, and clarification patterns. The distinction should be documented in Open Orchestra user docs and runtime bootstrap copy because agents otherwise use phase gates for mid-phase questions. ### Workflow Phase Matrix / End-to-End Workflow Narrative Sources: external baseline #200 and #199. Open Orchestra should document its PM -> PO -> Architect -> Developer -> QA -> Release sequence, gates, evidence, review checkpoints, and what is autonomous versus human-approved. This is product documentation. ### Rules Health / Generated Guidance Freshness Source: external baseline #203. Open Orchestra already generates bootstrap and managed instruction blocks. A health surface that reports stale generated guidance, missing playbooks, and workflow readiness would apply directly. ## Applies As A Pattern, Not Literally ### Specialized Metadata CI/CD Source: external baseline #209. Product-specific metadata details do not belong in Open Orchestra core, but the pattern does: - deployment lanes are not always one generic deploy command - some artifacts require publish/activate flows - generated or managed artifacts may need ignore rules - dependency prechecks should run before deploy Open Orchestra should represent this as stack-specific release lanes or release playbook checks, not as product-specific deployment logic. ### Auto-Run Local Rule Generation After Init Source: external baseline #208. The applicable concept is first-run completeness: after `orchestra init`, users should exit with usable runtime instructions, workflow files, and a clear next command without a hidden second step. ## Developer Standards To Generalize Several reviewed Developer standards are product-specific, but the underlying rules are stack-agnostic and should remain or be strengthened in Open Orchestra: - Read project metadata/config before generating code. - Infer naming and layering from existing code. - Default to least privilege / safe execution context. - Never query or mutate data inside loops; batch or bulk operations. - Keep entry points thin; delegate business logic to services/handlers. - Scan for existing exception/logging patterns before adding new ones. - Prefer existing data access patterns over inventing a new repository/selector. - Handle 1..N records/requests, not only the happy-path singleton. - Use centralized test data builders/factories. - Include async tests that flush queued work. - Use user/permission-specific test contexts for authorization-sensitive logic. - Avoid fixed async patterns; choose queues, jobs, events, or schedulers based on ordering, retry, observability, and failure semantics. - Use named external integrations/configured clients; never hardcode endpoints, tokens, credentials, or command strings. - Validate response status before processing external responses. - Keep user-facing strings configurable/localizable where the product needs it. - Run static analysis before handoff. - Deploy/validate the changed production artifact before relying on tests that exercise it. - Every sub-agent handoff should include project conventions, data access strategy, test strategy, and known constraints. These already overlap with current Open Orchestra rules. The main gap is making some of them more explicit for Java, .NET, TypeScript, and Python examples without carrying product-specific terminology into stack-agnostic docs. Adopted in Open Orchestra via `rules/development-engineering.mdc`, with examples for Java/Spring, .NET, TypeScript/Node, and Python. ## Does Not Apply To Core - Product-specific publish or activation commands. - Product-specific generated metadata folders. - Product-specific UI implementation rules. - Product-specific server-side naming and permission idioms as literal rules. These belong in product-specific profiles, not Open Orchestra core. ## Recommended Open Orchestra Backlog 1. Implement visual validation gate contract and evidence attachment. 2. Fix external import role aliases to canonical Open Orchestra roles. 3. Add benchmark-calibrated estimates. 4. Add playbook scaffold command and authoring docs. 5. Add Gate vs Clarify docs and workflow phase matrix. 6. Add rules/playbook health to `orchestra health` or a dedicated status view. 7. Add stack-agnostic Developer standards examples for Java, .NET, TypeScript, and Python.