admin343/browser
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

first commit

Browse Source
This commit is contained in:
npc0-hue
2026-07-11 14:56:10 +08:00
commit 7e05d0a4e7
660 changed files with 78119 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/architecture-delivery-stream/.openspec.yaml
+2
View File
@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-07-02
openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md
+55
View File
@@ -0,0 +1,55 @@
# Next Architecture Stream Action
## Current Guard
- No active guard.
- `fix-env-profile-settings` task `3.5` is complete.
- `implement-browser-acceptance-suite` is complete.
- `polish-platform-interaction-design` is complete with desktop/mobile browser walkthrough evidence, black mecha and magical-girl theme evidence, automated browser acceptance evidence, frontend verification, structure verification, and strict OpenSpec validation.
## Current Change To Implement
- None. The current delivery stream has no active implementation target.
## Latest Completed Change
- Change name: `polish-platform-interaction-design`
- Status: complete.
- Primary roots: `platform_web/`
- Completion evidence:
- `LOCAL_DEBUG_PLATFORM_PORT=18189 LOCAL_DEBUG_WEB_PORT=5183 LOCAL_DEBUG_ROOT=/private/tmp/browser-local-debug-acceptance scripts/browser-acceptance.sh`
- Evidence file: `/private/tmp/browser-local-debug-acceptance/browser-acceptance/browser-acceptance-evidence.json`
- `cd platform_web && npm run typecheck`
- `cd platform_web && npm test`
- `cd platform_web && npm run build`
- `scripts/check-structure.sh`
- `openspec validate polish-platform-interaction-design --strict`
## Recommended Next Action
No further concrete backlog item is defined in the current delivery stream. The next stream step should be one of:
1. Archive completed OpenSpec changes, starting with `polish-platform-interaction-design`, if the user wants to finalize the completed stream state.
2. Create exactly one new OpenSpec change from fresh product/design feedback, if the user provides or approves a new concrete backlog item.
## Prompt For The Next Chat
```text
Continue the architecture delivery stream in /Users/tasia/Desktop/code/browser.
Read first:
- AGENTS.md
- openspec/changes/architecture-delivery-stream/delivery-plan.md
- openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md
Task:
- Confirm there is no active guard and no active implementation target.
- If asked to finalize completed work, archive completed OpenSpec changes according to the archive workflow.
- If asked to continue product work, create exactly one new OpenSpec change from fresh approved feedback before implementing anything.
- Run the required OpenSpec validation for any change you create or archive.
- Update delivery-plan.md and NEXT_CHANGE.md after the stream action.
```
## Stop Condition
Stop after archiving completed work or preparing exactly one new approved OpenSpec change, unless the user explicitly asks to keep going.
openspec/changes/architecture-delivery-stream/delivery-plan.md
+123
View File
@@ -0,0 +1,123 @@
# Architecture Delivery Stream
This file is the working progress record for the architecture stream. It is intentionally stored with the OpenSpec change so a new chat can read the current queue before creating or implementing the next change.
## Status Legend
- `complete`: tasks and verification evidence exist.
- `active`: current implementation target.
- `guard`: current blocker that must be closed or explicitly reprioritized before generating the next concrete OpenSpec.
- `pending`: planned but not active.
- `paused`: intentionally deferred by the user.
- `blocked`: cannot proceed without a user decision or external state change.
## Current Guard
No active guard. `fix-env-profile-settings` task `3.5` was completed on 2026-07-08 with an API-backed browser walkthrough for the personal settings page, and `scripts/check-structure.sh` plus `openspec validate fix-env-profile-settings --strict` passed.
## Queue
| Order | Status | Change | Primary Roots | Completion Gate |
| --- | --- | --- | --- | --- |
| 0 | complete | `bootstrap-game-server-platform-architecture` | all | `scripts/check-structure.sh`; `openspec validate bootstrap-game-server-platform-architecture --strict`. |
| 1 | complete | `establish-development-runtime-baseline` | all | `scripts/check-all.sh`; `scripts/check-structure.sh`; `openspec validate establish-development-runtime-baseline --strict`; browser walkthrough. |
| 2 | complete | `implement-platform-core-domain` | `platform/` | Platform domain unit tests and strict validation. |
| 3 | complete | `implement-platform-api-surface` | `platform/` | API handler tests, validation tests, strict validation. |
| 4 | complete | `implement-ai-provider-management` | `platform/`, `platform_web/` | Secret redaction tests, API tests, browser walkthrough, strict validation. |
| 5 | complete | `implement-run-control-registration` | `run/`, `platform/` | Control protocol tests, registration integration test, strict validation. |
| 6 | complete | `implement-run-job-channel` | `run/`, `platform/` | Job lifecycle tests, journal/idempotency tests, strict validation. |
| 7 | complete | `implement-log-ingest-pipeline` | `run/`, `platform/` | Spool retry tests, batch ack tests, query tests, strict validation. |
| 8 | complete | `implement-artifact-transfer-channel` | `run/`, `platform/` | Chunk/resume/checksum tests, priority isolation tests, strict validation. |
| 9 | complete | `implement-plugin-registry-and-manifest-validation` | `plugins/`, `platform/` | Schema validation tests, registry API tests, strict validation. |
| 10 | complete | `implement-plugin-bridge-and-sdk` | `plugins/`, `platform_web/`, `platform/` | Bridge permission tests, SDK type checks, strict validation. |
| 11 | complete | `implement-platform-web-console-shell` | `platform_web/` | Frontend build, route/page tests, browser walkthrough, strict validation. |
| 12 | complete | `implement-server-management-workflows` | all | Create/start/stop workflow tests, browser walkthrough, strict validation. |
| 13 | complete | `redesign-platform-web-interactions` | `platform_web/` | Frontend tests/build, browser walkthrough, strict validation. |
| 14 | complete | `fix-platform-auth-session-api` | `platform/`, `platform_web/` | Auth/session API tests, frontend auth flow tests, strict validation. |
| 15 | complete | `implement-role-scoped-server-access` | `platform/`, `platform_web/` | Role access tests, UI visibility tests, strict validation. |
| 16 | complete | `implement-platform-observability-and-config-read` | `platform/`, `run/`, `platform_web/` | Observability/config read tests, browser walkthrough, strict validation. |
| 17 | complete | `implement-plugin-marketplace-api-driven-ui` | `platform/`, `platform_web/`, `plugins/` | Marketplace API tests, frontend tests/build, browser walkthrough, strict validation. |
| 18 | complete | `implement-config-write-and-file-dispatch` | `platform/`, `run/`, `platform_web/`, `plugins/` | Config diff/write tests, file dispatch tests, browser walkthrough, strict validation. |
| 19 | complete | `implement-run-worker-real-execution` | `run/`, `platform/` | Real worker lifecycle tests, job result tests, strict validation. |
| 20 | complete | `implement-plugin-page-bridge-execution` | `platform_web/`, `plugins/`, `platform/` | Plugin page bridge tests, permission tests, strict validation. |
| 21 | complete | `implement-platform-mediated-ai-invocation` | `platform/`, `platform_web/`, `plugins/` | AI invocation tests, key redaction tests, reviewable diff tests, strict validation. |
| 22 | complete | `implement-artifact-download-and-browser-transfer` | `platform/`, `run/`, `platform_web/` | Artifact download/transfer tests, browser download walkthrough, strict validation. |
| 23 | complete | `sync-implemented-docs-and-comments` | all | Documentation/comment sync checks and strict validation. |
| 24 | complete | `implement-durable-platform-storage` | `platform/` | Durable repository tests and strict validation. |
| 25 | complete | `add-local-docker-deployment` | all | Local docker smoke path and strict validation. |
| 26 | complete | `add-mysql-platform-metadata-storage` | `platform/`, deployment | MySQL metadata tests and strict validation. |
| 27 | complete | `fix-env-profile-settings` | `platform/`, `platform_web/` | Browser walkthrough task `3.5`; `scripts/check-structure.sh`; `openspec validate fix-env-profile-settings --strict`. |
| 28 | complete | `verify-current-platform-e2e-baseline` | all | Browser walkthrough and API/run/plugin proof report that classifies every required first-party flow as real, partial, demo-only, or blocked. |
| 29 | complete | `implement-real-game-plugin-lifecycle-proof` | `plugins/`, `platform/`, `platform_web/`, `run/` | Plugin/SDK tests, platform lifecycle tests, run lifecycle tests, platform_web tests/build, API-backed browser walkthrough, `scripts/check-structure.sh`, and `openspec validate implement-real-game-plugin-lifecycle-proof --strict`. |
| 30 | complete | `harden-log-artifact-channel-isolation` | `run/`, `platform/` | Run/platform channel isolation tests, protocol docs, `cd run && GOCACHE=/private/tmp/browser-go-build-cache go test ./... -count=1`, `cd platform && GOCACHE=/private/tmp/browser-go-build-cache go test ./... -count=1`, `scripts/check-structure.sh`, and `openspec validate harden-log-artifact-channel-isolation --strict`. |
| 31 | complete | `implement-local-debug-workspace` | all | Local debug docs/scripts, self-start smoke, browser walkthrough, frontend/plugin/platform/run checks, `scripts/check-structure.sh`, and `openspec validate implement-local-debug-workspace --strict`. |
| 32 | complete | `implement-browser-acceptance-suite` | `platform_web/`, all | Automated browser acceptance command, API-backed first-party route proof, plugin/server operation proof, frontend/plugin/platform/run checks, `scripts/check-structure.sh`, and `openspec validate implement-browser-acceptance-suite --strict`. |
| 33 | complete | `polish-platform-interaction-design` | `platform_web/` | Interaction/design polish criteria, desktop/mobile browser walkthroughs, automated browser acceptance, platform_web tests/build, `scripts/check-structure.sh`, and `openspec validate polish-platform-interaction-design --strict`. |
## Next Pointer
Read `openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md` before starting a fresh architecture-stream chat. That file contains the exact next action and prompt.
## Generator Handoff Template
Use this template when starting a fresh chat whose job is to create the next OpenSpec only:
```text
Continue the architecture delivery stream in /Users/tasia/Desktop/code/browser.
Read first:
- AGENTS.md
- openspec/changes/architecture-delivery-stream/delivery-plan.md
- openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md
Task:
- Follow NEXT_CHANGE.md exactly.
- If the current guard is still open, close or explicitly record the blocker first.
- Create exactly one new OpenSpec change.
- Generate proposal.md, design.md, specs/**/*.md, and tasks.md for that one change.
- Run openspec validate <new-change> --strict.
- Update NEXT_CHANGE.md to point at implementing the new change.
- Stop after the one new OpenSpec is ready; do not implement it in this chat unless explicitly asked.
```
## Implementation Handoff Template
Use this template when starting a fresh implementation chat for a concrete change:
```text
Implement OpenSpec change: <change-name>
Scope:
- Implement only openspec/changes/<change-name>/.
- Preserve root ownership boundaries in AGENTS.md.
- Do not add billing, cloud host sales, agent-provider/cloud-provider workflows, or unrelated marketplace features.
- Do not let browser or game management plugins access run directly; route plugin capabilities through platform-mediated contracts.
- Keep log ingest durable and independent from control, job result, and artifact/file transfer channels.
Read first:
- AGENTS.md
- openspec/changes/architecture-delivery-stream/delivery-plan.md
- openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md
- openspec/changes/bootstrap-game-server-platform-architecture/proposal.md
- openspec/changes/bootstrap-game-server-platform-architecture/design.md
- openspec/changes/<change-name>/proposal.md
- openspec/changes/<change-name>/design.md
- openspec/changes/<change-name>/tasks.md
Required closure:
- Complete the tasks in openspec/changes/<change-name>/tasks.md only after evidence exists.
- Run scripts/check-structure.sh.
- Run openspec validate <change-name> --strict.
- Run all change-specific test/build/walkthrough commands listed in the task file.
- If frontend pages are touched, complete a browser walkthrough before claiming acceptance.
- Update delivery-plan.md and NEXT_CHANGE.md before closing.
- Stop after this change is closed; do not start the next backlog item in the same chat unless explicitly asked.
```
## Progress Rules
1. Resolve the current guard before generating a new concrete product OpenSpec unless the user explicitly reprioritizes.
2. Create or implement only one concrete OpenSpec by default.
3. If implementation reveals that a pending item is too large, split it before writing product code.
4. Update this progress file and `NEXT_CHANGE.md` through an OpenSpec change when the queue order, active item, or completion gates materially change.
5. Keep final answers from implementation chats focused on changed files, verification evidence, and the next suggested backlog item.
openspec/changes/architecture-delivery-stream/design.md
+94
View File
@@ -0,0 +1,94 @@
## Context
`bootstrap-game-server-platform-architecture` established the repository roots, ownership boundaries, and architecture contracts, but it intentionally did not build the full platform. The remaining work touches all four roots and needs to be delivered as a sequence of small OpenSpec changes so each implementation chat has a narrow scope, concrete verification commands, and clear handoff to the next change.
The delivery stream is a process and governance layer. It does not replace the bootstrap specs. Each follow-up change must treat the bootstrap change and any archived specs as the baseline.
## Goals / Non-Goals
**Goals:**
- Define one ordered backlog for the architecture implementation.
- Keep each OpenSpec change small enough for one focused implementation chat.
- Require a standard handoff block for every concrete change so the user can open a new chat and paste a precise implementation prompt.
- Require closing evidence before the next OpenSpec is created or implemented.
- Cover `platform/`, `run/`, `platform_web/`, and `plugins/` without mixing ownership boundaries.
**Non-Goals:**
- Do not add billing, cloud host sales, provider marketplace, or agent-provider workflows.
- Do not implement product code inside this stream change.
- Do not require automated creation or closing of chats; chat boundaries are user-operated.
- Do not redefine product scope already covered by the bootstrap architecture.
## Decisions
### Decision 1: Use a serial backlog, not parallel feature branches
Only one concrete implementation OpenSpec should be active at a time unless the user explicitly pauses or reprioritizes the stream. This keeps validation evidence simple and prevents later changes from depending on unverified assumptions.
Alternative considered: create all detailed OpenSpecs at once. Rejected because later specs would likely become stale after the first implementation changes discover concrete package, runtime, and data model constraints.
### Decision 2: Start with development runtime baseline
The first concrete implementation change is `establish-development-runtime-baseline`. It defines the executable skeleton, package managers, local commands, and test/verification entry points before any business capability is implemented.
Alternative considered: start with platform domain APIs. Rejected because there is not yet a runnable backend or frontend baseline to attach tests and browser walkthroughs to.
### Decision 3: Split the stream by dependency, not by team label
Backlog items may touch multiple roots when the contract is cross-cutting, but each item must name its primary root ownership and forbid casual cross-root imports. Shared contracts must be generated, copied through explicit contract packages, or duplicated as documented API contracts until generation exists.
Alternative considered: one backlog per root. Rejected because platform-run protocols, plugin bridge contracts, and frontend API clients require coordinated changes.
### Decision 4: Every concrete change gets a handoff prompt
Each concrete OpenSpec must end with a short implementation handoff containing the change name, exact target, required reads, verification commands, and stopping conditions. The prompt is the practical bridge between chats.
Alternative considered: rely on OpenSpec files alone. Rejected because a new chat needs a compact instruction that prevents it from reopening already-settled scope.
### Decision 5: Closing evidence gates progression
A change is not considered closed until its tasks are checked with evidence. The minimum evidence is `scripts/check-structure.sh` plus `openspec validate <change> --strict`; frontend page changes also require a browser walkthrough, and executable code changes require the relevant tests/builds documented by that change.
Alternative considered: create the next change after implementation edits are made. Rejected because unverified work compounds defects into downstream specs.
## Initial Delivery Queue
| Order | Change | Primary Roots | Purpose |
| --- | --- | --- | --- |
| 0 | `bootstrap-game-server-platform-architecture` | all | Completed architecture baseline and repository skeleton. |
| 1 | `establish-development-runtime-baseline` | all | Add runnable project/tooling baselines and common verification commands. |
| 2 | `implement-platform-core-domain` | `platform/` | Add core domain, DTO, model, repository, service, validator, and route contracts for users, plugins, server instances, AI providers, jobs, artifacts, logs, and audit. |
| 3 | `implement-platform-api-surface` | `platform/` | Add HTTP API handlers, validation, error envelopes, and initial persistence wiring for the core resources. |
| 4 | `implement-ai-provider-management` | `platform/`, `platform_web/` | Store AI provider metadata safely, redact secrets, and expose first-party management APIs and UI. |
| 5 | `implement-run-control-registration` | `run/`, `platform/` | Add run hello, heartbeat, capability, version, and capacity registration. |
| 6 | `implement-run-job-channel` | `run/`, `platform/` | Add job claim, ack, progress, result, cancel, reconcile, and idempotent local journal behavior. |
| 7 | `implement-log-ingest-pipeline` | `run/`, `platform/` | Add local spool, compressed batch upload, sequence ack, retry, and platform log query metadata. |
| 8 | `implement-artifact-transfer-channel` | `run/`, `platform/` | Add chunked, resumable, checksummed, throttled artifact upload/download. |
| 9 | `implement-plugin-registry-and-manifest-validation` | `plugins/`, `platform/` | Validate plugin manifests, register installed game management plugins, and expose marketplace metadata. |
| 10 | `implement-plugin-bridge-and-sdk` | `plugins/`, `platform_web/`, `platform/` | Add safe plugin page bridge, SDK types, scoped platform abilities, and no raw key/run/path exposure. |
| 11 | `implement-platform-web-console-shell` | `platform_web/` | Add frontend app shell, routes, API client structure, theme tokens, and required first-party pages. |
| 12 | `implement-server-management-workflows` | all | Create server instances from plugins, dispatch lifecycle jobs to run, and show job/log/artifact state. |
| 13 | `implement-dev-game-plugin-proof` | `plugins/`, all | Add one development game management plugin proving multi-instance creation, logs, files, jobs, and AI assistance. |
| 14 | `implement-end-to-end-acceptance-suite` | all | Add cross-root acceptance checks and browser walkthrough coverage for the first complete workflow. |
## Risks / Trade-offs
- [Risk] The backlog may need to change after tooling decisions are implemented. Mitigation: update this stream through a new OpenSpec change if ordering or scope materially changes.
- [Risk] A change may grow too large for one chat. Mitigation: split it before implementation and keep the original change as a coordination parent only if needed.
- [Risk] Generated contracts may not exist early. Mitigation: use explicit copied contract files with documented ownership until generation is introduced by its own OpenSpec.
- [Risk] Chat handoff can omit important context. Mitigation: require each handoff to name exact files to read and exact commands to run.
## Migration Plan
1. Validate this stream change and use it as the current implementation queue.
2. Create `establish-development-runtime-baseline` as the first concrete OpenSpec.
3. In a new chat, implement only that change, run its verification, and check its tasks with evidence.
4. After closure, create or refine the next concrete OpenSpec from the queue.
## Open Questions
- Whether the initial persistence backend should be SQLite-first for local development or Postgres-first for production parity remains for the platform API changes.
- Whether log body storage starts as local compressed segments or a query engine adapter remains for the log ingest change.
- Whether run job transport starts as long polling or streaming remains for the run job channel change.
openspec/changes/architecture-delivery-stream/proposal.md
+26
View File
@@ -0,0 +1,26 @@
## Why
The bootstrap architecture is broad enough that implementing it as one large change would make review, verification, and rollback hard. The project needs an explicit OpenSpec delivery stream that breaks the platform, run executor, frontend console, and plugin system into ordered, single-session changes that can be implemented one at a time.
## What Changes
- Add a delivery workflow for creating and implementing architecture OpenSpec changes in dependency order.
- Define a per-change handoff format so each new chat can implement exactly one OpenSpec change without guessing scope.
- Define closing criteria for each implementation chat before the next OpenSpec change is started.
- Define the initial architecture backlog across `platform/`, `run/`, `platform_web/`, and `plugins/`.
- Keep the bootstrap architecture as the baseline and require every follow-up change to reference it instead of redefining product scope.
## Capabilities
### New Capabilities
- `architecture-delivery-workflow`: Ordered OpenSpec backlog, per-change handoff rules, implementation-chat closure criteria, and progress tracking for the full architecture delivery stream.
### Modified Capabilities
- None.
## Impact
- Adds planning artifacts under `openspec/changes/architecture-delivery-stream/`.
- Affects how future OpenSpec changes are created, implemented, validated, and handed off between chats.
- Does not implement backend, run, frontend, or plugin runtime code directly.
- Requires future implementation chats to run `scripts/check-structure.sh` and `openspec validate <change> --strict` before marking work complete.
openspec/changes/architecture-delivery-stream/specs/architecture-delivery-workflow/spec.md
+67
View File
@@ -0,0 +1,67 @@
## ADDED Requirements
### Requirement: Ordered Architecture Backlog
The repository SHALL maintain an ordered architecture delivery backlog that maps each future OpenSpec change to its primary roots, purpose, dependencies, and verification expectations.
#### Scenario: Backlog lists the next architecture change
- **WHEN** a contributor needs the next implementation target
- **THEN** the backlog identifies the next change name, affected roots, and why it follows the previous change
#### Scenario: Backlog preserves bootstrap as baseline
- **WHEN** a follow-up change is planned
- **THEN** it references `bootstrap-game-server-platform-architecture` or archived baseline specs instead of redefining the product scope
### Requirement: Single Active Implementation Change
The delivery workflow SHALL keep only one concrete implementation OpenSpec active at a time unless the user explicitly requests a pause, reprioritization, or parallel track.
#### Scenario: Previous change is not closed
- **WHEN** the current implementation change has unchecked tasks or missing verification evidence
- **THEN** the next concrete implementation change is not started as active work
#### Scenario: User requests a reprioritization
- **WHEN** the user explicitly changes the implementation order
- **THEN** the backlog is updated or superseded before the new active change is implemented
### Requirement: Per-Change Handoff
Each concrete implementation OpenSpec SHALL include a handoff block suitable for a fresh chat, containing the change name, implementation objective, required context files, expected verification commands, and stopping conditions.
#### Scenario: New chat starts implementation
- **WHEN** the user opens a fresh chat for a concrete change
- **THEN** the handoff block gives enough context to implement that change without expanding scope to unrelated backlog items
#### Scenario: Handoff references verification
- **WHEN** the handoff is prepared
- **THEN** it includes `scripts/check-structure.sh`, `openspec validate <change> --strict`, and any change-specific build, test, or browser walkthrough commands
### Requirement: Closure Evidence
Implementation tasks SHALL remain unchecked until the implementing chat records verification evidence for the task or group of tasks.
#### Scenario: Task is completed
- **WHEN** a task checkbox is marked complete
- **THEN** the change records the command, walkthrough, file reference, or artifact that proves the task is complete
#### Scenario: Verification fails
- **WHEN** a required verification command fails
- **THEN** the implementation chat fixes the issue or records the blocker before the change is considered closed
### Requirement: Ownership Boundaries
Each concrete change SHALL name its affected project roots and preserve root ownership boundaries from `AGENTS.md`.
#### Scenario: Change touches multiple roots
- **WHEN** a change updates more than one of `platform/`, `run/`, `platform_web/`, and `plugins/`
- **THEN** the OpenSpec design explains the contract boundary and avoids casual cross-root imports
#### Scenario: Shared contracts are needed
- **WHEN** two roots need the same request, response, or protocol shape
- **THEN** the change uses an explicit contract file, generated artifact, or documented copy boundary rather than importing implementation code across roots
### Requirement: Progress Tracking
The delivery workflow SHALL maintain a progress record for the architecture stream that shows completed, active, pending, paused, and blocked changes.
#### Scenario: Active change completes
- **WHEN** a concrete implementation change is closed
- **THEN** the progress record marks it complete with verification evidence and identifies the next pending change
#### Scenario: Change is split
- **WHEN** a backlog item is too large for one implementation chat
- **THEN** the progress record replaces it with smaller ordered changes and records the reason for the split
openspec/changes/architecture-delivery-stream/tasks.md
+27
View File
@@ -0,0 +1,27 @@
## 1. Stream Artifacts
- [x] 1.1 Create the architecture delivery stream proposal.
- [x] 1.2 Create the delivery stream design with ordered backlog decisions.
- [x] 1.3 Create the delivery workflow spec with backlog, handoff, closure, ownership, and progress requirements.
- [x] 1.4 Create the delivery progress record with queue status and handoff template.
## 2. First Concrete Change
- [x] 2.1 Create the `establish-development-runtime-baseline` OpenSpec change.
- [x] 2.2 Add proposal, design, specs, and tasks for the runtime baseline change.
- [x] 2.3 Add a fresh-chat handoff block to the runtime baseline tasks.
## 3. Verification
- [x] 3.1 Run `scripts/check-structure.sh`.
- [x] 3.2 Run `openspec validate architecture-delivery-stream --strict`.
- [x] 3.3 Run `openspec validate establish-development-runtime-baseline --strict`.
- [x] 3.4 Confirm OpenSpec status shows both changes have required artifacts present.
## Evidence
- `scripts/check-structure.sh`: passed.
- `openspec validate architecture-delivery-stream --strict`: passed.
- `openspec validate establish-development-runtime-baseline --strict`: passed.
- `openspec status --change architecture-delivery-stream --json`: proposal, design, specs, and tasks present.
- `openspec status --change establish-development-runtime-baseline --json`: proposal, design, specs, and tasks present.