@rudinmax87/united-we-stand 0.2.0 → 0.2.1

package/.united-we-stand/README.md

@@ -173,7 +173,7 @@ How chat usage works:
 - framework initialization guidance should appear only when you explicitly ask to initialize or explicitly bring up the framework
 - when initialization is requested, the AI should always do a fresh live check of the current git branch before creating branch memory
 - it should not reuse an earlier branch check, earlier status output, or remembered branch context from the same chat as the initialization target
-- if the current branch is the detected default branch, initialization should warn and ask for confirmation before creating branch memory unless you explicitly use `--force`
+- if the current branch is the detected default branch, any framework write that would create or rewrite branch memory should warn and ask for confirmation first; `--force` does not skip that confirmation
 
 The workflow is mainly used in chat after installation:
 
@@ -194,11 +194,11 @@ After the workflow is initialized, each stage writes or updates its branch file
 | Stage | File name | General description |
 |-------|-----------|---------------------|
 | `0-status-checker` | `00-current-status.md` | Current branch status, blockers, recommended next step, and routing state |
-| `1-initializer` | `01-init.md` | Raw idea, scope, assumptions, open questions, and success criteria |
-| `2-planner` | `02-plan.md` | Ordered plan, dependencies, risks, and suggested execution order |
-| `3-designer` | `03-design.md` | Architecture, interfaces, boundaries, data flow, and design decisions |
+| `1-initializer` | `01-init.md` | Raw idea, scope, assumptions, open questions, success criteria, and early security/dependency concerns |
+| `2-planner` | `02-plan.md` | Ordered plan, dependencies, risks, security/dependency risk handling, and suggested execution order |
+| `3-designer` | `03-design.md` | Architecture, interfaces, boundaries, attack surface, data flow, and design decisions |
 | `4-implementer` | `04-implementation.md` | What changed in code, validation performed, and remaining gaps |
-| `5-code-reviewer` | `05-code-review.md` | Quality, maintainability, security, optimization, and review findings |
+| `5-code-reviewer` | `05-code-review.md` | Quality, maintainability, vulnerability, security, optimization, and review findings |
 | `6-finalizer` | `06-finalization.md` | Final summary, uncaptured changes, doc updates, and closure confirmation |
 
 ## Runtime Branch Memory
@@ -244,7 +244,7 @@ The numbered framework stages are:
 2. `2-planner`: turn initialized intent into an ordered execution plan with dependencies and risks
 3. `3-designer`: define architecture, interfaces, boundaries, and implementation approach before coding
 4. `4-implementer`: make the code changes and record what changed plus how it was validated
-5. `5-code-reviewer`: review implementation quality, security, test sufficiency, and remaining issues
+5. `5-code-reviewer`: review implementation quality, dependency vulnerabilities, injection/attack risks, test sufficiency, and remaining issues
 6. `6-finalizer`: summarize delivered scope, identify spec/code mismatches or uncaptured changes, ask for explicit user approval, and only then close the workflow with `Current stage = none`
 
 ### Proper Order
@@ -288,6 +288,7 @@ Optional framework stages:
 - if a request could be interpreted as advancing through two or more phases at once, the AI should explain that united-we-stand only runs one stage at a time, suggest the next recommended numbered stage first, and ask the user to confirm one single stage
 - for branch-scoped work, the AI should stay inside `.spec-driven/<branch-folder>/` by default and update specs first unless you explicitly say otherwise
 - later stage files should be created when those stages are actually started or explicitly amended
+- if branch memory is created directly into a later stage by explicit user confirmation, the AI should create only that one numbered stage file plus `00-current-status.md` and `state.json`
 - `4-implementer` is the first framework stage allowed to change code
 - `6-finalizer` should check for meaningful code/doc changes that were not captured in the specs, ask the user to confirm the final state, and only then close the workflow with `Current stage = none`
 - if a closed branch receives new work later, the workflow should reopen `6-finalizer` and require final approval again
@@ -333,8 +334,9 @@ The framework is designed to route short natural requests such as `continue`, `f
 - If you ask for earlier-stage work while the branch is already in a later stage, the AI should perform that work without moving the workflow backward; instead it should mark downstream state as needing refresh in the status metadata.
 - The most reliable direct NLP bootstrap for initialization is to reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this` or `.united-we-stand/README.md init the following`.
 - If branch memory does not exist yet, an explicit request such as `init the following` or `initialize this` should be treated as permission to create the branch spec and start `1-initializer`.
-- If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests should still warn and ask for confirmation before creating `.spec-driven/...` unless you explicitly use `--force`.
+- If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there, the AI should still warn and ask for confirmation before writing `.spec-driven/...`; `--force` does not skip that confirmation.
 - If branch memory does not exist yet, broader natural phrases such as `let's start this`, `help me with the following idea, i want...`, `i want to build...`, `i want to create...`, or `let's work on...` should also default to `1-initializer` unless you explicitly ask for a later stage.
