83 lines
6.4 KiB
Markdown
83 lines
6.4 KiB
Markdown
## Context
|
|
|
|
The repository already has a completed baseline architecture stream plus many completed implementation changes. The delivery plan is now out of date because it still calls `implement-server-management-workflows` active, while `openspec list` shows it as complete. The only currently open implementation item is `fix-env-profile-settings`, where the remaining task is browser walkthrough evidence for the personal settings page.
|
|
|
|
The user wants a workflow that can be continued in fresh chats: run the plan, create one OpenSpec, implement or close it, then open the next chat and generate or execute the next OpenSpec. The queue must be practical for this repository and must keep the platform focused on game server management, not billing, cloud sales, or unrelated SaaS features.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Keep a single source of truth for the ordered architecture delivery queue.
|
|
- Make the next step obvious for a new chat without requiring a full rediscovery pass.
|
|
- Ensure each fresh chat creates or implements exactly one concrete OpenSpec unless the user explicitly asks to continue.
|
|
- Require verification evidence before tasks are marked complete.
|
|
- Prioritize proving real, end-to-end behavior over adding more demo-only surfaces.
|
|
- Preserve the existing ownership boundaries between `platform/`, `run/`, `platform_web/`, and `plugins/`.
|
|
|
|
**Non-Goals:**
|
|
|
|
- This change does not implement product features.
|
|
- This change does not redesign the interface directly.
|
|
- This change does not create billing, host sales, cloud-provider, or agent-provider workflows.
|
|
- This change does not allow browser or game management plugins to connect directly to run.
|
|
|
|
## Decisions
|
|
|
|
### Decision 1: Use the existing architecture stream as the queue record
|
|
|
|
The canonical queue will remain under `openspec/changes/architecture-delivery-stream/` because that location already contains `delivery-plan.md`, the handoff template, and the architecture workflow spec.
|
|
|
|
Alternative considered: create a new top-level `openspec/delivery/` folder. That would be cleaner long-term, but it would split the current history and require extra structural rules before the workflow itself is corrected.
|
|
|
|
### Decision 2: Add a next-change pointer for fresh chats
|
|
|
|
The refreshed stream will add `openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md`. It will contain the current state guard, next change name, exact creation prompt, exact implementation prompt, and stop condition. A fresh chat can read that file first and continue without scanning every historical change.
|
|
|
|
Alternative considered: keep only the queue table. A table is useful for planning, but it is too easy for a new chat to pick the wrong pending item when one change is blocked or partially closed.
|
|
|
|
### Decision 3: Separate generator chats from implementation chats
|
|
|
|
A generator chat may create exactly one new OpenSpec change and validate its artifacts. It must not implement that change unless the user explicitly asks. An implementation chat may implement exactly one concrete change and then update the queue pointer when complete.
|
|
|
|
Alternative considered: let one chat generate and implement many changes. That is faster in the short term but recreates the current problem: broad scope, stale status, and unclear closure evidence.
|
|
|
|
### Decision 4: Treat incomplete verification as an active guard
|
|
|
|
The queue must not advance past `fix-env-profile-settings` until its browser walkthrough task is closed or explicitly marked blocked with evidence. This avoids pretending the platform is accepted when the UI was not walked through.
|
|
|
|
Alternative considered: ignore the open task because the code and CLI checks passed. That would violate the repository verification rules for frontend changes.
|
|
|
|
### Decision 5: Seed the next queue with proof-oriented OpenSpecs
|
|
|
|
The next changes should first prove current behavior, then close real gaps. The seed queue is:
|
|
|
|
1. `verify-current-platform-e2e-baseline`: browser/API/run walkthrough proving which required platform flows work and which are still demo-only.
|
|
2. `implement-real-game-plugin-lifecycle-proof`: make a local game management plugin create and manage multiple server instances through platform-mediated actions.
|
|
3. `harden-log-artifact-channel-isolation`: prove log ingest remains durable while file/artifact operations are active.
|
|
4. `implement-local-debug-workspace`: make local debugging easy for platform, run, frontend, and game management plugins.
|
|
5. `implement-browser-acceptance-suite`: automate browser walkthroughs for the required first-party areas.
|
|
6. `polish-platform-interaction-design`: address interface dissatisfaction through concrete interaction proposals and browser-reviewed improvements aligned with the existing visual direction.
|
|
|
|
The first generated change should be `verify-current-platform-e2e-baseline` because the user is questioning whether the project is still only a demo. Implementation should be guided by observed behavior, not assumptions.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- Stale queue risk -> Mitigation: require every completed implementation chat to update `NEXT_CHANGE.md` and `delivery-plan.md` before closing.
|
|
- Oversized change risk -> Mitigation: split a pending item before product code is written if it cannot be completed in one focused chat.
|
|
- False completion risk -> Mitigation: keep task boxes unchecked until commands, browser walkthrough notes, screenshots, or test results are recorded.
|
|
- UI churn risk -> Mitigation: put interface dissatisfaction into a specific design OpenSpec instead of mixing visual redesign into backend or protocol work.
|
|
- Scope creep risk -> Mitigation: every handoff repeats the platform boundaries and excludes billing, cloud sales, unrelated marketplace features, raw AI key exposure, and direct plugin/run access.
|
|
|
|
## Migration Plan
|
|
|
|
1. Update `architecture-delivery-stream/delivery-plan.md` to reflect the actual completed and active states.
|
|
2. Add `NEXT_CHANGE.md` with the immediate guard and next generated OpenSpec prompt.
|
|
3. Validate this planning change with `openspec validate refresh-architecture-delivery-stream --strict`.
|
|
4. Run `scripts/check-structure.sh` to ensure repository structure expectations still pass.
|
|
5. In the next fresh chat, finish `fix-env-profile-settings` browser walkthrough if still open; then generate `verify-current-platform-e2e-baseline`.
|
|
|
|
## Open Questions
|
|
|
|
- None for this planning change. The detailed product gaps must be discovered by the first proof-oriented OpenSpec.
|