Squashed '.vendor/stage-pilot/' changes from 7ab085e..551777b
551777b feat: add interface contract and data model baseline support to bootstrap-baseline f17e086 feat: add bootstrap seed file support to bootstrap-baseline skill be85338 feat: introduce lightweight change path, change-req skill, and release feedback loop 949bb40 docs(skill): new-discovery 병렬 Discovery 및 active-cycle 처리 규칙 강화 7f96130 docs: fix draft-req skill template paths 94b1445 diff --git a/.github/skills/draft-batch-design/SKILL.md b/.github/skills/draft-batch-design/SKILL.md index 5f87d00..944e075 100644 --- a/.github/skills/draft-batch-design/SKILL.md +++ b/.github/skills/draft-batch-design/SKILL.md @@ -1,6 +1,6 @@ --- name: draft-batch-design -description: "Use when: drafting the design document for an existing batch, running /draft-batch-design with a BAT ID, filling docs/batches/<BAT_ID>/design.md, or recording architecture and interface decisions before implementation." +description: "Use when: drafting the design document for an existing batch, running /draft-batch-design with a BAT ID, filling docs/batches/<BAT_ID>/design.md, recording architecture and interface decisions before implementation, or planning updates to docs/project-structure.md and docs/runtime-flows.md." argument-hint: "예: bat-001 또는 docs/batches/bat-001_20260424_scaffold" user-invocable: true --- @@ -9,27 +9,43 @@ user-invocable: true d1ce3ce 프로세스 완전 변경 git-subtree-dir: .vendor/stage-pilot git-subtree-split: 551777bc7009ee133fbaab1267ca324f1dc3c6bb
This commit is contained in:
@@ -0,0 +1,115 @@
|
||||
schema_version: 1
|
||||
capture_mode: declared
|
||||
|
||||
project:
|
||||
repository_name: sample-host-project
|
||||
display_name: Sample Host Project
|
||||
summary: Python-based API service for curated market data analysis.
|
||||
primary_domain: financial analytics
|
||||
|
||||
stack:
|
||||
tech_stack:
|
||||
- Python
|
||||
- FastAPI
|
||||
- PostgreSQL
|
||||
|
||||
runtime:
|
||||
primary_runtime: api-service
|
||||
primary_entrypoints:
|
||||
- name: uvicorn src.main:app
|
||||
purpose: serve the HTTP API
|
||||
- name: python -m src.jobs.refresh_market_data
|
||||
purpose: refresh curated market data snapshots
|
||||
|
||||
interfaces:
|
||||
contracts:
|
||||
- name: HTTP market data API
|
||||
type: http-api
|
||||
actors: internal dashboards and downstream service clients
|
||||
purpose: serve curated market data and derived analytics to clients
|
||||
stability: experimental
|
||||
inputs:
|
||||
- client requests for curated market data and analytics
|
||||
outputs:
|
||||
- JSON market snapshot payloads and derived analytics payloads
|
||||
errors:
|
||||
- 404 not_found :: symbol is not available in the curated dataset
|
||||
- 503 upstream_unavailable :: refreshed data is temporarily unavailable
|
||||
compatibility_rules:
|
||||
- response payload changes should remain backward compatible within the same API version
|
||||
- name: Refresh job command
|
||||
type: cli
|
||||
actors: operators and scheduled automation
|
||||
purpose: update stored market data snapshots from upstream sources
|
||||
stability: internal
|
||||
inputs:
|
||||
- python -m src.jobs.refresh_market_data :: trigger a refresh of curated market data snapshots
|
||||
outputs:
|
||||
- refreshed local snapshot artifacts persisted for later API reads
|
||||
errors:
|
||||
- non-zero exit code :: refresh failed and data should be treated as stale
|
||||
compatibility_rules:
|
||||
- command arguments and exit-code semantics should remain stable for automation callers
|
||||
shared_constraints:
|
||||
- all interfaces assume symbol identifiers are validated before persistence or response rendering
|
||||
- refresh failures must not silently overwrite previously known-good snapshots
|
||||
current_gaps:
|
||||
- authentication and authorization rules are not defined yet
|
||||
- API versioning strategy is still undecided
|
||||
|
||||
structure:
|
||||
planned_top_level_areas:
|
||||
- path: src/
|
||||
responsibility: application code and background jobs
|
||||
- path: scripts/
|
||||
responsibility: developer and operator helper commands
|
||||
- path: tests/
|
||||
responsibility: automated validation and regression coverage
|
||||
|
||||
data_model:
|
||||
persistence_backend: PostgreSQL
|
||||
entities:
|
||||
- name: Market Snapshot
|
||||
purpose: represent the latest curated market data for a tracked symbol
|
||||
source_of_truth: PostgreSQL market_snapshots table
|
||||
lifecycle: collected -> normalized -> published -> superseded
|
||||
key_fields:
|
||||
- symbol :: string :: tracked market identifier
|
||||
- captured_at :: timestamp :: time the upstream data snapshot was collected
|
||||
- payload :: json :: normalized market data stored for API responses and analytics inputs
|
||||
relationships:
|
||||
- Analytics Snapshot :: derived from one published Market Snapshot
|
||||
state_rules:
|
||||
- only one published snapshot per symbol should be treated as current
|
||||
- superseded snapshots remain queryable for audit or replay use cases
|
||||
- name: Analytics Snapshot
|
||||
purpose: represent derived metrics computed from a market snapshot
|
||||
source_of_truth: PostgreSQL analytics_snapshots table
|
||||
lifecycle: queued -> computed -> published -> superseded
|
||||
key_fields:
|
||||
- symbol :: string :: tracked market identifier
|
||||
- derived_at :: timestamp :: time analytics were computed
|
||||
- metrics :: json :: derived indicators and summary values
|
||||
relationships:
|
||||
- Market Snapshot :: source snapshot used to compute analytics
|
||||
state_rules:
|
||||
- published analytics must reference an existing published or superseded market snapshot
|
||||
- analytics should be recomputed whenever a new published market snapshot replaces the current one
|
||||
consistency_rules:
|
||||
- symbol identifiers must remain consistent across snapshot and analytics entities
|
||||
- analytics records must not exist without a corresponding source market snapshot
|
||||
persistence_notes:
|
||||
- refresh jobs write Market Snapshot rows before recomputing Analytics Snapshot rows
|
||||
- future retention and archival policies are not defined yet
|
||||
current_gaps:
|
||||
- exact table schema and indexing strategy are still undecided
|
||||
- historical retention policy is still undecided
|
||||
|
||||
notes:
|
||||
known_unknowns:
|
||||
- deployment target is undecided
|
||||
|
||||
metadata:
|
||||
captured_at_kst: 2026-04-30 16:20
|
||||
source: bootstrap-baseline-questionnaire
|
||||
updated_from: user-answer
|
||||
@@ -0,0 +1,38 @@
|
||||
# Bootstrap Baseline Example
|
||||
|
||||
이 예시는 fresh host 저장소에 StagePilot을 설치한 뒤 `/bootstrap-baseline`을 실행했을 때 남아야 하는 최소 active baseline 상태를 보여 준다.
|
||||
|
||||
## Scenario
|
||||
|
||||
1. host 저장소에 StagePilot을 설치했다.
|
||||
2. 아직 Discovery, REQ, Batch, Release 문서는 하나도 없었다.
|
||||
3. doctor를 실행하면 `INFO [bootstrap-required]`로 `/bootstrap-baseline`이 필요하다는 안내가 나온다.
|
||||
4. `/bootstrap-baseline`이 최소 질문 세트를 받고 `.stagepilot/bootstrap/baseline.yaml`을 만든 뒤 baseline 문서와 active index를 초기화했다.
|
||||
5. 첫 real Discovery는 아직 시작하지 않았고, 이 예시는 그 직후 상태를 보여 준다.
|
||||
|
||||
## Files to inspect
|
||||
|
||||
- `doctor-before-bootstrap-output.md`
|
||||
- bootstrap 이전 fresh host 저장소에서 기대하는 doctor 출력 예시다.
|
||||
- `bootstrap-baseline-output.md`
|
||||
- `/bootstrap-baseline` 실행 결과 예시다.
|
||||
- `.stagepilot/bootstrap/baseline.yaml`
|
||||
- bootstrap 질문 답변을 저장한 seed file 예시다.
|
||||
- `docs/project-structure.md`
|
||||
- bootstrap으로 생성된 구조 baseline 초안 예시다.
|
||||
- `docs/runtime-flows.md`
|
||||
- bootstrap으로 생성된 runtime flow baseline 초안 예시다.
|
||||
- `docs/interface-contract.md`
|
||||
- bootstrap으로 생성된 인터페이스 계약 baseline 초안 예시다.
|
||||
- `docs/data-model.md`
|
||||
- bootstrap으로 생성된 데이터 모델 baseline 초안 예시다.
|
||||
- `docs/discovery/index.md`, `docs/srs/index.md`, `docs/batches/index.md`, `docs/releases/index.md`
|
||||
- 첫 real Discovery 전까지 비어 있어도 되는 register 골격이다.
|
||||
|
||||
## Validation
|
||||
|
||||
이 예시 루트는 doctor로 독립 검증할 수 있다.
|
||||
|
||||
```bash
|
||||
python3 .github/scripts/stagepilot-doctor.py examples/bootstrap-baseline
|
||||
```
|
||||
@@ -0,0 +1,45 @@
|
||||
# Sample Output: bootstrap-baseline
|
||||
|
||||
- Input:
|
||||
- fresh host repository after StagePilot install
|
||||
- Asked Questions:
|
||||
- `project-summary` -> `Python-based API service for curated market data analysis`
|
||||
- `primary-domain` -> `financial analytics`
|
||||
- `tech-stack` -> `Python, FastAPI, PostgreSQL`
|
||||
- `primary-runtime` -> `api-service`
|
||||
- `primary-entrypoints` -> `uvicorn src.main:app :: serve the HTTP API`, `python -m src.jobs.refresh_market_data :: refresh curated market data snapshots`
|
||||
- `interface-contracts` -> `HTTP market data API :: http-api :: internal dashboards and downstream service clients :: serve curated market data and derived analytics to clients`, `Refresh job command :: cli :: operators and scheduled automation :: update stored market data snapshots from upstream sources`
|
||||
- `interface-inputs` -> `HTTP market data API :: GET /markets/{symbol} :: request the current curated snapshot for a symbol`, `HTTP market data API :: GET /analytics/{symbol} :: request derived analytics for a symbol`, `Refresh job command :: python -m src.jobs.refresh_market_data :: trigger a refresh of curated market data snapshots`
|
||||
- `interface-outputs` -> `HTTP market data API :: JSON market snapshot payload :: current normalized market data for the requested symbol`, `HTTP market data API :: JSON analytics payload :: derived analytics and summary metrics for the requested symbol`, `Refresh job command :: refreshed local snapshot artifacts :: normalized data persisted for later API reads`
|
||||
- `interface-errors` -> `HTTP market data API :: 404 not_found :: symbol is not available in the curated dataset`, `HTTP market data API :: 503 upstream_unavailable :: refreshed data is temporarily unavailable`, `Refresh job command :: non-zero exit code :: refresh failed and data should be treated as stale`
|
||||
- `core-entities` -> `Market Snapshot :: represent the latest curated market data for a tracked symbol`, `Analytics Snapshot :: represent derived metrics computed from a market snapshot`
|
||||
- `persistence-backend` -> `PostgreSQL`
|
||||
- `compatibility-rules` -> `HTTP market data API :: response payload changes should remain backward compatible within the same API version`, `Refresh job command :: command arguments and exit-code semantics should remain stable for automation callers`
|
||||
- Created Files:
|
||||
- `.stagepilot/bootstrap/baseline.yaml`
|
||||
- `docs/discovery/index.md`
|
||||
- `docs/srs/index.md`
|
||||
- `docs/batches/index.md`
|
||||
- `docs/releases/index.md`
|
||||
- `docs/project-structure.md`
|
||||
- `docs/runtime-flows.md`
|
||||
- `docs/interface-contract.md`
|
||||
- `docs/data-model.md`
|
||||
- Seed Status:
|
||||
- `.stagepilot/bootstrap/baseline.yaml`: created
|
||||
- Baseline Status:
|
||||
- `docs/project-structure.md`: created
|
||||
- `docs/runtime-flows.md`: created
|
||||
- `docs/interface-contract.md`: created
|
||||
- `docs/data-model.md`: created
|
||||
- Index Status:
|
||||
- `docs/discovery/index.md`: created
|
||||
- `docs/srs/index.md`: created
|
||||
- `docs/batches/index.md`: created
|
||||
- `docs/releases/index.md`: created
|
||||
- Notes:
|
||||
- baseline docs were rendered from `.stagepilot/bootstrap/baseline.yaml`
|
||||
- no Discovery document was created
|
||||
- no REQ, Batch, or Release unit was opened
|
||||
- Next Action:
|
||||
- `/new-discovery <actual product or service change topic>`
|
||||
@@ -0,0 +1,6 @@
|
||||
# Batch Index
|
||||
|
||||
## Batch Register
|
||||
|
||||
| BAT ID | Profile | Status | Included REQ | Discovery | Folder |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
@@ -0,0 +1,97 @@
|
||||
# Sample Host Project Data Model
|
||||
|
||||
- Baseline Mode: declared
|
||||
- Baseline Seed: .stagepilot/bootstrap/baseline.yaml
|
||||
- Status: confirmed
|
||||
- Owner: Platform Team
|
||||
- Last Updated (KST): 2026-04-30 16:30
|
||||
- Source Discovery / Batch: bootstrap-baseline
|
||||
|
||||
## Project Summary
|
||||
- Python-based API service for curated market data analysis.
|
||||
|
||||
## Primary Domain
|
||||
- financial analytics
|
||||
|
||||
## Primary Persistence Backend
|
||||
- PostgreSQL
|
||||
|
||||
## Purpose
|
||||
- This document captures the initial data model baseline after StagePilot bootstrap.
|
||||
- It provides a shared reference for later REQ, delivery, migration, and verification work.
|
||||
|
||||
## Scope
|
||||
- Covers core entities, relationships, lifecycle rules, and persistence assumptions for the sample host project.
|
||||
- Does not replace ORM code, migrations, or detailed acceptance criteria.
|
||||
|
||||
## Model Summary
|
||||
|
||||
- Market Snapshot :: normalized raw and curated market data for a tracked symbol
|
||||
- Analytics Snapshot :: derived metrics computed from a Market Snapshot
|
||||
|
||||
## Entity: `Market Snapshot`
|
||||
|
||||
- Purpose: represent the latest curated market data for a tracked symbol
|
||||
- Source of Truth: PostgreSQL `market_snapshots` table
|
||||
- Lifecycle: collected -> normalized -> published -> superseded
|
||||
|
||||
### Key Fields
|
||||
|
||||
- `symbol` :: string :: tracked market identifier
|
||||
- `captured_at` :: timestamp :: time the upstream data snapshot was collected
|
||||
- `payload` :: json :: normalized market data stored for API responses and analytics inputs
|
||||
|
||||
### Relationships
|
||||
|
||||
- `Analytics Snapshot` :: derived from one published Market Snapshot
|
||||
|
||||
### State Rules
|
||||
|
||||
- only one published snapshot per symbol should be treated as current
|
||||
- superseded snapshots remain queryable for audit or replay use cases
|
||||
|
||||
## Entity: `Analytics Snapshot`
|
||||
|
||||
- Purpose: represent derived metrics calculated from a market snapshot
|
||||
- Source of Truth: PostgreSQL `analytics_snapshots` table
|
||||
- Lifecycle: queued -> computed -> published -> superseded
|
||||
|
||||
### Key Fields
|
||||
|
||||
- `symbol` :: string :: tracked market identifier
|
||||
- `derived_at` :: timestamp :: time analytics were computed
|
||||
- `metrics` :: json :: derived indicators and summary values
|
||||
|
||||
### Relationships
|
||||
|
||||
- `Market Snapshot` :: source snapshot used to compute analytics
|
||||
|
||||
### State Rules
|
||||
|
||||
- published analytics must reference an existing published or superseded market snapshot
|
||||
- analytics should be recomputed whenever a new published market snapshot replaces the current one
|
||||
|
||||
## Shared Consistency Rules
|
||||
|
||||
- `symbol` identifiers must remain consistent across snapshot and analytics entities
|
||||
- analytics records must not exist without a corresponding source market snapshot
|
||||
|
||||
## Persistence / Integration Notes
|
||||
|
||||
- refresh jobs write Market Snapshot rows before recomputing Analytics Snapshot rows
|
||||
- future retention and archival policies are not defined yet
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
- exact table schema and indexing strategy are still undecided
|
||||
- historical retention policy is still undecided
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when a core entity, key field, or relationship changes.
|
||||
- Update this document when lifecycle or persistence behavior changes.
|
||||
- Update this document when a batch introduces a migration, backfill, or breaking data assumption.
|
||||
|
||||
## Change Log
|
||||
|
||||
- 2026-04-30: bootstrap-baseline created the initial data model baseline from declared project inputs.
|
||||
@@ -0,0 +1,8 @@
|
||||
# Discovery 전체 인덱스
|
||||
|
||||
<!-- 아래 테이블은 /new-discovery 실행 시 자동 갱신된다. 수동 편집 금지. -->
|
||||
|
||||
## Discovery 목록
|
||||
|
||||
| ID | 날짜 | 이슈명 | 문서 | 상태 |
|
||||
|---|---|---|---|---|
|
||||
@@ -0,0 +1,97 @@
|
||||
# Sample Host Project Interface Contract
|
||||
|
||||
- Baseline Mode: declared
|
||||
- Baseline Seed: .stagepilot/bootstrap/baseline.yaml
|
||||
- Status: confirmed
|
||||
- Owner: Platform Team
|
||||
- Last Updated (KST): 2026-04-30 16:30
|
||||
- Source Discovery / Batch: bootstrap-baseline
|
||||
- Primary Runtime: api-service
|
||||
|
||||
## Project Summary
|
||||
- Python-based API service for curated market data analysis.
|
||||
|
||||
## Primary Domain
|
||||
- financial analytics
|
||||
|
||||
## Purpose
|
||||
- This document captures the initial interface contract baseline after StagePilot bootstrap.
|
||||
- It provides a shared reference for future REQ, design, implementation, and verification work.
|
||||
|
||||
## Scope
|
||||
- Covers the planned API and job interfaces exposed by the sample host project.
|
||||
- Does not duplicate detailed acceptance criteria or generated OpenAPI/schema artifacts.
|
||||
|
||||
## Interface Summary
|
||||
|
||||
- HTTP market data API :: serve curated market data and derived analytics to clients
|
||||
- Refresh job command :: update stored market data snapshots from upstream sources
|
||||
|
||||
## Interface: `HTTP market data API`
|
||||
|
||||
- Type: http-api
|
||||
- Consumers / Producers: internal dashboards and downstream service clients
|
||||
- Purpose: serve curated market data and derived analytics to clients
|
||||
- Stability: experimental
|
||||
|
||||
### Inputs
|
||||
|
||||
- `GET /markets/{symbol}` :: request the current curated snapshot for a symbol
|
||||
- `GET /analytics/{symbol}` :: request derived analytics for a symbol
|
||||
|
||||
### Outputs
|
||||
|
||||
- JSON market snapshot payload :: current normalized market data for the requested symbol
|
||||
- JSON analytics payload :: derived analytics and summary metrics for the requested symbol
|
||||
|
||||
### Error Contract
|
||||
|
||||
- `404 not_found` :: symbol is not available in the curated dataset
|
||||
- `503 upstream_unavailable` :: refreshed data is temporarily unavailable
|
||||
|
||||
### Compatibility Rules
|
||||
|
||||
- response payload changes should remain backward compatible within the same API version
|
||||
|
||||
## Interface: `Refresh job command`
|
||||
|
||||
- Type: cli
|
||||
- Consumers / Producers: operators and scheduled automation
|
||||
- Purpose: update stored market data snapshots from upstream sources
|
||||
- Stability: internal
|
||||
|
||||
### Inputs
|
||||
|
||||
- `python -m src.jobs.refresh_market_data` :: trigger a refresh of curated market data snapshots
|
||||
|
||||
### Outputs
|
||||
|
||||
- refreshed local snapshot artifacts :: normalized data persisted for later API reads
|
||||
|
||||
### Error Contract
|
||||
|
||||
- non-zero exit code :: refresh failed and data should be treated as stale
|
||||
|
||||
### Compatibility Rules
|
||||
|
||||
- command arguments and exit-code semantics should remain stable for automation callers
|
||||
|
||||
## Shared Constraints
|
||||
|
||||
- all interfaces assume symbol identifiers are validated before persistence or response rendering
|
||||
- refresh failures must not silently overwrite previously known-good snapshots
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
- authentication and authorization rules are not defined yet
|
||||
- API versioning strategy is still undecided
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when an externally visible API, event, CLI, or file contract changes.
|
||||
- Update this document when a batch changes compatibility, validation, or error behavior.
|
||||
- Update this document when a new external consumer or producer is introduced.
|
||||
|
||||
## Change Log
|
||||
|
||||
- 2026-04-30: bootstrap-baseline created the initial interface contract baseline from declared project inputs.
|
||||
@@ -0,0 +1,91 @@
|
||||
# Sample Host Project Structure
|
||||
|
||||
- Baseline Mode: declared
|
||||
- Baseline Seed: .stagepilot/bootstrap/baseline.yaml
|
||||
- Status: confirmed
|
||||
- Owner: Platform Team
|
||||
- Last Updated (KST): 2026-04-30 16:30
|
||||
- Source Discovery / Batch: bootstrap-baseline
|
||||
|
||||
## Project Summary
|
||||
- Python-based API service for curated market data analysis.
|
||||
|
||||
## Primary Domain
|
||||
- financial analytics
|
||||
|
||||
## Tech Stack
|
||||
- Python
|
||||
- FastAPI
|
||||
- PostgreSQL
|
||||
|
||||
## Primary Runtime
|
||||
- Type: api-service
|
||||
- Planned Entry Points:
|
||||
- uvicorn src.main:app :: serve the HTTP API
|
||||
- python -m src.jobs.refresh_market_data :: refresh curated market data snapshots
|
||||
|
||||
## Purpose
|
||||
- This document captures the initial repository structure baseline after StagePilot bootstrap.
|
||||
- It becomes a shared reference before the first real Discovery starts.
|
||||
|
||||
## Scope
|
||||
- Covers top-level repository layout and broad module boundaries.
|
||||
- Does not define feature-specific acceptance criteria or delivery units.
|
||||
|
||||
## Top-Level Structure
|
||||
|
||||
```text
|
||||
.
|
||||
├── .github/
|
||||
├── .stagepilot/
|
||||
├── docs/
|
||||
├── src/
|
||||
├── scripts/
|
||||
├── tests/
|
||||
└── README.md
|
||||
```
|
||||
|
||||
## Package / Module Responsibilities
|
||||
|
||||
- `.github/`
|
||||
- StagePilot skills, templates, and host instructions installed into the repository.
|
||||
- `.stagepilot/`
|
||||
- bootstrap declaration seed used to render the baseline documents.
|
||||
- `docs/`
|
||||
- Active SDLC docs, index files, and cross-cutting baseline references.
|
||||
- `src/`
|
||||
- Product and service implementation code.
|
||||
- `scripts/`
|
||||
- developer and operator helper commands.
|
||||
- `tests/`
|
||||
- Automated checks and regression coverage.
|
||||
|
||||
## Dependency Rules
|
||||
|
||||
- Delivery documents under `docs/` must not be treated as implementation modules.
|
||||
- `src/` can evolve independently, but structure changes should update this baseline.
|
||||
- `.stagepilot/bootstrap/baseline.yaml` should be updated when the declared project identity changes before code exists.
|
||||
- Tooling automation under `.github/` must not overwrite host source code.
|
||||
|
||||
## Shared Boundaries
|
||||
|
||||
- `.github/` provides SDLC workflow assets.
|
||||
- `.stagepilot/` stores bootstrap declarations outside active SDLC units.
|
||||
- `docs/` is the source of truth for active SDLC state.
|
||||
- `src/`, `scripts/`, and `tests/` remain host-project owned implementation surfaces.
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
- The first real Discovery has not been created yet.
|
||||
- Deployment target is still undecided.
|
||||
- Actual domain module boundaries will be refined once the first delivery topic is defined.
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when top-level directories change.
|
||||
- Update this document when module ownership boundaries change.
|
||||
- Update this document when a batch changes the approved structure baseline.
|
||||
|
||||
## Change Log
|
||||
|
||||
- 2026-04-30: bootstrap-baseline created the initial repository structure baseline from `.stagepilot/bootstrap/baseline.yaml`.
|
||||
@@ -0,0 +1,6 @@
|
||||
# Release Index
|
||||
|
||||
## Release Register
|
||||
|
||||
| REL ID | Profile | Status | Included Batch | Discovery/REQ Input | Link |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
@@ -0,0 +1,68 @@
|
||||
# Sample Host Project Runtime Flows
|
||||
|
||||
- Baseline Mode: declared
|
||||
- Baseline Seed: .stagepilot/bootstrap/baseline.yaml
|
||||
- Status: confirmed
|
||||
- Owner: Platform Team
|
||||
- Last Updated (KST): 2026-04-30 16:30
|
||||
- Source Discovery / Batch: bootstrap-baseline
|
||||
- Primary Runtime: api-service
|
||||
|
||||
## Project Summary
|
||||
- Python-based API service for curated market data analysis.
|
||||
|
||||
## Purpose
|
||||
- This document captures the initial command and runtime flow baseline after StagePilot bootstrap.
|
||||
- It gives later Discovery and Batch work a stable reference before product-specific flows exist.
|
||||
|
||||
## Scope
|
||||
- Covers bootstrap, discovery start, and validation entry points.
|
||||
- Does not define detailed feature behavior.
|
||||
|
||||
## Covered Entry Points
|
||||
|
||||
- uvicorn src.main:app :: serve the HTTP API
|
||||
- python -m src.jobs.refresh_market_data :: refresh curated market data snapshots
|
||||
- Copilot Chat /bootstrap-baseline :: initialize declared baseline docs
|
||||
|
||||
## Shared Components
|
||||
|
||||
- .stagepilot/bootstrap/baseline.yaml
|
||||
- `.github/skills/`
|
||||
- `docs/project-structure.md`
|
||||
- `docs/*/index.md`
|
||||
|
||||
## Flow: `bootstrap baseline initialization`
|
||||
|
||||
1. StagePilot assets are installed into the host repository.
|
||||
2. `/bootstrap-baseline` collects the minimum declaration set and writes `.stagepilot/bootstrap/baseline.yaml`.
|
||||
3. baseline docs and active index skeletons are rendered from that seed.
|
||||
4. The repository becomes ready for the first real Discovery.
|
||||
|
||||
## Flow: `planned host runtime`
|
||||
|
||||
1. Operator starts `uvicorn src.main:app` to serve the planned HTTP API.
|
||||
2. Background refresh can run with `python -m src.jobs.refresh_market_data`.
|
||||
3. Detailed production flows remain subject to later Discovery and delivery work.
|
||||
|
||||
## Flow Constraints
|
||||
|
||||
- Fresh host repositories should complete baseline initialization before the first real Discovery.
|
||||
- Declared runtime assumptions must stay in sync with `.stagepilot/bootstrap/baseline.yaml` until observed implementation evidence exists.
|
||||
- Structure or orchestration changes must update this document or `docs/project-structure.md`.
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
- Product-specific runtime orchestration is not defined yet.
|
||||
- Deployment target is undecided.
|
||||
- Delivery and release flows will be added by later Discovery and Batch work.
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when command entry points change.
|
||||
- Update this document when runtime orchestration changes.
|
||||
- Update this document when a batch changes the approved flow baseline.
|
||||
|
||||
## Change Log
|
||||
|
||||
- 2026-04-30: bootstrap-baseline created the initial runtime flow baseline from `.stagepilot/bootstrap/baseline.yaml`.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Software Requirement Specification Index
|
||||
|
||||
## 목적
|
||||
- 이 문서는 bootstrap-baseline 직후의 requirement register 골격 예시다.
|
||||
- 첫 real Discovery 이후 `draft-req`가 실제 requirement를 추가한다.
|
||||
|
||||
## Next Requirement ID
|
||||
|
||||
- Current: `REQ-001`
|
||||
- Rule: `Requirement Register`에 있는 가장 큰 REQ 번호보다 정확히 1 커야 한다.
|
||||
|
||||
## Requirement Register
|
||||
|
||||
| ID | Title | Type | Status | Priority | Owner | Link |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## Recent Change Log Summary
|
||||
|
||||
- none
|
||||
@@ -0,0 +1,9 @@
|
||||
# Sample Output: doctor before bootstrap-baseline
|
||||
|
||||
fresh host 저장소에서 아직 baseline이 초기화되지 않은 경우 doctor는 아래처럼 bootstrap 안내를 함께 출력한다.
|
||||
|
||||
```text
|
||||
WARN [missing-active-docs] .: No active SDLC docs were found under docs/. Workspace-specific checks were skipped.
|
||||
INFO [bootstrap-required] .: Fresh host repos should run /bootstrap-baseline in Copilot Chat before the first real Discovery. Missing bootstrap files: docs/discovery/index.md, docs/srs/index.md, docs/batches/index.md, docs/releases/index.md, docs/project-structure.md, docs/runtime-flows.md
|
||||
stagepilot-doctor: 0 error(s), 1 warning(s), 1 info message(s)
|
||||
```
|
||||
@@ -0,0 +1,32 @@
|
||||
# P3 Example: change-req and suggest-next-discovery
|
||||
|
||||
이 예시는 release feedback 이후 개선 루프를 어떻게 닫는지 보여 주는 self-contained sample workspace다.
|
||||
|
||||
## Scenario
|
||||
|
||||
1. `rel-001` 배포가 `feedback-captured` 상태로 닫혔다.
|
||||
2. 운영 피드백에서 두 종류의 후속 작업이 나왔다.
|
||||
- 기존 REQ 강화: 문서 release checklist의 acceptance criteria를 더 엄격하게 바꿔야 한다.
|
||||
- 신규 반복 후보: release feedback를 기반으로 follow-up triage를 자동 추천하는 개선이 필요하다.
|
||||
3. `suggest-next-discovery rel-001`는 위 두 항목을 각각 `change-req`와 `new-discovery`로 분류한다.
|
||||
4. 이 예시의 active docs는 그 결과 `change-req req-001`를 이미 한 번 적용한 뒤의 상태를 보여 준다.
|
||||
|
||||
## Files to inspect
|
||||
|
||||
- `docs/releases/rel-001_20260428_docs_release_hardening.md`
|
||||
- `Feedback Handoff`에 `Discovery Input`, `REQ Input`, `Change Request Input`이 모두 있다.
|
||||
- `docs/srs/Documentation/req-001_docs_release_checklist.md`
|
||||
- 두 번째 `Change Log` 항목이 `change-req` 실행 결과를 나타낸다.
|
||||
- 구현 근거가 무효화되어 상태가 `Approved`로 되돌아간 상태다.
|
||||
- `suggest-next-discovery-output.md`
|
||||
- `suggest-next-discovery rel-001`의 예시 결과다.
|
||||
- `change-req-output.md`
|
||||
- `change-req req-001`의 예시 결과다.
|
||||
|
||||
## Validation
|
||||
|
||||
이 예시 루트는 doctor로 독립 검증할 수 있다.
|
||||
|
||||
```bash
|
||||
python3 .github/scripts/stagepilot-doctor.py examples/p3-change-management
|
||||
```
|
||||
@@ -0,0 +1,22 @@
|
||||
# Sample Output: change-req req-001
|
||||
|
||||
- Target REQ: `docs/srs/Documentation/req-001_docs_release_checklist.md`
|
||||
- New Change Entry: `CHG-2026-04-30-02` represented as `CHG-20260430-02`
|
||||
- Change Summary:
|
||||
- docs-only release profile에서도 broken-link 검증을 필수 acceptance criteria로 승격
|
||||
- delivery trace에 기존 batch/release 영향과 재검증 필요 여부를 추가
|
||||
- Impacted Delivery Trace:
|
||||
- Batches: `bat-001`
|
||||
- Releases: `rel-001`
|
||||
- Revalidation Impact:
|
||||
- Reverification Needed: `yes`
|
||||
- Existing Implementation Invalidated: `yes`
|
||||
- Status Recommendation: `revert-to-approved`
|
||||
- Result:
|
||||
- REQ status changed from `Implemented` to `Approved`
|
||||
- `docs/srs/index.md` register status changed to `Approved`
|
||||
- `Recent Change Log Summary` updated with the new change entry
|
||||
|
||||
## Rationale
|
||||
|
||||
이 변경은 기존 release evidence만으로는 새 acceptance criteria를 충족했다고 볼 수 없으므로 `Implemented` 상태를 유지할 수 없다. 따라서 REQ는 `Approved`로 되돌아가고, 후속 batch verification을 다시 거쳐야 한다.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
# bat-001 Design
|
||||
|
||||
- Status: confirmed
|
||||
|
||||
## Architecture Summary
|
||||
- docs-only release는 app-service health signal 대신 문서 품질 증거를 사용한다.
|
||||
|
||||
## Changed Areas
|
||||
- release template
|
||||
- feedback handoff structure
|
||||
|
||||
## Key Decisions
|
||||
- docs-only release는 broken-link와 release note update를 핵심 evidence로 남긴다.
|
||||
|
||||
## Edge Cases
|
||||
- release 후 feedback로 acceptance criteria가 강화되면 REQ 상태를 되돌릴 수 있다.
|
||||
|
||||
## Architecture Impact
|
||||
- runtime-flows
|
||||
|
||||
## Reference Doc Update Plan
|
||||
- project-structure.md: none
|
||||
- runtime-flows.md: docs-only release feedback flow 반영
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
# bat-001 Implementation
|
||||
|
||||
- Status: completed
|
||||
- Batch: bat-001
|
||||
|
||||
## Plan Summary
|
||||
- release template와 docs-only verification structure를 구현했다.
|
||||
|
||||
## Changed Files
|
||||
- .github/templates/releases/release.md
|
||||
- README.md
|
||||
|
||||
## Execution Log
|
||||
1. docs-only release profile 섹션 추가
|
||||
2. feedback handoff를 Discovery/REQ로 나누어 기록
|
||||
|
||||
## Validation
|
||||
- manual release review
|
||||
- doctor sample workspace check
|
||||
|
||||
## Remaining Risks
|
||||
- 후속 feedback가 REQ 변경으로 이어질 수 있다.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
# bat-001: docs release hardening
|
||||
|
||||
- Status: released
|
||||
- Profile: standard
|
||||
- Source Discovery: dcy-001
|
||||
- Included REQ: req-001
|
||||
- Excluded REQ: 없음
|
||||
|
||||
## Summary
|
||||
- docs-only release checklist를 requirement와 release evidence로 연결하는 batch다.
|
||||
|
||||
## Scope
|
||||
- In Scope:
|
||||
- release template update
|
||||
- docs-only verification structure
|
||||
- Out of Scope:
|
||||
- runtime health checks
|
||||
|
||||
## Documents
|
||||
- Planning: [planning.md](./planning.md)
|
||||
- Design: [design.md](./design.md)
|
||||
- Implementation: [implementation.md](./implementation.md)
|
||||
- Verification: [verification.md](./verification.md)
|
||||
|
||||
## Notes
|
||||
- release feedback 이후 req-001이 다시 `Approved`로 되돌아갔다.
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# bat-001 Planning
|
||||
|
||||
- Status: confirmed
|
||||
- Batch: bat-001
|
||||
- Profile: standard
|
||||
|
||||
## Included REQ
|
||||
- req-001
|
||||
|
||||
## Delivery Plan
|
||||
- release template와 docs-only release evidence 구조를 정리한다.
|
||||
|
||||
## Dependencies
|
||||
- Internal:
|
||||
- release template
|
||||
- README validation guide
|
||||
- External:
|
||||
- none
|
||||
|
||||
## Design Gate
|
||||
- Design Required Before Implementation: yes
|
||||
- Reason: docs-only release profile과 evidence structure를 새로 정의해야 한다.
|
||||
|
||||
## Milestones
|
||||
1. release template 정리
|
||||
2. release evidence 반영
|
||||
3. feedback handoff 확인
|
||||
|
||||
## Risks
|
||||
- docs-only validation 기준이 release 후 강화될 수 있다.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
# bat-001 Verification
|
||||
|
||||
- Status: confirmed
|
||||
- Batch: bat-001
|
||||
|
||||
## Acceptance Mapping
|
||||
- req-001:
|
||||
- AC1 -> docs-only release checklist evidence
|
||||
- AC2 -> feedback handoff structure
|
||||
|
||||
## Evidence
|
||||
- Test:
|
||||
- doctor sample validation passed before release
|
||||
- Manual:
|
||||
- docs-only release note and checklist reviewed
|
||||
- Logs:
|
||||
- release review notes
|
||||
|
||||
## Result
|
||||
- Ready for Release: true
|
||||
- Blocking Issues:
|
||||
- 없음
|
||||
@@ -0,0 +1,7 @@
|
||||
# Batch Index
|
||||
|
||||
## Batch Register
|
||||
|
||||
| BAT ID | Profile | Status | Included REQ | Discovery | Folder |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| bat-001 | standard | released | req-001 | dcy-001 | [batch](./bat-001_20260427_docs_release_hardening) |
|
||||
+149
@@ -0,0 +1,149 @@
|
||||
# Discovery
|
||||
|
||||
- 상태: confirmed
|
||||
- 문서 ID: dcy-001_20260425_docs_release_quality_loop
|
||||
- 이슈명: Docs release quality loop
|
||||
- 작성 시각(KST): 2026-04-25 10:00
|
||||
- 마지막 갱신 시각(KST): 2026-04-30 13:00
|
||||
- 대체됨: 없음
|
||||
- 후속 Discovery 참조: 없음
|
||||
- 생성된 REQ 참조: req-001
|
||||
|
||||
# 1. 계획 상태 요약
|
||||
|
||||
- 연계 문서 현황:
|
||||
- 관련 점수 파일: 미생성
|
||||
- 관련 TODO/메모: 없음
|
||||
- 해석:
|
||||
- docs-only release에서도 문서 검증 품질이 release 판단 근거에 직접 연결돼야 한다.
|
||||
- 운영 피드백으로 checklist 강화를 반복적으로 흡수할 수 있어야 한다.
|
||||
|
||||
# 2. 요구사항 판정 결과
|
||||
|
||||
- 판정: 신규
|
||||
- 근거
|
||||
- 기존 release checklist는 docs-only profile 세분화 기준이 부족했다.
|
||||
- follow-up feedback를 기존 REQ와 연결할 필요가 있었다.
|
||||
|
||||
# 3. 문제점의 요약
|
||||
|
||||
- 현재 상태
|
||||
- docs release는 수동 검토 메모에 의존한다.
|
||||
- broken-link 점검과 release note 점검이 acceptance criteria로 명확히 드러나지 않는다.
|
||||
- 기대 상태
|
||||
- release checklist가 명시적 acceptance criteria와 evidence로 연결된다.
|
||||
- 운영 피드백이 후속 REQ 또는 Discovery로 자연스럽게 이어진다.
|
||||
- 이해관계자
|
||||
- maintainer
|
||||
- reviewer
|
||||
- docs consumer
|
||||
- 제약사항
|
||||
- 문서 패키지는 app-service 운영 지표를 사용하지 않는다.
|
||||
- doctor 검증과 release 문서만으로도 추적 가능해야 한다.
|
||||
|
||||
## 주요 사용자 시나리오
|
||||
|
||||
- maintainer가 docs-only release 전 broken-link와 release note 상태를 확인한다.
|
||||
- reviewer가 release feedback를 보고 기존 REQ 변경인지 신규 반복인지 판단한다.
|
||||
|
||||
# 4. 이번에 정의할 변경
|
||||
|
||||
- docs release checklist를 REQ와 release evidence에 연결한다.
|
||||
- feedback handoff에서 후속 작업 분류 기준을 남긴다.
|
||||
|
||||
## 영향 범위
|
||||
|
||||
- 코드 영향:
|
||||
- 없음
|
||||
- 문서 영향:
|
||||
- docs/srs/Documentation/req-001_docs_release_checklist.md
|
||||
- docs/releases/rel-001_20260428_docs_release_hardening.md
|
||||
- 운영 영향:
|
||||
- docs-only release review 절차 강화
|
||||
|
||||
# 5. 요구사항 목록
|
||||
|
||||
## 기능 요구사항
|
||||
- FR-1: docs-only release는 broken-link 검증을 acceptance criteria로 포함해야 한다.
|
||||
- FR-2: release feedback는 후속 Discovery/REQ/change-req 입력으로 분리되어야 한다.
|
||||
|
||||
## 비기능 요구사항
|
||||
- NFR-1: 변경 이력은 Change Log와 release feedback 양쪽에서 추적 가능해야 한다.
|
||||
|
||||
## 범위 경계
|
||||
- In Scope
|
||||
- docs release checklist
|
||||
- feedback handoff structure
|
||||
- Out of Scope
|
||||
- app-service runtime health check
|
||||
- 외부 배포 자동화
|
||||
|
||||
# 6. 리스크/가정 목록
|
||||
|
||||
## 리스크
|
||||
- R-1 (Medium): checklist 강화 시 기존 구현 증거가 부족해질 수 있다.
|
||||
- 완화 방안: change-req로 상태 되돌림과 재검증 계획을 남긴다.
|
||||
- R-2 (Low): feedback 분류가 모호하면 follow-up 경로가 섞일 수 있다.
|
||||
- 완화 방안: suggest-next-discovery에서 분류 근거를 명시한다.
|
||||
|
||||
## 가정
|
||||
- A-1: docs-only release는 doctor와 수동 리뷰 결과로 검증 가능하다.
|
||||
- A-2: feedback handoff는 release 문서가 source of truth다.
|
||||
|
||||
# 7. 초기 성공 기준
|
||||
|
||||
- S-1: docs checklist REQ가 release feedback까지 추적된다.
|
||||
- S-2: feedback에서 change-req와 new-discovery가 구분된다.
|
||||
|
||||
## 측정 방식 및 데이터 출처
|
||||
|
||||
- S-1 측정 방식: doctor traceability 확인 / 데이터 출처: docs/srs, docs/releases
|
||||
- S-2 측정 방식: feedback handoff review / 데이터 출처: release 문서
|
||||
|
||||
# 8. REQ로 넘기기 전 확인 체크
|
||||
|
||||
- [x] 범위(In Scope/Out of Scope) 확정
|
||||
- 기준: docs checklist와 feedback 구조만 포함
|
||||
- [x] 성공 지표의 측정 방식/데이터 출처 확정
|
||||
- 기준: doctor와 release 문서로 추적 가능
|
||||
- [x] High 영향 리스크 우선순위 및 해소 책임자 지정
|
||||
- 기준: maintainer가 후속 변경 관리 수행
|
||||
- [x] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
|
||||
- 기준: open question 없음
|
||||
- [x] Freeze 확정 담당자(CONFIRMED_BY) 지정
|
||||
- 기준: maintainer confirmed
|
||||
|
||||
# 9. 파일 처리 결과
|
||||
|
||||
- 처리 결과: 생성
|
||||
- 생성 경로: docs/discovery/dcy-001_20260425_docs_release_quality_loop.md
|
||||
- 참조 문서:
|
||||
- docs/srs/Documentation/req-001_docs_release_checklist.md
|
||||
- docs/releases/rel-001_20260428_docs_release_hardening.md
|
||||
|
||||
# 10. 사용자 결정 필요 항목 요약
|
||||
|
||||
## DECIDE
|
||||
- 없음
|
||||
|
||||
## CONFIRM
|
||||
- 없음
|
||||
|
||||
## DATA
|
||||
- 없음
|
||||
|
||||
# 11. Discovery Freeze
|
||||
|
||||
## 섹션 참조
|
||||
- 범위: [# 5. 요구사항 목록 > 범위 경계](#5-요구사항-목록)
|
||||
- 리스크/오픈 질문: [# 6. 리스크/가정 목록](#6-리스크가정-목록)
|
||||
- 성공 기준: [# 7. 초기 성공 기준](#7-초기-성공-기준)
|
||||
- 인계 전 확인: [# 8. REQ로 넘기기 전 확인 체크](#8-req로-넘기기-전-확인-체크)
|
||||
- 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약)
|
||||
|
||||
## Freeze 플래그
|
||||
- Handoff Decision: REQ Drafting 진행 가능
|
||||
- Handoff Rationale: docs release quality loop를 REQ와 release feedback에 연결할 준비가 됨
|
||||
- Ready for REQ Drafting: true
|
||||
- Confirmed By: maintainer
|
||||
- Confirmed At (KST): 2026-04-25 11:00
|
||||
@@ -0,0 +1,7 @@
|
||||
# Discovery 전체 인덱스
|
||||
|
||||
## Discovery 목록
|
||||
|
||||
| ID | 날짜 | 이슈명 | 문서 | 상태 |
|
||||
|---|---|---|---|---|
|
||||
| dcy-001 | 20260425 | Docs release quality loop | [Discovery](./dcy-001_20260425_docs_release_quality_loop.md) | confirmed |
|
||||
@@ -0,0 +1,7 @@
|
||||
# Release Index
|
||||
|
||||
## Release Register
|
||||
|
||||
| REL ID | Profile | Status | Included Batch | Discovery/REQ Input | Link |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| rel-001 | docs-only | feedback-captured | bat-001 | dcy-001, req-001 | [release](./rel-001_20260428_docs_release_hardening.md) |
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
# rel-001: docs release hardening
|
||||
|
||||
- Status: feedback-captured
|
||||
- Profile: docs-only
|
||||
- Included Batch: bat-001
|
||||
|
||||
## Scope
|
||||
- Included:
|
||||
- docs-only release profile evidence
|
||||
- feedback handoff structure
|
||||
- Excluded:
|
||||
- app-service rollout automation
|
||||
|
||||
## Rollout Plan
|
||||
1. merge release template updates
|
||||
2. publish package update
|
||||
|
||||
## Rollback Plan
|
||||
- revert package update and release note changes
|
||||
|
||||
## Verification Checklist
|
||||
- docs-only release note updated
|
||||
- broken-link verification reviewed
|
||||
- feedback handoff recorded
|
||||
|
||||
## Release Execution Evidence
|
||||
- Release Status Transition Target: released
|
||||
|
||||
### Deployment Facts
|
||||
- Executed At:
|
||||
- 2026-04-28T09:00:00Z
|
||||
- Completed At:
|
||||
- 2026-04-28T09:12:00Z
|
||||
- Environment:
|
||||
- repository package
|
||||
- Operator:
|
||||
- docs maintainer
|
||||
- Revision or Artifact:
|
||||
- main@HEAD
|
||||
- Commands or Procedure:
|
||||
- merge release prep and publish package update
|
||||
|
||||
### Profile-Specific Checks
|
||||
- docs-only:
|
||||
- Published or Packaged Targets:
|
||||
- release template and README guidance
|
||||
- Link or Rendering Check:
|
||||
- doctor broken-link validation reviewed during release
|
||||
- Navigation or Consumer Update:
|
||||
- release note updated for docs-only profile
|
||||
- tooling:
|
||||
- Install or Upgrade Smoke:
|
||||
- none
|
||||
- CLI or Script Execution:
|
||||
- none
|
||||
- Compatibility Note:
|
||||
- none
|
||||
- app-service:
|
||||
- Health Endpoint:
|
||||
- n/a
|
||||
- Startup Log Fields:
|
||||
- n/a
|
||||
- Request Log Fields:
|
||||
- n/a
|
||||
- Smoke or Manual Verification:
|
||||
- n/a
|
||||
|
||||
### Rollback Outcome
|
||||
- Rollback Required:
|
||||
- no
|
||||
- Rollback Trigger:
|
||||
- none
|
||||
- Rollback Action:
|
||||
- none
|
||||
|
||||
### Release Decision Evidence
|
||||
- Released Decision:
|
||||
- yes
|
||||
- Rationale:
|
||||
- docs-only release evidence was sufficient at release time
|
||||
- Recorded By:
|
||||
- docs maintainer
|
||||
- Recorded At:
|
||||
- 2026-04-28T09:12:00Z
|
||||
|
||||
## Feedback Handoff
|
||||
- Observation Summary:
|
||||
- docs consumers requested stricter broken-link evidence and clearer follow-up triage
|
||||
- Discovery Input:
|
||||
- release feedback triage automation for maintainers
|
||||
- REQ Input:
|
||||
- release note checklist for docs-only profile
|
||||
- Change Request Input:
|
||||
- req-001 docs release checklist needs stricter broken-link acceptance criteria
|
||||
+110
@@ -0,0 +1,110 @@
|
||||
# req-001: Docs release checklist
|
||||
|
||||
- Status: Approved
|
||||
- Type: Documentation
|
||||
- Priority: Medium
|
||||
- Owner: Docs Maintainer
|
||||
|
||||
## Intent
|
||||
- docs-only release에서도 소비자 관점의 품질 게이트를 문서화하고 검증 근거로 남긴다.
|
||||
|
||||
## Requirement
|
||||
- docs-only release는 release note 반영과 broken-link 검증 결과를 release evidence에 포함해야 한다.
|
||||
|
||||
## Acceptance Criteria
|
||||
1. Given docs-only release가 준비되었을 때, When release evidence를 검토하면, Then broken-link 검증 결과가 명시되어야 한다.
|
||||
2. Given release feedback가 수집되었을 때, When follow-up를 분류하면, Then Discovery/REQ/change-req 입력이 구분되어야 한다.
|
||||
|
||||
## Impacted Area
|
||||
- Docs: docs/releases/rel-001_20260428_docs_release_hardening.md, README.md
|
||||
- Modules: bootstrap/stagepilot.sh, .github/scripts/stagepilot-doctor.py
|
||||
- Tests: doctor release feedback summary validation
|
||||
|
||||
## Notes
|
||||
- `CHG-20260430-02`로 acceptance criteria가 강화되어 기존 구현 증거는 재검증이 필요하다.
|
||||
|
||||
## Change Log
|
||||
|
||||
### CHG-20260426-01
|
||||
- Date: 2026-04-26
|
||||
- Author: Docs Maintainer
|
||||
|
||||
#### Change Summary
|
||||
- initial requirement created
|
||||
|
||||
#### Intent
|
||||
- docs-only release checklist를 requirement로 관리한다.
|
||||
|
||||
#### Acceptance Criteria Delta
|
||||
- Added:
|
||||
- release evidence must include release note update result
|
||||
- Updated:
|
||||
- none
|
||||
- Removed:
|
||||
- none
|
||||
|
||||
#### Impacted Area Delta
|
||||
- Docs:
|
||||
- release template
|
||||
- Modules:
|
||||
- none
|
||||
- Tests:
|
||||
- manual release review
|
||||
|
||||
#### Delivery Trace Delta
|
||||
- Batches:
|
||||
- bat-001
|
||||
- Releases:
|
||||
- rel-001
|
||||
|
||||
#### Revalidation Impact
|
||||
- Reverification Needed: no
|
||||
- Existing Implementation Invalidated: no
|
||||
- Status Recommendation: keep-current
|
||||
- Follow-up Action: implement through bat-001
|
||||
|
||||
#### Validation Plan
|
||||
- verify release checklist before approval
|
||||
|
||||
### CHG-20260430-02
|
||||
- Date: 2026-04-30
|
||||
- Author: Docs Maintainer
|
||||
|
||||
#### Change Summary
|
||||
- strengthen docs-only release criteria to require broken-link evidence and explicit feedback triage
|
||||
|
||||
#### Intent
|
||||
- release feedback에서 드러난 품질 gap을 기존 REQ에 반영한다.
|
||||
|
||||
#### Acceptance Criteria Delta
|
||||
- Added:
|
||||
- broken-link 검증 결과가 release evidence에 포함되어야 한다.
|
||||
- feedback handoff는 Discovery/REQ/change-req 입력을 구분해야 한다.
|
||||
- Updated:
|
||||
- release note update alone is no longer sufficient for docs-only release verification.
|
||||
- Removed:
|
||||
- none
|
||||
|
||||
#### Impacted Area Delta
|
||||
- Docs:
|
||||
- docs/releases/rel-001_20260428_docs_release_hardening.md
|
||||
- README.md
|
||||
- Modules:
|
||||
- .github/scripts/stagepilot-doctor.py
|
||||
- Tests:
|
||||
- doctor feedback summary sample
|
||||
|
||||
#### Delivery Trace Delta
|
||||
- Batches:
|
||||
- bat-001 needs reverification or successor batch is required
|
||||
- Releases:
|
||||
- rel-001 remains historical evidence only
|
||||
|
||||
#### Revalidation Impact
|
||||
- Reverification Needed: yes
|
||||
- Existing Implementation Invalidated: yes
|
||||
- Status Recommendation: revert-to-approved
|
||||
- Follow-up Action: prepare a follow-up batch to reverify docs-only release criteria
|
||||
|
||||
#### Validation Plan
|
||||
- rerun doctor on a follow-up batch and verify release feedback summary plus broken-link evidence
|
||||
@@ -0,0 +1,26 @@
|
||||
# Software Requirement Specification Index
|
||||
|
||||
## 목적
|
||||
- 이 문서는 프로젝트의 SRS 운영 기준과 requirement 목록을 관리하는 entry point이다.
|
||||
- 개별 requirement의 상세 내용은 타입별 폴더 하위 `req-XXX_*.md` 파일에서 관리한다.
|
||||
|
||||
## 사용 방법
|
||||
1. 새로운 requirement가 필요하면 `Next Requirement ID`를 확인하고 `docs/srs/req-template.md`를 복사해 `docs/srs/<Type>/req-XXX_<slug>.md` 파일을 생성한다.
|
||||
2. 초안 작성은 `draft-req`, 승인 전환은 `confirm-req`, 변경 대응은 `change-req`, 구현 완료 전환은 `confirm-req-implemented` skill을 기준으로 수행한다.
|
||||
3. 작성 또는 수정 후 누락과 모호성을 점검한다.
|
||||
4. requirement 추가 또는 변경 후 `Next Requirement ID`, `Requirement Register`, `Recent Change Log Summary`를 함께 갱신한다.
|
||||
|
||||
## Next Requirement ID
|
||||
|
||||
- Current: `REQ-002`
|
||||
- Rule: `Requirement Register`에 있는 가장 큰 REQ 번호보다 정확히 1 커야 한다.
|
||||
|
||||
## Requirement Register
|
||||
|
||||
| ID | Title | Type | Status | Priority | Owner | Link |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| REQ-001 | Docs release checklist | Documentation | Approved | Medium | Docs Maintainer | [req-001](./Documentation/req-001_docs_release_checklist.md) |
|
||||
|
||||
## Recent Change Log Summary
|
||||
|
||||
- 2026-04-30 `REQ-001` `CHG-20260430-02`: broken-link acceptance criteria 강화, 상태 `Implemented -> Approved`
|
||||
@@ -0,0 +1,44 @@
|
||||
# Sample Output: suggest-next-discovery rel-001
|
||||
|
||||
- Input Release: `rel-001`
|
||||
- Release Status: `feedback-captured`
|
||||
- Basis:
|
||||
- `Discovery Input`: `release feedback triage automation for maintainers`
|
||||
- `REQ Input`: `release note checklist for docs-only profile`
|
||||
- `Change Request Input`: `req-001 docs release checklist needs stricter broken-link acceptance criteria`
|
||||
|
||||
## CANDIDATE-1
|
||||
|
||||
- Classification: `change-req`
|
||||
- Target: `req-001`
|
||||
- Value: High
|
||||
- Risk: Medium
|
||||
- Effort: Low
|
||||
- Reason:
|
||||
- 피드백이 기존 REQ acceptance criteria 강화로 닫힌다.
|
||||
- 기존 batch/release trace를 유지한 채 REQ 상태를 재검증 대상으로 되돌릴 수 있다.
|
||||
- Next Command:
|
||||
- `/change-req req-001`
|
||||
|
||||
## CANDIDATE-2
|
||||
|
||||
- Classification: `new-discovery`
|
||||
- Target: `release feedback triage automation for maintainers`
|
||||
- Value: Medium
|
||||
- Risk: Low
|
||||
- Effort: Medium
|
||||
- Reason:
|
||||
- release feedback를 다음 반복 후보로 자동 분류하는 기능은 기존 REQ 수정만으로 닫히지 않는다.
|
||||
- 독립 Discovery로 추적하는 편이 범위와 성공 기준을 명확히 유지한다.
|
||||
- Next Command:
|
||||
- `/new-discovery release feedback triage automation for maintainers`
|
||||
|
||||
## CANDIDATE-3
|
||||
|
||||
- Classification: `no-action`
|
||||
- Target: `release note checklist for docs-only profile`
|
||||
- Value: Low
|
||||
- Risk: Low
|
||||
- Effort: Low
|
||||
- Reason:
|
||||
- 현재 `req-001` 변경에 흡수 가능하므로 별도 반복으로 분리하지 않는다.
|
||||
Reference in New Issue
Block a user