+- If branch memory does not exist yet and you explicitly confirm starting from a later stage such as planning, the AI should create only that single numbered stage file for the pass. It should not backfill `01-init.md` in the same response.
 - If branch memory does not exist yet and you ask for concrete code changes or other persistent repo work without explicitly asking to initialize the framework, the AI should continue helping with that request normally and should not interrupt to explain framework setup.
 - In that situation it should not create `.spec-driven/...` files unless you explicitly ask to initialize or explicitly bring up the framework.
 
@@ -450,9 +452,9 @@ Standalone agents can be used at any time when the task needs specialized help.
 - `project-manager`: summarize scope, blockers, milestones, dependencies, and coordination needs
 - `refactorer`: plan or execute structural improvements while preserving behavior
 - `test-strategist`: design proportionate test strategy and identify critical test coverage gaps
-- `optimizer`: review website optimization, Lighthouse/PageSpeed risks, startup cost, media delivery, caching, and real-user performance bottlenecks
+- `optimizer`: review website optimization, mobile Lighthouse/PageSpeed risks, startup cost, media delivery, caching, render blockers, LCP discovery, and real-user performance bottlenecks
 - `performance-reviewer`: review latency, throughput, memory, and performance hotspots
-- `accessibility-reviewer`: review accessibility concerns for UI work, including semantics and navigation
+- `accessibility-reviewer`: review accessibility concerns for UI work, including semantics, navigation, accessible control names, and contrast
 - `api-contract-writer`: define API request/response boundaries, contracts, and field exposure rules
 - `data-modeler`: design or review schemas, migrations, and data boundaries
 - `sql-database-designer`: design SQL schemas, migration layout, and required database flowcharts, sequence diagrams, entity-relationship models, and relational models
