mirror of
https://github.com/merlinhu1/codex-game-studio.git
synced 2026-08-25 07:54:34 +02:00
feat: add bounded task orchestration
This commit is contained in:
MerlinH
@@ -22,7 +22,7 @@ This file mirrors the repository-specific agent rules from `AGENTS.md` in the co
|
||||
- `src/agents.ts` is the single owner for generated project `AGENTS.md`.
|
||||
- Direct Codex execution is the default path via `opengamestudio run <role>`.
|
||||
- `--dry-run` and `--print-prompt` are inspection-only paths.
|
||||
- Telemetry, planner/next, ownership enforcement, and parallel orchestration are future-only.
|
||||
- Explicit, file-backed task orchestration is now inside the product boundary; telemetry, planner/next, ownership enforcement, hosted orchestration, background loops, and unbounded parallelism remain future-only.
|
||||
- Read `docs/architecture/product-boundary.md` before creating or revising designs, implementation plans, OpenSpec changes, generated project surfaces, role/workflow expansions, approval/write-policy behavior, or runtime execution behavior.
|
||||
|
||||
## Truthmark Notes
|
||||
|
||||
@@ -173,7 +173,7 @@ flowchart TD
|
||||
|
||||
## Rationale
|
||||
|
||||
Separating inspection, implementation, verification, review, and fix branches makes the Codex lifecycle auditable without inventing hidden planner, telemetry, ownership enforcement, or parallel orchestration behavior.
|
||||
Separating inspection, implementation, verification, review, and fix branches makes the Codex lifecycle auditable without inventing hidden planner, telemetry, ownership enforcement, hosted/background orchestration, or unbounded parallel behavior.
|
||||
|
||||
## Truth Sources
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ flowchart TD
|
||||
- They do not call Codex.
|
||||
- They do not write `.codex/runs/` cache files.
|
||||
- They do not mutate `.codex/studio.json` or `.codex/tasks.json`.
|
||||
- They do not expose hidden planner, telemetry, ownership enforcement, or parallel orchestration behavior.
|
||||
- They do not expose hidden planner, telemetry, ownership enforcement, hosted/background orchestration, or unbounded parallel behavior. Explicit task orchestration belongs in task/run lifecycle commands, not render-only shortcut output.
|
||||
|
||||
## Failure Modes And Debugging Cues
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
status: active
|
||||
doc_type: architecture
|
||||
truth_kind: architecture
|
||||
last_reviewed: 2026-06-13
|
||||
last_reviewed: 2026-06-25
|
||||
source_of_truth:
|
||||
- ../../README.md
|
||||
- ../../AGENTS.md
|
||||
@@ -24,7 +24,7 @@ Open Game Studio helps developers use Codex as a practical game-development stud
|
||||
|
||||
The product should make it easier to start, plan, build, review, and ship games by providing a package-friendly TypeScript CLI that creates project scaffolds, renders bounded Codex prompts, manages game-studio roles and workflows, records auditable project state, and validates the generated surfaces.
|
||||
|
||||
The product exists to expand what a developer can do with Codex for game creation. It must not turn game development into mandatory studio ceremony, hide the developer's intent behind an opaque orchestrator, or replace human creative and technical judgment.
|
||||
The product exists to expand what a developer can do with Codex for game creation. It may orchestrate role-scoped Codex work when the plan, state, permissions, and handoffs stay explicit and reviewable. It must not turn game development into mandatory studio ceremony, hide the developer's intent behind an opaque orchestrator, or replace human creative and technical judgment.
|
||||
|
||||
## Product Shape
|
||||
|
||||
@@ -34,13 +34,14 @@ Open Game Studio is:
|
||||
- Codex-native in its primary execution path;
|
||||
- oriented around generated project files such as `AGENTS.md`, `.codex/**`, templates, tasks, and validation output;
|
||||
- useful for both solo/prototype work and more structured studio-style work;
|
||||
- explicit about when it is rendering prompts, running Codex, mutating project state, or only inspecting planned behavior.
|
||||
- allowed to provide bounded task orchestration for role-scoped Codex runs when it remains local, explicit, file-backed, policy-gated, and validated;
|
||||
- explicit about when it is rendering prompts, planning tasks, orchestrating task runs, running Codex, mutating project state, or only inspecting planned behavior.
|
||||
|
||||
Open Game Studio is not:
|
||||
|
||||
- a game engine or replacement for engine tooling;
|
||||
- a hosted service, daemon, IDE, or background workflow controller;
|
||||
- a general-purpose agent orchestrator or arbitrary workflow DAG engine;
|
||||
- a general-purpose agent platform or arbitrary workflow DAG engine outside game-studio tasks;
|
||||
- a hidden memory, checkpoint, telemetry, or analytics platform;
|
||||
- a CI, merge-approval, or release-enforcement product;
|
||||
- a requirements-management system or heavyweight studio-process mandate;
|
||||
@@ -51,25 +52,26 @@ External tools, reference workflows, and comparison projects may inspire improve
|
||||
## Core Behavior Expectations
|
||||
|
||||
1. **Codex-native by default.** Direct Codex execution through `opengamestudio run <role>` remains the primary runtime path. Inspection paths such as `--dry-run` and `--print-prompt` must stay non-mutating.
|
||||
2. **Local repository files stay reviewable.** Project state, prompts, tasks, approvals, templates, and validation evidence should be visible in the working tree or deterministic CLI output, not hidden in off-repo services.
|
||||
3. **Developer control comes first.** Studio depth is optional and mode-controlled. Fast prototype workflows must remain lightweight; strict approval flows must be explicit rather than silently imposed on every project.
|
||||
4. **Project stage and studio strictness are separate.** Lifecycle stage (`design`, `prototype`, `development`) must not be collapsed into process strictness (`fast-prototype`, `guided-studio`, `strict-studio`).
|
||||
5. **Generated instructions use `AGENTS.md` and `.codex/**`.** Do not add `CODEX.md`, legacy generated-project compatibility shims, or alternate instruction contracts unless a future boundary update explicitly changes this rule.
|
||||
6. **Depth comes from selected context, not prompt bloat.** Registries may contain rich roles, workflows, engine references, and rules, but generated prompts should include only relevant selected material.
|
||||
7. **Mutation is policy-gated and visible.** Any design that lets Codex or the CLI mutate files must specify write policy, approval/override behavior, sandbox selection, dry-run diagnostics, and where provenance is recorded.
|
||||
8. **Future-only surfaces must remain absent until built.** Planner/next, telemetry, parallel orchestration, hard output-ownership enforcement, and similar surfaces must not appear as user-facing behavior before they have implementation, tests, and docs.
|
||||
9. **Validation is part of the product.** New generated surfaces, package assets, CLI commands, and behavior-bearing docs need repo-native validation and tests before readiness or parity claims.
|
||||
10. **Truthmark is repository workflow tooling here, not the product.** Truthmark-backed docs may guard Open Game Studio's repository truth, but Open Game Studio should not present Truthmark workflow mechanics as game-studio product features.
|
||||
2. **Orchestration is now in scope when explicit.** The CLI may coordinate multiple role-scoped Codex task runs, including dependencies and bounded sequences, only when task state, selected context, approvals, locks, run metadata, and failure outcomes are visible in `.codex/**` or deterministic CLI output.
|
||||
3. **Local repository files stay reviewable.** Project state, prompts, tasks, approvals, templates, and validation evidence should be visible in the working tree or deterministic CLI output, not hidden in off-repo services.
|
||||
4. **Developer control comes first.** Studio depth is optional and mode-controlled. Fast prototype workflows must remain lightweight; orchestration and strict approval flows must be explicit rather than silently imposed on every project.
|
||||
5. **Project stage and studio strictness are separate.** Lifecycle stage (`design`, `prototype`, `development`) must not be collapsed into process strictness (`fast-prototype`, `guided-studio`, `strict-studio`).
|
||||
6. **Generated instructions use `AGENTS.md` and `.codex/**`.** Do not add `CODEX.md`, legacy generated-project compatibility shims, or alternate instruction contracts unless a future boundary update explicitly changes this rule.
|
||||
7. **Depth comes from selected context, not prompt bloat.** Registries may contain rich roles, workflows, engine references, and rules, but generated prompts and task packets should include only relevant selected material.
|
||||
8. **Mutation is policy-gated and visible.** Any design that lets Codex or the CLI mutate files must specify write policy, approval/override behavior, sandbox selection, dry-run diagnostics, and where provenance is recorded.
|
||||
9. **Future-only surfaces must remain absent until built.** Planner/next, telemetry, hard output-ownership enforcement, hosted orchestration, background autonomous loops, and unbounded parallelism must not appear as user-facing behavior before they have implementation, tests, and docs.
|
||||
10. **Validation is part of the product.** New generated surfaces, package assets, CLI commands, orchestration behavior, and behavior-bearing docs need repo-native validation and tests before readiness or parity claims.
|
||||
11. **Truthmark is repository workflow tooling here, not the product.** Truthmark-backed docs may guard Open Game Studio's repository truth, but Open Game Studio should not present Truthmark workflow mechanics as game-studio product features.
|
||||
|
||||
## In Scope
|
||||
|
||||
Designs and plans may expand or refine:
|
||||
|
||||
- CLI commands for project initialization, status, templates, validation, tasks, approvals, role runs, and bounded workflow shortcuts;
|
||||
- CLI commands for project initialization, status, templates, validation, tasks, approvals, role runs, explicit task orchestration, and bounded workflow shortcuts;
|
||||
- generated game project files under the project root, especially `AGENTS.md`, `.codex/**`, templates, tasks, approvals, context manifests, and selected runtime docs;
|
||||
- role and workflow registries that improve game-development coverage while keeping materialized prompts bounded;
|
||||
- engine references for Godot, Unity, and Unreal when they are packaged, validated, reviewed, and selected by relevance;
|
||||
- approval and write-policy primitives that explain or gate mutating behavior;
|
||||
- approval, locking, dependency, and write-policy primitives that explain or gate mutating and orchestrated behavior;
|
||||
- project validation, package smoke tests, and human-readable documentation that keep generated surfaces honest.
|
||||
|
||||
## Out Of Scope Unless This Boundary Changes
|
||||
@@ -81,7 +83,7 @@ Designs and plans must not introduce these as required product behavior:
|
||||
- mandatory heavyweight studio process for small prototypes;
|
||||
- non-Codex execution hosts as first-class runtime replacements;
|
||||
- general task management, PR approval, CI enforcement, or release governance outside the game-studio CLI boundary;
|
||||
- broad prompt generation that loads all agents, all templates, all engine references, or all docs for a single role task;
|
||||
- broad prompt generation or orchestration packets that load all agents, all templates, all engine references, or all docs for a single role task;
|
||||
- compatibility layers for stale generated project formats unless an explicit migration design is approved.
|
||||
|
||||
Optional integrations are acceptable only when the local Codex-native workflow remains understandable, reviewable, and usable without them.
|
||||
@@ -97,7 +99,7 @@ Every design, plan, or OpenSpec change should answer these questions before impl
|
||||
- What local files or deterministic outputs let a human review the change?
|
||||
- What writes are allowed, what writes are forbidden, and what fails closed?
|
||||
- What context is selected, and what prevents loading everything by default?
|
||||
- Does it accidentally introduce a hosted service, daemon, orchestrator, hidden memory layer, CI gate, or heavyweight lifecycle platform?
|
||||
- Does it accidentally introduce a hosted service, daemon, general-purpose orchestrator, hidden memory layer, CI gate, unbounded parallelism, or heavyweight lifecycle platform?
|
||||
- What tests, validation commands, and behavior-bearing docs prove the boundary remains intact?
|
||||
|
||||
If a design or plan cannot answer these questions, it is not ready to implement.
|
||||
|
||||
@@ -15,4 +15,4 @@ npm run validate
|
||||
|
||||
Keep generated projects under `projects/<slug>/`.
|
||||
|
||||
The current build invokes Codex by default through `run <role>`. Use `--dry-run` or `--print-prompt` for inspection-only paths. It still intentionally excludes planner commands, telemetry, parallel orchestration, changed-file tracking, and ownership enforcement.
|
||||
The current build invokes Codex by default through `run <role>`. Use `--dry-run` or `--print-prompt` for inspection-only paths. Explicit local task orchestration is now inside the product boundary, but runtime claims require implementation and validation. The build still intentionally excludes planner commands, telemetry, changed-file tracking, hosted/background orchestration, unbounded parallelism, and ownership enforcement.
|
||||
|
||||
@@ -16,9 +16,9 @@ Generated projects materialize project-specific `.codex/prompts/<role>.md` files
|
||||
|
||||
Market and analytics are first-class renderable workflows owned by dedicated roles. Workflow prompts and normal role runs inline selected package template bodies instead of pointing Codex at project-relative template paths or loading every template.
|
||||
|
||||
Studio orchestration is provided by the `studio-orchestrator` role and the render-only `handoff` workflow shortcut, not by a generated `project_orchestrator.md`.
|
||||
Studio orchestration is provided through Codex-native roles, file-backed task state, explicit `task orchestrate` execution, selected workflow task recipes, and bounded workflow surfaces, not by a generated `project_orchestrator.md`.
|
||||
|
||||
Richer workflows exist for design specs, game-feel review, art direction, UI/UX review, production milestones, review, ship-check, playtest, bugfix, vertical slice, market, analytics, and handoff. Shortcut workflow commands render prompts only; executable workflow lifecycle support remains future-only.
|
||||
Richer workflows exist for design specs, game-feel review, art direction, UI/UX review, production milestones, review, ship-check, playtest, bugfix, vertical slice, market, analytics, and handoff. Shortcut workflow commands render prompts. Supported workflow recipes such as `vertical-slice`, `bugfix`, `ui-ux-review`, and `release-checklist` can explicitly create `.codex/tasks.json` task graphs before `task orchestrate` runs them.
|
||||
|
||||
Intentional omissions for the first build: no interactive `menu`, no `startover`, no generated `project_orchestrator.md`, no exact `template_info.md`, no eager competitor reports during init, and no upstream license/authorship/citation parity documents.
|
||||
|
||||
@@ -26,4 +26,4 @@ Codex-native difference: `run <role>` invokes `codex exec` by default against th
|
||||
|
||||
Generated role prompts and workflow files include freshness metadata and rendered-body hashes for new projects. Validation reports legacy missing-metadata files as regeneration-needed skip diagnostics instead of treating them as fresh.
|
||||
|
||||
Future-only features are not implemented in this build: planner/`next`, telemetry, parallel orchestration, changed-file tracking, prompt-size metrics, hard output-ownership enforcement, legacy `.gamestudio` compatibility, `CODEX.md`, and `project_orchestrator.md`.
|
||||
Future-only features still not implemented in this build include planner/`next`, telemetry, changed-file tracking, prompt-size metrics, hard output-ownership enforcement, hosted/background orchestration, unbounded parallelism, legacy `.gamestudio` compatibility, `CODEX.md`, and `project_orchestrator.md`. Explicit local task orchestration is implemented as foreground, bounded, file-backed CLI behavior.
|
||||
|
||||
@@ -13,4 +13,4 @@ For inspection-only runs, add `--dry-run` or `--print-prompt` to view the genera
|
||||
|
||||
Intentional differences: no interactive menu, no `startover`, no exact `template_info.md`, no eager competitor reports during init, no generated `project_orchestrator.md`, no `CODEX.md`, no legacy `.gamestudio` compatibility, and no unsupported upstream underscore role IDs. Supported aliases such as `new` for `init` remain available.
|
||||
|
||||
Future-only features are not implemented: `opengamestudio next`, telemetry, parallel orchestration, changed-file tracking, and ownership enforcement.
|
||||
Future-only features are not implemented: `opengamestudio next`, telemetry, changed-file tracking, hosted/background orchestration, unbounded parallelism, and ownership enforcement. Explicit local task orchestration is implemented through reviewable `.codex/**` task, lock, and run state.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -88,7 +88,8 @@ This doc was created from the editable engineering-behavior template at docs/tru
|
||||
- Every built-in template records description and role/workflow use hints.
|
||||
- The project config template must parse as JSON.
|
||||
- Workflow shortcuts render prompts only.
|
||||
- Workflow shortcuts do not imply hidden planner, telemetry, ownership, or parallel orchestration behavior.
|
||||
- `workflow create-tasks` is a separate explicit recipe path that writes file-backed tasks for supported workflows without launching Codex.
|
||||
- Workflow shortcuts do not imply hidden planner, telemetry, ownership, hosted orchestration, background loops, or unbounded parallel behavior. Explicit local task orchestration is provided only through reviewable `.codex/**` task, lock, and run state.
|
||||
- Custom IDs must use the `custom-*` prefix.
|
||||
- Custom file references must be project-safe relative paths.
|
||||
- Custom entries must not replace built-in role, workflow, or template IDs.
|
||||
@@ -139,7 +140,8 @@ This doc was created from the editable engineering-behavior template at docs/tru
|
||||
|
||||
- Decision (2026-05-28): Use Codex-native hyphenated role IDs as the user- and project-facing role contract.
|
||||
- Decision (2026-05-28): Keep workflow shortcuts render-only for this pass.
|
||||
- Decision (2026-05-28): Keep future planner, next, telemetry, ownership enforcement, and parallel orchestration hidden.
|
||||
- Decision (2026-05-28): Keep future planner, next, telemetry, ownership enforcement, hosted orchestration, background loops, and unbounded parallelism hidden.
|
||||
- Decision (2026-06-25): Allow explicit local task orchestration as a product-boundary feature area when implemented through bounded selected context, file-backed task state, run metadata, locks, approvals, validation, and docs.
|
||||
- Decision (2026-06-13): Workflow prompts use the same context-contract renderer as role-run prompts.
|
||||
- Decision (2026-06-13): Workflow prompts include only selected workflow context.
|
||||
- Decision (2026-06-14): Add one specialist role ID per supported engine.
|
||||
|
||||
@@ -10,7 +10,7 @@ last_reviewed: 2026-06-25
|
||||
|
||||
Runtime and task execution connects prepared Codex Game Studio prompts to the Codex CLI.
|
||||
|
||||
It also preserves explicit task state and runs bounded verification, review, and fix loops without hidden orchestration.
|
||||
It also preserves explicit task state and runs bounded verification, review, and fix loops. The product boundary now allows local, file-backed task orchestration when task state, locks, approvals, selected context, run metadata, and failures stay reviewable.
|
||||
|
||||
## Scope
|
||||
|
||||
@@ -25,6 +25,8 @@ It does not own role prompt content, project scaffolding, or public CLI help wor
|
||||
- A user invokes `run <role> ... --project <path>` to render or execute a role prompt.
|
||||
- A user creates a file-backed task through `task create`.
|
||||
- A user runs a file-backed task through `task run`.
|
||||
- A user orchestrates ready file-backed tasks through `task orchestrate`.
|
||||
- A user creates explicit task graphs through `workflow create-tasks <workflow-id>`.
|
||||
- A run includes structured verification, review, or bounded fix-pass options.
|
||||
|
||||
## Inputs
|
||||
@@ -35,6 +37,8 @@ It does not own role prompt content, project scaffolding, or public CLI help wor
|
||||
- A studio role ID or task ID.
|
||||
- A non-empty task or objective.
|
||||
- Optional included artifacts.
|
||||
- Optional declared write files for task approval and orchestration locks.
|
||||
- Optional task dependencies, workflow IDs, group IDs, and priority.
|
||||
- Optional verification command and arguments.
|
||||
- Optional review flag, fix flag, and max fix-pass count.
|
||||
|
||||
@@ -44,7 +48,7 @@ Runtime execution prepares bounded Codex prompts before side effects.
|
||||
|
||||
It evaluates studio write policy before mutation.
|
||||
|
||||
It records visible run and task state for non-inspection paths. It reports verification, review, and fix outcomes without hidden orchestration.
|
||||
It records visible run and task state for non-inspection paths. It reports verification, review, and fix outcomes without hidden orchestration; future orchestration work must keep those outcomes explicit in `.codex/**` state.
|
||||
|
||||
## Execution Model
|
||||
|
||||
@@ -100,6 +104,11 @@ It records visible run and task state for non-inspection paths. It reports verif
|
||||
- Implementation and fix phases classify mutating eligibility.
|
||||
- Allowed mutating policies map to `danger-full-access` unless constrained sandbox is explicitly requested.
|
||||
- Task runs mutate task status only for non-dry execution.
|
||||
- Task orchestration preflights selected tasks without writing run, lock, or task state.
|
||||
- Non-dry task orchestration records an orchestration run under `.codex/runs/<run-id>/`, writes per-task prompt/output metadata under `tasks/<task-id>/`, and uses `.codex/locks/` for transient write locks.
|
||||
- Bounded parallel orchestration caps `--max-concurrency` at 3.
|
||||
- Mutating orchestrated tasks without declared `writeFiles` use a conservative project-wide write lock.
|
||||
- `files` are read/context inputs; `writeFiles` are mutation approval and lock inputs.
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -122,9 +131,11 @@ It records visible run and task state for non-inspection paths. It reports verif
|
||||
## State, Retry, And Failure Behavior
|
||||
|
||||
- Task stores live at `.codex/tasks.json`.
|
||||
- Task stores use schema version 1 and unique `task-###` IDs.
|
||||
- Task stores use schema version 2 and unique `task-###` IDs; schema version 1 stores are normalized on read and rewritten as version 2 when saved.
|
||||
- `task create` requires a valid studio project before writing task state.
|
||||
- Task statuses are `ready`, `running`, `blocked`, and `done`.
|
||||
- Task statuses are `ready`, `running`, `blocked`, `done`, `cancelled`, and `skipped`.
|
||||
- Task dependency records require dependent tasks to reach `done`.
|
||||
- Orchestration serializes task-store writes while bounded tasks execute.
|
||||
- Verification commands use bounded stdout and stderr capture.
|
||||
- Verification commands use a default timeout.
|
||||
- Timed-out verification receives SIGTERM, then SIGKILL after the configured grace period.
|
||||
@@ -140,6 +151,8 @@ It records visible run and task state for non-inspection paths. It reports verif
|
||||
- Print-prompt output is the deterministic prompt body.
|
||||
- Non-dry run output reports implementation, verification, review, fix-pass, and final-status summaries.
|
||||
- Task creation prints the new task ID.
|
||||
- Task orchestration dry-runs print planned tasks, dependencies, locks, selected context, and Codex commands.
|
||||
- Non-dry orchestration output reports per-task status and final orchestration status.
|
||||
|
||||
## Product Truth Links
|
||||
|
||||
@@ -165,6 +178,9 @@ It records visible run and task state for non-inspection paths. It reports verif
|
||||
- Decision (2026-06-17): Route custom role runs through the same write-policy, sandbox, context, cache, and template contracts as built-in roles.
|
||||
- Decision (2026-06-17): Do not introduce a separate plugin runtime for custom roles.
|
||||
- Decision (2026-06-17): Honor review/fix flags for custom role runs with real lifecycle prompts.
|
||||
- Decision (2026-06-25): Move explicit local task orchestration into the product boundary while keeping hosted orchestration, background loops, hidden planners, and unbounded parallelism out of scope.
|
||||
- Decision (2026-06-25): Implement orchestration as a foreground `task orchestrate` command with side-effect-free preflight, schema-version-2 task state, transient `.codex/locks/`, and bounded concurrency capped at 3.
|
||||
- Decision (2026-06-25): Bind task approval and orchestration locks to declared `writeFiles`; keep `files` as read/context inputs.
|
||||
- Decision (2026-06-17): Use a read-only QA review prompt and a bounded custom-role fix prompt.
|
||||
|
||||
## Rationale
|
||||
@@ -175,7 +191,8 @@ Non-dry runs use visible cache paths and verification output. Read-only review p
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- This workflow does not implement hidden parallel execution.
|
||||
- This workflow implements explicit bounded local task orchestration; it does not implement hidden parallel execution.
|
||||
- This workflow does not implement hosted orchestration, background autonomous loops, or unbounded parallelism.
|
||||
- This workflow does not implement telemetry.
|
||||
- This workflow does not implement ownership enforcement.
|
||||
- This workflow does not implement a planner or next queue.
|
||||
@@ -197,10 +214,17 @@ Non-dry runs use visible cache paths and verification output. Read-only review p
|
||||
- ../../../../src/context-manifest.ts
|
||||
- ../../../../src/prompt-context.ts
|
||||
- ../../../../src/tasks.ts
|
||||
- ../../../../src/orchestrator.ts
|
||||
- ../../../../src/orchestrator-locks.ts
|
||||
- ../../../../src/workflow-recipes.ts
|
||||
- ../../../../src/ccgs-adaptation.ts
|
||||
- ../../../../src/codex-runtime.ts
|
||||
- ../../../../src/verification.ts
|
||||
- ../../../../tests/runner.test.ts
|
||||
- ../../../../tests/studio-policy.test.ts
|
||||
- ../../../../tests/tasks.test.ts
|
||||
- ../../../../tests/orchestrator.test.ts
|
||||
- ../../../../tests/workflow-recipes.test.ts
|
||||
- ../../../../tests/ccgs-adaptation.test.ts
|
||||
- ../../../../tests/verification.test.ts
|
||||
- ../../../../tests/codex-runtime.test.ts
|
||||
|
||||
@@ -128,7 +128,7 @@ It does not own project scaffolding internals, role prompt content, or Codex run
|
||||
- Node support requires a package engine floor that includes Node >=24.
|
||||
- Packaged files must include `dist/`, `engine_configs/`, `engine_reference/`, and `templates/`.
|
||||
- Future-only command surfaces stay hidden until implemented intentionally.
|
||||
- Future-only examples include `next`, `telemetry`, `parallel`, and ownership enforcement.
|
||||
- Future-only examples include `next`, `telemetry`, hosted/background orchestration, unbounded parallelism, and ownership enforcement.
|
||||
|
||||
## Versioning And Migration
|
||||
|
||||
@@ -158,7 +158,8 @@ It does not own project scaffolding internals, role prompt content, or Codex run
|
||||
- Decision (2026-06-14): Validate engine reference packs by registered file presence and seed-review metadata shape.
|
||||
- Decision (2026-06-14): Validate active-engine materialized references without judging prose quality.
|
||||
- Decision (2026-06-17): Expose the expanded workflow catalog as render-only CLI shortcuts.
|
||||
- Decision (2026-06-17): Keep future planner, next, telemetry, parallel orchestration, and ownership enforcement hidden.
|
||||
- Decision (2026-06-17): Keep future planner, next, telemetry, hosted/background orchestration, unbounded parallelism, and ownership enforcement hidden.
|
||||
- Decision (2026-06-25): Treat explicit local task orchestration as in-boundary once it has CLI behavior, validation, tests, and truth docs; keep hosted/background orchestration and unbounded parallelism hidden.
|
||||
- Decision (2026-06-17): Add local deterministic behavioral-evaluation subchecks.
|
||||
- Decision (2026-06-17): Do not use hosted evaluators, telemetry, hidden memory, or LLM judges for those checks.
|
||||
- Decision (2026-06-17): Support project-local customization as an extend-only `custom-*` overlay.
|
||||
|
||||
@@ -32,7 +32,7 @@ They are listed in `docs/truthmark/routes/areas/repository.md`.
|
||||
- Role run commands render deterministic Codex prompts.
|
||||
- Unless in inspection mode, role run commands execute Codex with optional verification, review, and bounded fix passes.
|
||||
- Workflow shortcut commands are render-only prompt surfaces.
|
||||
- Workflow shortcuts do not imply hidden planner, parallel orchestration, telemetry, or ownership enforcement behavior.
|
||||
- Workflow shortcuts do not imply hidden planner, hosted orchestration, background loops, unbounded parallelism, telemetry, or ownership enforcement behavior. Explicit local task orchestration is now allowed by the product boundary only when backed by reviewable `.codex/**` state.
|
||||
- Validation checks package metadata, source files, templates, role/workflow rendering, behavioral-evaluation scenarios, and customization packs.
|
||||
- It also checks future-surface guardrails, build output, and package install smoke behavior.
|
||||
|
||||
@@ -93,7 +93,7 @@ Bounded truth surfaces make the architecture easier to review. They also prevent
|
||||
## Non-Goals
|
||||
|
||||
- This doc does not replace specific leaf truth docs.
|
||||
- This repository does not expose hidden parallel orchestration.
|
||||
- This repository does not expose hidden parallel orchestration, hosted orchestration, background autonomous loops, or unbounded parallelism.
|
||||
- This repository does not expose telemetry.
|
||||
- This repository does not expose planner/next queues.
|
||||
- This repository does not expose ownership enforcement as public CLI behavior.
|
||||
|
||||
@@ -30,7 +30,7 @@ It covers project initialization, role/workflow prompt rendering, direct Codex e
|
||||
|
||||
It also covers generated project files and validation.
|
||||
|
||||
This capability excludes game-engine functionality and hosted orchestration.
|
||||
This capability excludes game-engine functionality and hosted orchestration. It includes explicit local task orchestration when state, approvals, selected context, locks, runs, and failures are reviewable in `.codex/**`.
|
||||
|
||||
It also excludes background autonomous control, CI/release enforcement, hidden checkpoint/memory systems, and mandatory studio ceremony for small prototypes.
|
||||
|
||||
@@ -93,12 +93,14 @@ Production templates are package-shipped assets selected by relevance.
|
||||
## Product Decisions
|
||||
|
||||
- 2026-06-13: Open Game Studio is a local-first Codex-native CLI/package for game-development repository workflows.
|
||||
- 2026-06-13: Open Game Studio is not a hosted studio service, daemon, general orchestrator, or game engine.
|
||||
- 2026-06-13: Open Game Studio is not a hosted studio service, daemon, general-purpose orchestrator, or game engine.
|
||||
- 2026-06-25: Explicit local task orchestration is inside the product boundary when it remains Codex-native, file-backed, bounded by selected context, policy-gated, and validated.
|
||||
- 2026-06-25: The first orchestration implementation is a foreground `task orchestrate` CLI with bounded concurrency, transient `.codex/locks/`, workflow task recipes, and no hosted/background/unbounded behavior.
|
||||
- 2026-06-13: Studio depth is optional and mode-controlled.
|
||||
- 2026-06-13: Lifecycle stage must remain separate from process strictness.
|
||||
- 2026-06-13: Generated project instruction contracts use `AGENTS.md` and `.codex/**`.
|
||||
- 2026-06-13: Generated project instruction contracts do not use `CODEX.md` or legacy compatibility shims.
|
||||
- 2026-06-13: Planner/next, telemetry, parallel orchestration, hard ownership enforcement, and similar future-only surfaces remain absent until implemented, tested, and documented.
|
||||
- 2026-06-13: Planner/next, telemetry, hard ownership enforcement, hosted/background orchestration, unbounded parallelism, and similar future-only surfaces remain absent until implemented, tested, and documented.
|
||||
- 2026-06-13: Truthmark-backed docs guard repository truth in this checkout.
|
||||
- 2026-06-13: Truthmark workflow mechanics are not Open Game Studio product features.
|
||||
- 2026-06-17: Project-local customization is an extend-only, file-backed overlay for `custom-*` roles, workflows, and templates.
|
||||
|
||||
@@ -132,11 +132,18 @@ Code surface:
|
||||
- src/context-manifest.ts
|
||||
- src/prompt-context.ts
|
||||
- src/tasks.ts
|
||||
- src/orchestrator.ts
|
||||
- src/orchestrator-locks.ts
|
||||
- src/workflow-recipes.ts
|
||||
- src/ccgs-adaptation.ts
|
||||
- src/codex-runtime.ts
|
||||
- src/verification.ts
|
||||
- tests/runner.test.ts
|
||||
- tests/studio-policy.test.ts
|
||||
- tests/tasks.test.ts
|
||||
- tests/orchestrator.test.ts
|
||||
- tests/workflow-recipes.test.ts
|
||||
- tests/ccgs-adaptation.test.ts
|
||||
- tests/verification.test.ts
|
||||
- tests/codex-runtime.test.ts
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
Validation exits nonzero when any check fails.
|
||||
|
||||
Repo validation checks package scripts, build output, package assets, engine configs, expanded role rendering, canonical workflow rendering, deterministic behavioral-evaluation scenarios, templates, package packing, installed-bin asset loading, future-only CLI surfaces, and Codex CLI readiness.
|
||||
Repo validation checks package scripts, build output, package assets, engine configs, expanded role rendering, canonical workflow rendering, deterministic behavioral-evaluation scenarios, templates, package packing, installed-bin asset loading, future-only CLI surfaces, and Codex CLI readiness. Tests also cover explicit task orchestration, workflow task recipes, and curated CCGS adaptation registry consistency.
|
||||
|
||||
Project validation checks `.codex/studio.json` full `roles`, mode-specific `activeRoles`, registry-derived `workflows`, `.codex/studio/config.json` customization packs, `AGENTS.md`, generated project-specific role prompts, workflow files, engine source files, starter docs, timeline sections, forbidden legacy artifacts, and read-only `status`/`resume` behavior.
|
||||
|
||||
@@ -13,7 +13,7 @@ npm exec opengamestudio -- run --help | grep -- "--dry-run"
|
||||
! npm exec opengamestudio -- --help | grep -E " next|telemetry"
|
||||
```
|
||||
|
||||
Workflow shortcut commands such as `market`, `analytics`, `design-spec`, `feel-review`, `art-direction`, `ui-review`, `milestone`, and `handoff` render prompts only. They do not launch Codex or create run records.
|
||||
Workflow shortcut commands such as `market`, `analytics`, `design-spec`, `feel-review`, `art-direction`, `ui-review`, `milestone`, and `handoff` render prompts only. They do not launch Codex or create run records. `workflow create-tasks <workflow-id>` is the explicit path for turning supported workflow recipes into `.codex/tasks.json` tasks; it still does not launch Codex.
|
||||
|
||||
Behavioral evaluation scenarios are local deterministic validation subchecks. They render built-in role and workflow prompts, assert required prompt obligations, selected context categories, relevant templates, output-contract coverage, and forbidden future-only drift. They do not call hosted evaluators, telemetry, hidden memory, or LLM judges.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user