@xulthekl/team-flow 0.42.0 → 0.44.0

package/agents/prototype-env-scout.md

@@ -16,7 +16,7 @@ You NEVER write, edit, create, or delete any file. Your only output is the brief
 ## Invocation Contract
 
 The dispatch prompt provides (some may be absent — probe to discover):
-- `prd_path` or a hint to locate the current PRD version (e.g., `prd/v1/prd.md`).
+- `prd_path` or a hint to locate the current PRD version (e.g., `requirement/v1/prd.md`).
 - `design_system_path` (from `prototype.designSystem` config) or a hint to find `design-system.md`.
 - `prototype_root` (default `prototype/`).
 - The intent: new prototype from scratch / iterate on existing / sync after a change.
@@ -36,7 +36,7 @@ Turn the probe into a decision-ready brief: what exists, what is missing, and a
 - List existing pages (`prototype/pages/*.html`), components (`prototype/components/`), and `flow.md` if present.
 
 ### Step 3: PRD Version Probe
-- Identify the PRD version to prototype against (read `prd/vN/prd.md` frontmatter `iteration_version` if present).
+- Identify the PRD version to prototype against (read `requirement/vN/prd.md` frontmatter `iteration_version` if present).
 - Extract from the PRD the inputs the builder will need: §4 画面原型 (page list), §7 系统功能清单 (functions), §8.4 功能模块 (fields), §8.2 画面交互 (navigation/transitions).
 
 ### Step 4: Synthesize Brief + Recommended Plan

package/agents/prototype-reviewer.md

@@ -11,13 +11,13 @@ You are an independent Prototype Consistency Reviewer. You check whether an HTML
 
 ## The Iron Law
 
-You are an independent reviewer. You did NOT participate in producing the PRD or the prototype. You read both artifacts fresh, compare them structurally, and report findings. You MUST write the review report to disk at `prd/vN/prototype-auto-review.md`. Do NOT modify the prototype or PRD — only write the review report.
+You are an independent reviewer. You did NOT participate in producing the PRD or the prototype. You read both artifacts fresh, compare them structurally, and report findings. You MUST write the review report to disk at `requirement/vN/prototype-auto-review.md`. Do NOT modify the prototype or PRD — only write the review report.
 
 ## Inputs
 
 | Parameter | Description |
 |-----------|-------------|