@@ -476,7 +478,7 @@ Initialize branch memory for the branch you are working on:
 united-we-stand branch-init "Describe the change you want to make"
 ```
 
-If you are on the repository default branch, `branch-init` should warn and ask for confirmation before creating branch memory there. This is meant to reduce long-lived workflow state on `main`/`master`-style branches when a feature branch would be safer.
+If you are on the repository default branch, `branch-init` should warn and ask for confirmation before creating or rewriting branch memory there. This confirmation is still required even when `--force` is used. This is meant to reduce long-lived workflow state on `main`/`master`-style branches when a feature branch would be safer.
 
 If you are in detached HEAD, provide the branch name explicitly:
 

package/.united-we-stand/agents/1-initializer.md

@@ -22,12 +22,13 @@ None.
 
 - Convert user idea into initial branch definition.
 - Capture scope boundaries, assumptions, questions, and success criteria.
+- Capture security-sensitive context early when relevant, including risky dependencies, trust boundaries, sensitive data, and likely attack surface.
 - Capture out-of-scope explicitly to reduce downstream ambiguity.
 - When initialization is requested, always perform a fresh live check of the current git branch before creating or updating branch memory.
 - Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
 - If branch memory does not exist yet and the user explicitly asks to initialize or init the work, create the branch spec for `1-initializer`.
 - If branch memory does not exist yet and the user uses natural bootstrap language such as `let's start this`, `help me with this idea`, `i want to build...`, or `let's work on...`, treat that as initialization intent by default.
-- If the current branch is detected as the repository default branch and branch memory does not exist yet, warn about default-branch risks and ask for confirmation before creating the branch spec unless the user explicitly used `--force` or equivalent force/bypass wording.
+- If the current branch is detected as the repository default branch and framework memory would be written there, warn about default-branch risks and ask for confirmation before creating or rewriting the branch spec. Force or bypass wording does not skip that confirmation.
 - Do not implement code.
 - If the user asks to modify initializer content, update `01-init.md` in place and keep `Current stage = 1-initializer` unless the user explicitly advances.
 - Do not create or populate planning content just because initializer content now looks complete.
@@ -42,6 +43,7 @@ None.
 - Assumptions
 - Open questions
 - Success criteria
+- Security / dependency concerns
 
 ## Next-Step Status Rules
 

package/.united-we-stand/agents/2-planner.md

@@ -24,6 +24,9 @@ Turn initialized intent into an actionable sequence.
 - Produce ordered plan, dependencies, and risk visibility.
 - Define suggested execution order and critical blockers.
 - Finish the planning step by reviewing and updating the full task list so it captures all work that still needs to be done.
+- Plan for dependency/package risk reduction and identify when later stages must run vulnerability audits or explicit attack-surface reviews.
+- If branch memory does not exist yet and the user explicitly confirms starting from planning, bootstrap only `00-current-status.md`, `state.json`, and `02-plan.md`.
+- When planning is the first explicit stage on a branch, do not auto-create `01-init.md` or any other numbered stage file in the same pass.
 - Do not implement code.
 - If code/spec drift is observed, apply canonical conflict policy.
 - If the user asks to add or modify planning content, update `02-plan.md` in place.
@@ -35,6 +38,7 @@ Turn initialized intent into an actionable sequence.
 - Objectives
 - Dependencies
 - Risks / unknowns
+- Security / dependency risk plan
 - Suggested execution order
 - Detailed task list
 - Status

package/.united-we-stand/agents/3-designer.md

@@ -23,6 +23,7 @@ Define architecture, boundaries, and implementation approach before coding.
 
 - Document architecture and interface decisions.
 - Define boundaries (security, data exposure, ownership checks) when relevant.
+- Identify attack surface and injection risks when relevant, including XSS, SQL/NoSQL injection, command injection, path traversal, SSRF, CSRF, open redirects, and unsafe deserialization.
 - Define testing boundaries and observability expectations for non-trivial changes.
 - Add diagrams/flows when they reduce ambiguity.
 - For complex integrations (external APIs, databases, third-party services), include explicit sequence/flow diagrams.
@@ -40,6 +41,7 @@ Define architecture, boundaries, and implementation approach before coding.
 - Key components
 - Interfaces / data flow
 - Constraints
+- Security boundaries / attack surface
 - Design decisions
 - Diagrams/flows when useful (Mermaid allowed)
 

package/.united-we-stand/agents/4-implementer.md

@@ -33,6 +33,7 @@ Implement branch changes while preserving traceability and quality.
 - Treat `../steering/coding-steering.md` as mandatory for every code change.
 - Follow repository linting, parser-based analysis, and static-analysis rules during implementation instead of treating them as review-only concerns.
 - When repo commands or configured tools exist for linting or parser/static-analysis checks, use them during implementation close and fix straightforward violations in the changed scope before considering the implementation ready for review.
+- When the requested work includes a fix, especially a security or dependency fix, re-verify afterward that the project still builds/compiles when applicable, relevant tests still pass when available, and no intended functionality was removed or changed unintentionally.
 - Add the required file-level/function/block comments from coding steering during implementation instead of leaving them for review cleanup.
 - Do not leave large multi-responsibility functions behind when they can be split into smaller helpers during the implementation step.
 - If code/spec drift exists, reconcile using canonical conflict policy.
@@ -46,6 +47,7 @@ Implement branch changes while preserving traceability and quality.
 - Why it changed
 - Files touched
 - Validation and tests executed
+- Post-fix build/compile/runtime verification performed when applicable
 - Lint/parser/static-analysis checks executed for the changed scope, or an explicit note when such checks were not available
 - Remaining gaps / follow-ups
 

package/.united-we-stand/agents/5-code-reviewer.md

@@ -12,6 +12,8 @@ Review implementation for conformance, quality, security, optimization, and test
 
 - State updates: `../framework/02-state-model.md`
 - Review model: `../framework/10-review-model.md`
+- React/frontend checklist: `../framework/12-react-frontend-review-checklist.md`
+- Vulnerability audit matrix: `../framework/13-vulnerability-audit-matrix.md`
 - Conflict policy: `../framework/05-conflict-resolution.md`
 - Done criteria: `../framework/07-definition-of-done.md`
 - Profile selection: `../framework/profiles/00-profile-selection.md`
@@ -24,15 +26,22 @@ Review implementation for conformance, quality, security, optimization, and test
 
 - By default review quality, security, and optimization dimensions.
 - Treat optimization as the third default check and apply the standalone `optimizer` checklist when the reviewed scope includes a website, frontend, landing page, or user-facing performance path.
+- For React/frontend scope, apply `12-react-frontend-review-checklist.md` as a manual/static-analysis review lens even when no extra tool is installed.
+- For website/frontend scope, include mobile Lighthouse/PageSpeed-style blockers in the default review, especially cache lifetime issues, image delivery issues, render-blocking requests, LCP breakdown/resource discovery issues, network dependency tree problems, unused JS/CSS, unnamed interactive controls, and insufficient contrast.
+- Do not treat a website review as clean when those issues would predictably keep the first production-like mobile Lighthouse/PageSpeed run below a strong score unless the residual risk is explicitly documented.
 - If optimization is not materially applicable, say so explicitly instead of silently skipping it.
 - User may request narrower review scope.
 - Report findings and recommended fixes.
+- Run the proper repo-native vulnerability audit command for the detected stack/package manager whenever a safe no-extra-install command exists, or explicitly state why that audit was unavailable.
+- Report all detected dependency vulnerabilities as high priority in `05-code-review.md`, even when the underlying tool reports a lower severity.
 - Treat coding-steering violations as real findings, not optional style suggestions.
 - Flag missing required comments, large multi-responsibility functions, duplicated logic, unused code, and routine SonarQube-style maintainability issues when they are present in reviewed scope.
 - Run repository linting, parser-based analysis, and static-analysis checks when they are available for the changed stack or package, or explicitly state that they were unavailable or not run.
+- Review code for injection and attack risks when relevant, including XSS, SQL/NoSQL injection, command injection, path traversal, SSRF, CSRF, open redirects, unsafe deserialization, and secret exposure.
 - Surface the relevant lint/parser/static-analysis observations to the user as part of the review output instead of silently relying on them.
 - Do not perform implementation rewrites unless user explicitly requests them.
 - If implementation or design work is requested while review is the current stage, perform the requested earlier-stage work through the appropriate specs/code paths without regressing workflow metadata.
+- If the user asks for fixes from review findings, require post-fix verification of build/compile health, available tests, and functionality preservation before treating the fixes as complete.
 - If the user asks to modify review notes, update `05-code-review.md` in place.
 - Do not create or populate `06-finalization.md` from a review amendment alone.
 - Keep `Current stage = 5-code-reviewer` unless the user explicitly advances, skips, or bypasses.
@@ -40,11 +49,13 @@ Review implementation for conformance, quality, security, optimization, and test
 ## Required Output (`05-code-review.md`)
 
 - Quality & maintainability findings
+- Vulnerability audit findings
 - Security & boundary findings
 - Optimization findings
 - Severity / priority
 - Recommended fixes
 - Lint/parser/static-analysis observations and whether those checks were run
+- Residual risks
 - Reviewed scope and non-reviewed scope
 
 ## Next-Step Status Rules

package/.united-we-stand/agents/accessibility-reviewer.md

@@ -6,10 +6,13 @@
 
 ## Purpose
 
-Review accessibility risks for UI work, including semantics, navigation, and assistive-tech impact.
+Review accessibility risks for UI work, including semantics, navigation, assistive-tech impact, and Lighthouse-weighted issues that commonly drag mobile release scores.
 
 ## Behavior
 
 - Read `AGENTS.md`, relevant framework rules, relevant steering, and current branch specs if present.
+- Prioritize Lighthouse-impacting accessibility failures when relevant, especially unnamed interactive controls and insufficient foreground/background contrast.
+- For icon-only buttons or custom controls, verify accessible names explicitly instead of assuming visible icons are sufficient.
+- For text and UI surfaces, verify contrast with mobile readability in mind and flag combinations that are likely to fail WCAG AA or Lighthouse.
 - Do not silently update framework stage files.
 - If the user explicitly asks to persist output, write only the requested files.

package/.united-we-stand/agents/optimizer.md

@@ -16,6 +16,9 @@ Review websites and user-facing applications for optimization risks that affect
 - When used standalone, do not silently update framework stage files unless the user explicitly asks to persist findings.
 - Prefer concrete findings with the affected route/component/asset, likely user impact, and recommended fix.
 - If a checklist area is not applicable, say so explicitly instead of implying it was checked.
+- For website/frontend scope, treat mobile Lighthouse/PageSpeed on a production-like URL as a first-class release signal, not a nice-to-have after desktop looks good.
+- Do not clear a mobile optimization review while predictable Lighthouse blockers such as cache-lifetime failures, render-blocking resources, late-discovered LCP assets, oversized images, unused JS/CSS, unnamed buttons, or low-contrast UI remain unresolved without an explicit documented reason.
+- If the user wants a launch-ready review, require post-deploy or production-like verification on mobile and explicitly state whether the remaining findings are compatible with a realistic 90+ mobile score target.
 
 ## Default Optimization Checklist
 
@@ -31,20 +34,20 @@ Review all of the following when relevant:
 8. Reduce main-thread work from startup logic, rerenders, heavy parsing, and synchronous DOM work.
 9. Prevent forced reflow and layout thrashing.
 10. Optimize fonts, weights, render-blocking CSS, and loading behavior.
-11. Verify good caching behavior for built assets, images, fonts, media, and CDN/browser headers.
-12. Shorten the network dependency tree and reduce render-blocking chains.
+11. Verify good caching behavior for built assets, images, fonts, media, and CDN/browser headers, and treat missing long-lived cache headers as release blockers when Lighthouse flags them.
+12. Shorten the network dependency tree and reduce render-blocking chains, especially CSS, fonts, and late-discovered hero assets.
 13. Limit third-party impact and measure it separately.
 14. Optimize DOM size and structure.
 15. Avoid rendering offscreen content too early.
 16. Handle mobile differently when lower-power behavior should be simplified.
 17. Preserve layout stability and prevent CLS regressions.
-18. Fix Lighthouse-accessibility issues that overlap with optimization work.
+18. Fix Lighthouse-accessibility issues that overlap with optimization work, especially unnamed buttons/controls and insufficient foreground/background contrast.
 19. Fix SEO and metadata hygiene that affect Lighthouse and sharing quality.
 20. Watch for production-only bundle breakage from chunking, stale assets, or minification-sensitive behavior.
 21. Test optimization work in local, staging, and production-like environments when possible.
-22. Measure with the right tools, not Lighthouse alone.
-23. Verify what the browser is actually downloading in the network panel.
+22. Measure with the right tools, not Lighthouse alone, but always include a mobile Lighthouse/PageSpeed pass when launch-readiness is in scope.
+23. Verify what the browser is actually downloading in the network panel, including LCP resource discovery timing and whether the critical hero asset is fetched early enough.
 24. Re-test after meaningful changes and compare trends rather than trusting one run.
-25. Prioritize fixes in sensible order: runtime errors, eager media, JS startup cost, code splitting, images, decorative effects, main-thread work, caching, render blockers, accessibility, environment verification, then re-test.
-26. Treat an optimized website as one that is fast, interactive, stable, cache-sane, mobile-aware, and free of unnecessary early downloads.
-27. Before calling work done, verify console health, duplicate bootstrap avoidance, media/image behavior, chunking, decorative effects, main-thread work, forced reflow hotspots, fonts, cache headers, accessibility warnings, and post-deploy Lighthouse/PageSpeed checks.
+25. Prioritize fixes in sensible order: runtime errors, eager media, JS startup cost, code splitting, images, decorative effects, main-thread work, caching, render blockers, LCP discovery, accessibility, environment verification, then re-test.
+26. Treat an optimized website as one that is fast, interactive, stable, cache-sane, mobile-aware, accessible enough to avoid score drag, and free of unnecessary early downloads.
+27. Before calling work done, verify console health, duplicate bootstrap avoidance, media/image behavior, chunking, decorative effects, main-thread work, forced reflow hotspots, fonts, cache headers, render-blocking requests, LCP breakdown/discovery, unused JS/CSS, accessibility warnings, and post-deploy mobile Lighthouse/PageSpeed checks.

package/.united-we-stand/agents-md-block.md

@@ -38,7 +38,8 @@ This repository uses **united-we-stand**, a spec-driven AI workflow framework th
 - Never reuse an earlier branch check, earlier status output, or remembered branch context from the same chat as the initialization target.
 - If branch memory does not exist yet and the user asks for concrete code changes or other persistent repo work without explicitly asking to initialize, do not interrupt to explain missing framework setup. Help with the request normally instead of inferring a numbered stage.
 - Do not create `.spec-driven/...` files from that request alone. Only surface initialization/framework guidance when the user explicitly asks to initialize or explicitly brings up the framework.
-- If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.
+- If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there, warn about default-branch risks and ask for confirmation before writing `.spec-driven/...` files. Force or bypass wording does not skip that confirmation.
+- If branch memory does not exist yet and the user explicitly confirms starting from a later stage, create only `00-current-status.md`, `state.json`, and the single targeted numbered stage file. Never create two numbered stage files in the same pass.
 - The most reliable direct NLP bootstrap is to reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this` or `.united-we-stand/README.md init the following`.
 - Runtime branch memory is writable under `.spec-driven/` only.
 - Treat `.united-we-stand/` as installed framework content (do not use it for runtime branch memory updates).

package/.united-we-stand/antigravity-workflow.md

@@ -12,6 +12,6 @@ If branch memory does not exist yet and the user asks for concrete code changes
 
 When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory. Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
 
-If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.
+If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there, warn about default-branch risks and ask for confirmation before writing `.spec-driven/...` files. Force or bypass wording does not skip that confirmation.
 
 For the most reliable natural-language initialization when branch memory does not exist yet, reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this`.

package/.united-we-stand/copilot-instructions.md

@@ -12,6 +12,6 @@ If branch memory does not exist yet and the user asks for concrete code changes
 
 When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory. Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
 
-If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.
+If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there, warn about default-branch risks and ask for confirmation before writing `.spec-driven/...` files. Force or bypass wording does not skip that confirmation.
 
 For the most reliable natural-language initialization when branch memory does not exist yet, reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this`.

package/.united-we-stand/cursor-rule.mdc

@@ -15,6 +15,6 @@ If branch memory does not exist yet and the user asks for concrete code changes
 
 When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory. Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
 
-If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.
+If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there, warn about default-branch risks and ask for confirmation before writing `.spec-driven/...` files. Force or bypass wording does not skip that confirmation.
 
 For the most reliable natural-language initialization when branch memory does not exist yet, reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this`.

package/.united-we-stand/framework/00-index.md

@@ -19,6 +19,8 @@ Provide reusable, deterministic rules for spec-driven AI development across repo
 9. `09-traceability-model.md`
 10. `10-review-model.md`
 11. `11-glossary.md`
+12. `12-react-frontend-review-checklist.md`
+13. `13-vulnerability-audit-matrix.md`
 
 Then read:
 
@@ -41,6 +43,8 @@ Then read:
 - Requirement mapping across stages: `09-traceability-model.md`
 - Review dimensions, deep checks, and outputs: `10-review-model.md`
 - Shared definitions: `11-glossary.md`
+- React/frontend static review heuristics: `12-react-frontend-review-checklist.md`
+- Native vulnerability audit command guidance: `13-vulnerability-audit-matrix.md`
 
 ## Design Goals
 

package/.united-we-stand/framework/01-core-rules.md

@@ -91,12 +91,15 @@ This file is the canonical source for global framework invariants.
 29. **Post-closure work reopens finalizer**
     If the workflow was explicitly closed and the user later requests more branch changes, reopen `6-finalizer` as the current stage, clear closed/finalized state, and require finalization approval again after the new work is incorporated.
 
-30. **Default-branch initialization requires confirmation**
-    If the current branch is detected as the repository default branch and branch memory does not yet exist, explicit initialization requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files. Explicit `--force` semantics are the only bypass for that confirmation.
+30. **Default-branch framework writes require confirmation**
+    If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there, warn about default-branch risks and ask for confirmation before writing `.spec-driven/...` files. Force or bypass wording never skips that confirmation.
+
+31. **Bootstrap only the targeted stage file**
+    When branch memory does not exist yet and the user explicitly confirms starting from a later stage, create only `00-current-status.md`, `state.json`, and the single targeted numbered stage file for that pass. Never backfill another numbered stage file in the same pass.
 
 ## Stage Mandatory Set
 
-Mandatory framework stages:
+Mandatory framework stages in the normal forward flow:
 
 - `1-initializer`
 - `4-implementer`

package/.united-we-stand/framework/04-command-routing.md

@@ -127,21 +127,23 @@ If the user explicitly asks to initialize or init the work and branch memory doe
 
 Initialization bootstrap does not grant permission to pre-create or populate planning, design, implementation, review, or finalization files.
 
-## Default Branch Initialization Rule
+## Default Branch Spec-Creation Rule
 
-If branch memory does not exist yet and the current branch is detected as the repository default branch and the user asks to initialize:
+If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there:
 
-1. warn clearly that initialization is being requested on the default branch
+1. warn clearly that framework memory is about to be written on the default branch
 2. explain that default-branch framework memory can make later feature-branch flow, branch-specific specs, and long-lived workflow state harder to manage
 3. ask for explicit confirmation before creating `.spec-driven/<branch>/`
-4. if the user confirms, continue with normal `1-initializer` bootstrap
-5. if the user explicitly uses `--force` or equally explicit force/bypass semantics, proceed without asking again
+4. if the user confirms, continue with the single requested framework stage bootstrap
+5. force or bypass wording does not skip this confirmation on the default branch
 
 Examples:
 
 - `initialize this on main`
 - `branch-init this work on master`
 - `init this branch` while currently on the detected default branch
+- `start planning on main`
+- `create the review spec on master`
 
 Examples:
 
@@ -170,6 +172,7 @@ If branch memory does not exist yet and the user requests concrete code changes
 4. do not create `.spec-driven/...` files or numbered stage files unless the user explicitly asks to initialize or explicitly mentions the framework
 5. if the user explicitly asks to initialize instead, create branch memory and start `1-initializer`
 6. if the user explicitly asks to start the framework from a later stage or uses force/bypass semantics, require confirmation of one exact target stage before proceeding
+7. once that exact later-stage start is confirmed, create only `00-current-status.md`, `state.json`, and the single requested stage file; do not backfill `01-init.md` or any other numbered stage file in the same pass
 
 This silent fallback applies on the default branch too. Do not interrupt ordinary work on `main`/default branches just to explain framework setup.
 

package/.united-we-stand/framework/06-spec-writing-standard.md

@@ -53,12 +53,14 @@ Required fields:
 - Assumptions
 - Open questions
 - Success criteria
+- Security / dependency concerns
 
 ### `02-plan.md`
 
 - Objectives
 - Dependencies
 - Risks / unknowns
+- Security / dependency risk plan
 - Suggested execution order
 - Detailed task list
 - Status
@@ -69,6 +71,7 @@ Required fields:
 - Key components
 - Interfaces / data flow
 - Constraints
+- Security boundaries / attack surface
 - Design decisions
 - Diagrams/flows when useful (Mermaid allowed)
 
@@ -83,10 +86,13 @@ Required fields:
 ### `05-code-review.md`
 
 - Quality & maintainability findings
+- Vulnerability audit findings
 - Security / boundary findings
 - Optimization findings
 - Severity / priority
 - Recommended fixes
+- Lint/parser/static-analysis observations
+- Residual risks
 - Reviewed scope and non-reviewed scope
 
 ### `06-finalization.md`

package/.united-we-stand/framework/07-definition-of-done.md

@@ -15,11 +15,11 @@ A stage is done when all are true:
 
 ## Role-Specific Completion Expectations
 
-- **Initializer**: goal, scope, assumptions, open questions, and success criteria captured.
-- **Planner**: objectives, tasks, dependencies, and risks are actionable.
-- **Designer**: architecture, boundaries, and implementation guidance are clear.
-- **Implementer**: changes, rationale, tests, and validation are recorded.
-- **Code Reviewer**: quality, security, and optimization findings, severity, scope, and recommendations are explicit.
+- **Initializer**: goal, scope, assumptions, open questions, success criteria, and relevant security/dependency concerns are captured.
+- **Planner**: objectives, tasks, dependencies, risks, and security/dependency risk handling are actionable.
+- **Designer**: architecture, boundaries, attack surface, and implementation guidance are clear.
+- **Implementer**: changes, rationale, tests, and validation are recorded, including post-fix verification when relevant.
+- **Code Reviewer**: quality, vulnerability, security, and optimization findings, severity, scope, and recommendations are explicit.
 - **Finalizer**: delivered scope, known gaps, uncaptured spec/code differences, doc impact, and user closure confirmation status are clear; the workflow is only closed after explicit user confirmation.
 
 ## Implementation and Review Quality Gates
@@ -33,8 +33,12 @@ These gates must be applied through profile + review-model rules:
 - error handling and logging are intentional
 - tests are proportionate and meaningful
 - security boundaries are reviewed
-- dependency/security checks are run when dependency changes occur
+- earlier stages identify dependency risk and attack surface when relevant
+- dependency/security checks are run according to the selected stack/package manager when a safe no-extra-install command exists, or the gap is explicitly disclosed
+- all detected dependency vulnerabilities are surfaced as high priority review findings
+- fix requests are not done until post-fix verification was attempted for build/compile health, available tests, and functionality preservation
 - available lint/parser/static-analysis checks relevant to the changed scope were run, or their absence/non-execution is explicitly disclosed
+- for website/frontend changes, predictable mobile Lighthouse/PageSpeed blockers such as cache lifetime failures, render-blocking requests, late-discovered LCP assets, oversized images, unused JS/CSS, unnamed controls, and low-contrast UI are either fixed or explicitly documented before review is treated as clean
 
 Profile-specific mandates (for example JS/TS style, audit commands, JSDoc practices) must be enforced via selected profile docs.
 

package/.united-we-stand/framework/08-skip-force-policy.md

@@ -28,11 +28,11 @@ If branch memory does not exist yet, direct repo work without explicit initializ
 
 ## Default Branch Initialization Warning
 
-If the current branch is detected as the repository default branch and the user asks to initialize framework memory:
+If the current branch is detected as the repository default branch and the framework would create or rewrite branch memory there:
 
 - warn about the risks of anchoring branch-specific workflow state on the default branch
 - ask for explicit confirmation before creating `.spec-driven/...` files
-- only skip that confirmation when the user explicitly uses `--force` or equivalent force/bypass wording
+- never skip that confirmation because of `--force` or equivalent force/bypass wording
 
 ## Mandatory Stage Warning
 
@@ -40,6 +40,7 @@ If user bypasses a mandatory stage (`1-initializer` or `4-implementer`):
 
 - warn clearly about risk and missing guarantees
 - proceed only if user confirms bypass intent
+- create only the single explicitly targeted stage file for that pass; do not backfill the bypassed stage file in the same pass
 
 ## Traceability Requirement
 

package/.united-we-stand/framework/10-review-model.md

@@ -37,8 +37,11 @@ User may explicitly narrow scope.
    - oversized or multi-responsibility functions
    - routine SonarQube-style maintainability findings that should have been prevented during implementation
    - lint, parser-based analysis, and static-analysis findings relevant to the changed scope
+   - React/frontend static-review checklist findings when that stack is in scope
 3. **Security**
+   - dependency vulnerability audit findings from safe repo-native/package-manager-native commands when available
    - input validation/injection boundaries
+   - XSS, SQL/NoSQL injection, command injection, path traversal, SSRF, CSRF, open redirects, unsafe deserialization, and secret exposure when relevant
    - authn/authz ownership checks (BOLA/IDOR)
    - data exposure minimization
    - dependency/supply-chain considerations
@@ -47,8 +50,9 @@ User may explicitly narrow scope.
    - duplicated initialization, unnecessary listeners, and repeated bootstrap work
    - media, image, font, and third-party delivery cost
    - main-thread work, forced reflow, DOM size, and offscreen rendering cost
-   - mobile behavior, layout stability, caching, and production-only bundle risks
-   - accessibility/SEO/best-practice issues that Lighthouse commonly surfaces during optimization work
+   - mobile behavior, layout stability, caching, render-blocking requests, LCP breakdown/resource discovery, network dependency chains, and production-only bundle risks
+   - unused JS/CSS and late-discovered critical resources
+   - Lighthouse-scored accessibility issues that materially affect launch-readiness, especially unnamed interactive controls and insufficient contrast
 5. **Testing**
    - tests exist and cover high-risk paths proportionately
 6. **Documentation**
@@ -61,7 +65,9 @@ Review output should state:
 - what was reviewed
 - what was not reviewed
 - findings
+- vulnerability audit findings or an explicit unavailable/not-run note
 - optimization findings or an explicit not-applicable note
+- for website/frontend scope, an explicit note on whether the remaining findings are compatible with a realistic strong mobile Lighthouse/PageSpeed outcome
 - severity/priority
 - recommended fixes
 - lint/parser/static-analysis observations and whether those checks were run
@@ -70,6 +76,8 @@ Review output should state:
 ## Reviewer Behavior Constraints
 
 - report discrepancies by default
+- run safe repo-native vulnerability audit commands when available for the selected stack/package manager, or explicitly disclose that no no-install command was available
+- report detected dependency vulnerabilities as high priority findings in review output
 - treat mandatory coding-steering violations as review findings that block a clean review
 - use available lint/parser/static-analysis results as first-class review evidence instead of optional background context
 - do not rewrite lower stages unless user explicitly requests it

package/.united-we-stand/framework/12-react-frontend-review-checklist.md

@@ -0,0 +1,97 @@
+# React / Frontend Review Checklist
+
+Use this document as a framework-native checklist for React, Next.js, Vite, Remix, Gatsby, Expo web, and similar frontend reviews when no extra dependency is installed.
+
+This is a review lens, not a bundled parser or external tool requirement.
+
+## Scope
+
+Apply when the reviewed code materially includes:
+
+- React components or hooks
+- frontend routing/layout code
+- client rendering and hydration
+- bundle-size or delivery concerns
+- Next.js/App Router or similar framework code
+
+## State And Effects
+
+Check for:
+
+- derived state computed in `useEffect` instead of during render
+- `fetch()` in effects where a server/data-layer approach is more appropriate
+- too many `setState` calls in one effect
+- effects being used like event handlers
+- `useState` initialized from props and then expected to stay in sync
+- related local state that should likely be modeled with `useReducer`
+- stale-closure `setState(value + 1)` patterns
+- object/array literals in hook dependency arrays
+
+## Rendering And Performance
+
+Check for:
+
+- unnecessary `useMemo`/memoization for trivially cheap expressions
+- inline object/array/function props that defeat memoized child components
+- hydration flicker from mount-only `useEffect` state resets
+- sequential async work that should use `Promise.all()`
+- repeated expensive work during render
+- unnecessary rerenders from unstable references
+
+## Animation And Motion
+
+Check for:
+
+- `transition: all`
+- layout-property animation instead of transform/opacity
+- permanent `will-change`
+- large animated blur effects
+- `scale(0)` entrance animations
+- lack of reduced-motion handling when motion libraries are used
+- hover-only behavior on touch devices
+
+## Bundle Size And Delivery
+
+Check for:
+
+- barrel imports that weaken tree-shaking
+- full-library imports such as `lodash` instead of path imports
+- heavy date/moment-style libraries without justification
+- heavy client libraries that should be lazy/dynamically loaded
+- synchronous third-party scripts
+- full `framer-motion` usage where a lighter pattern would work
+- dead code, unused files, unused exports, unused types, and duplicate exports
+
+## Next.js And Route Delivery
+
+Check for:
+
+- `<img>` instead of `next/image`
+- missing `sizes` for responsive `next/image`
+- native `<script>` instead of `next/script`
+- inline `Script` without a stable `id`
+- Google Fonts `<link>` usage instead of `next/font`
+- stylesheet `<link>` usage that bypasses bundling
+- polyfill CDN scripts that duplicate framework behavior
+- missing page metadata
+- client-side redirects in effects when framework-native redirect handling should be used
+- `useSearchParams` without the required suspense boundary
+- GET handlers with side effects or mutating route semantics
+
+## Security Crossover
+
+Check for:
+
+- hardcoded client-side secrets
+- unsafe redirects
+- GET handlers that mutate state
+- direct use of `eval`, `new Function`, or string-based timers
+- user-controlled content flowing into unsafe rendering or execution sinks
+
+## Review Output Guidance
+
+When these checks produce findings:
+
+- surface them under quality, security, or optimization as appropriate
+- treat them as first-class review evidence, not optional polish
+- keep manual findings explicit about affected files/components and likely user impact