-| `prd_path` | PRD 文件路径（e.g., `prd/v1/prd.md`） |
+| `prd_path` | PRD 文件路径（e.g., `requirement/v1/prd.md`） |
 | `prototype_path` | 原型目录路径（e.g., `prototype/`） |
 
 If either path is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`.

package/agents/spec-writer.md

@@ -27,7 +27,7 @@ You write planning artifacts, never implementation code. Honor confirmed DP-0 de
 |-----------|-------------|
 | `change_dir` | change 目录路径（e.g., `changes/feature-x/`） |
 | `brief_path` | change-brief.md 路径（可选,workflow-orchestrator S4 分发时存在） |
-| `plan_path` | prd/vN/plan.md 路径（可选,高阶技术方向） |
+| `plan_path` | requirement/vN/plan.md 路径（可选,高阶技术方向） |
 | `arch_dir` | architecture/ 目录路径（可选,architecture-design 产出） |
 
 If `change_dir` is missing, or `.team-flow.yaml` `dp_0_confirmed` is not `true`, report `FAIL` with reason `INPUT_ERROR` and route back to workflow-start for DP-0.

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.42.0`
+- Current: `v0.44.0`
 - v0.9.1 highlights: DP-4 execution-mode recommendations, a portable runtime across 17 platforms, and a raw-package smoke with no plugin-root variable.
 - Self-contained — no OpenSpec or Superpowers runtime required
 - Upstream: [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec), [obra/superpowers](https://github.com/obra/superpowers)

package/docs/examples/add-dark-mode/specs/ui-theme/spec.md

@@ -1,35 +1,33 @@
-# Capability Spec
-
 ## ADDED Requirements
 
 ### Requirement: User can use dark mode
 
-The system SHALL provide a dark theme variant for the primary user interface.
+The system SHALL provide a user-facing dark mode for the web UI that can be toggled between light and dark themes.
 
-#### Scenario: Initial load follows system preference
+#### Scenario: Manual toggle
 
-- **WHEN** a first-time visitor opens the application and has no saved theme preference
-- **THEN** the interface uses the operating system color-scheme preference
+- **WHEN** the user clicks the theme toggle in the UI
+- **THEN** the interface switches to the selected theme immediately
 
-#### Scenario: User manually switches theme
+#### Scenario: System preference on first load
 
-- **WHEN** the user activates the theme toggle
-- **THEN** the interface switches between light and dark mode immediately
+- **WHEN** the user opens the application for the first time
+- **THEN** the interface theme matches the system preference by default
 
 ### Requirement: User preference persists
 
-The system SHALL persist an explicit user theme choice across reloads.
+The system SHALL persist the user's explicit theme choice across browser sessions using localStorage or an equivalent mechanism.
 
-#### Scenario: Saved choice overrides system preference
+#### Scenario: Return visit
 
-- **WHEN** a returning user has a saved theme choice
-- **THEN** the application loads using the saved choice instead of the current system preference
+- **WHEN** the user revisits the application after explicitly choosing dark mode
+- **THEN** the interface renders in dark mode without requiring another toggle
 
 ### Requirement: Theme maintains readable contrast
 
-The system SHALL preserve readable text and UI contrast in both light and dark mode.
+The system SHALL ensure that all core page colors and text combinations remain readable in both light and dark themes.
 
-#### Scenario: Primary content remains readable
+#### Scenario: Dark mode readability
 
-- **WHEN** the user views text, surfaces, and interactive controls in dark mode
-- **THEN** foreground and background combinations remain readable and distinguishable
+- **WHEN** the interface is in dark mode
+- **THEN** text and interactive elements meet WCAG contrast requirements against dark backgrounds

package/docs/examples/refactor-auth-boundary/specs/auth-boundary/spec.md

@@ -1,45 +1,33 @@
-# auth-request-gating Specification
-
 ## MODIFIED Requirements
 
 ### Requirement: Protected requests use one authentication boundary
 
-The system SHALL evaluate protected requests through one shared authentication boundary instead of scattered controller-level auth logic.
-
-#### Scenario: Valid protected request
+The system SHALL route all protected requests through a single authentication boundary instead of scattering checks across route handlers and service helpers.
 
-- **WHEN** a protected request includes valid authentication credentials
-- **THEN** the shared authentication boundary produces an authenticated request context
-- **AND** downstream handlers use that context instead of re-parsing credentials independently
+#### Scenario: Protected endpoint request
 
-#### Scenario: Missing credentials
-
-- **WHEN** a protected request arrives without required credentials
-- **THEN** the shared authentication boundary rejects the request consistently
-- **AND** the request does not continue into protected business logic
+- **WHEN** a protected endpoint receives a request
+- **THEN** the authentication boundary evaluates credentials and produces a stable auth decision before the route handler executes
 
 ### Requirement: Auth failures map consistently
 
-The system SHALL map authentication and authorization failures through standardized request-level outcomes.
+The system SHALL map unauthorized and forbidden outcomes from the authentication boundary to consistent response formats across all protected routes.
 
-#### Scenario: Invalid token
+#### Scenario: Missing credentials
 
-- **WHEN** token validation fails
-- **THEN** the request receives the standardized unauthorized outcome
-- **AND** downstream handlers are not invoked
+- **WHEN** a protected request lacks valid credentials
+- **THEN** the boundary returns an unauthorized decision and the route responds with the standard unauthorized format
 
-#### Scenario: Authenticated but forbidden
+#### Scenario: Insufficient permissions
 
-- **WHEN** the requester is authenticated but lacks required access
-- **THEN** the request receives the standardized forbidden outcome
-- **AND** the outcome is produced without ad hoc controller-specific branching
+- **WHEN** a protected request has valid credentials but insufficient permissions
+- **THEN** the boundary returns a forbidden decision and the route responds with the standard forbidden format
 
 ### Requirement: Existing approved login behavior remains unchanged
 
-The refactor SHALL preserve already approved login and session semantics while changing the internal auth boundary shape.
+The system SHALL preserve existing externally approved login and session behavior while moving request-level checks behind the new boundary.
 
-#### Scenario: Existing login flow
+#### Scenario: Successful login
 
-- **WHEN** a user signs in through the existing approved login path
-- **THEN** the resulting session or token behavior remains externally unchanged
-- **AND** the new boundary consumes the established auth artifacts without requiring a new client contract
+- **WHEN** a user completes the existing login flow
+- **THEN** session creation and token issuance behavior remains identical to the pre-refactor implementation

package/docs/solutions/INDEX.md

@@ -2,6 +2,7 @@
 <!-- 每条一行，按 severity 降序，≤150 行硬上限 -->
 | date | phase | domain | type | severity | summary | file |
 |------|-------|--------|------|----------|---------|------|
+| 2026-08-17 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-08-17-no-summary.md |
 | 2026-08-07 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-08-07-no-summary.md |
 | 2026-08-06 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-08-06-no-summary.md |
 | 2026-08-05 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-08-05-no-summary.md |

package/docs/solutions/cross-phase/2026-08-17-no-summary.md

@@ -0,0 +1,17 @@
+---
+phase: cross-phase
+domain: general
+type: insight
+severity: medium
+date: 2026-08-17
+source: 
+---
+
+## 问题描述
+(no summary)
+
+## 根因/模式
+（待补充）
+
+## 预防措施/应用方式
+（待补充）