@rudinmax87/united-we-stand 0.1.2 → 0.2.1

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

@@ -169,11 +169,11 @@ How chat usage works:
 
 - if branch memory does not exist yet, explicit initialization prompts should start `1-initializer`
 - broad start-of-work prompts should also default to `1-initializer` unless you explicitly ask for a later stage
-- if branch memory does not exist yet and you ask for direct code changes, the AI should warn that united-we-stand is not initialized and ask whether to proceed outside the framework for the current chat
-- once you confirm outside-framework work for the current chat, the AI should not ask that same confirmation again unless you later return to framework mode
+- if branch memory does not exist yet and you ask for direct code changes without explicitly asking to initialize, the AI should continue helping normally and should not interrupt to explain framework setup
+- 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, 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,10 +334,11 @@ 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 ask for concrete code changes or other persistent repo work without explicitly asking to initialize the framework, the AI should first warn that united-we-stand is not initialized for that branch and ask whether you want to proceed outside the framework for the current chat.
-- If you confirm that outside-framework work is fine, the AI should continue outside the framework for the rest of the current chat without asking for the same confirmation again unless you later ask to initialize or return to framework flow.
+- 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.
 
 ## Framework Stage Chat Routes
 
@@ -407,7 +409,7 @@ Framework-stage routes:
 
 These direct route labels select the acting stage behavior. If the workflow is already in a later stage, they must not regress `Current stage`, `Completed steps`, or `Incompleted stages`.
 
-If branch memory does not exist yet and a direct request such as `implement this`, `fix these vulnerabilities`, `upgrade this dependency`, or `refactor this module` would otherwise cause repo changes, the AI should not silently enter that framework stage. It should first warn that united-we-stand is not initialized for the branch and ask whether you want to proceed outside the framework for the current chat.
+If branch memory does not exist yet and a direct request such as `implement this`, `fix these vulnerabilities`, `upgrade this dependency`, or `refactor this module` would otherwise cause repo changes, the AI should not silently enter that framework stage. It should continue helping with the request normally without announcing missing framework setup unless you explicitly ask to initialize or explicitly bring up the framework.
 
 Standalone specialist routes:
 
@@ -416,6 +418,7 @@ Standalone specialist routes:
 - `manage this project` -> `project-manager`
 - `refactor this` -> `refactorer`
 - `plan tests for this` -> `test-strategist`
+- `check optimization` / `review website optimization` -> `optimizer`
 - `check performance` -> `performance-reviewer`
 - `check accessibility` -> `accessibility-reviewer`
 - `write api contracts` -> `api-contract-writer`
@@ -432,6 +435,7 @@ Standalone route examples:
 - `document this install process`
 - `refactor this CLI without changing behavior`
 - `plan tests for this doctor command`
+- `check optimization for this landing page`
 - `write api contracts for the new endpoint`
 - `design sql schema for the booking tables`
 - `create database diagrams for this workflow`
@@ -448,8 +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, 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
@@ -473,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

@@ -20,19 +20,20 @@ Implement branch changes while preserving traceability and quality.
 
 ## Prerequisites
 
-- If branch memory does not exist yet, do not treat the request as automatic entry into `4-implementer`. Warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework for the current chat.
+- If branch memory does not exist yet, do not treat the request as automatic entry into `4-implementer`. Continue helping with the implementation request normally unless the user explicitly asks to initialize or explicitly asks for framework-stage behavior.
 - Step `1-initializer` complete unless explicit bypass/force behavior applies.
 - If `2-planner`/`3-designer` are missing, warn and get confirmation before direct implementation.
 
 ## Behavior
 
 - Update specs first when user intent changes.
-- If the user confirms outside-framework work because branch memory is missing, continue the rest of that chat outside the framework without re-asking for the same confirmation unless the user later asks to initialize or return to framework flow.
+- If branch memory is missing and the user did not ask to initialize, do not mention missing framework setup or create stage metadata from ordinary implementation requests.
 - Implement code changes and add/update tests proportionate to risk.
 - Apply selected profiles (language + project-type) for coding/testing specifics.
 - 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

@@ -6,12 +6,14 @@
 
 ## Purpose
 
-Review implementation for conformance, quality, security, and test sufficiency.
+Review implementation for conformance, quality, security, optimization, and test sufficiency.
 
 ## Canonical References
 
 - 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`
@@ -22,15 +24,24 @@ Review implementation for conformance, quality, security, and test sufficiency.
 
 ## Behavior
 
-- By default review both quality and security dimensions.
+- 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.
@@ -38,10 +49,13 @@ Review implementation for conformance, quality, security, and test sufficiency.
 ## 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

@@ -0,0 +1,53 @@
+# Optimizer
+
+> **Category:** Standalone role agent
+> **May change code:** Only if explicitly requested by the user and allowed by repo/framework rules
+> **Default framework file updates:** None unless explicitly asked, or when invoked as part of `5-code-reviewer`
+
+## Purpose
+
+Review websites and user-facing applications for optimization risks that affect real-user speed, Lighthouse/PageSpeed results, stability, and production behavior.
+
+## Behavior
+
+- Read `AGENTS.md`, relevant framework rules, relevant steering, and current branch specs if present.
+- Use website optimization as the default audit lens, not only narrow runtime profiling.
+- When invoked by `5-code-reviewer`, write findings into the `## Optimization findings` section of `05-code-review.md`.
+- 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
+
+Review all of the following when relevant:
+
+1. Reduce initial page work and startup cost.
+2. Split JavaScript carefully without over-splitting critical paths.
+3. Avoid duplicated app initialization and repeated global bootstrap work.
+4. Delay non-critical UI, effects, analytics, widgets, and third-party scripts.
+5. Optimize images, responsive delivery, compression, dimensions, and lazy loading.
+6. Optimize audio and video loading, preload behavior, posters, and autoplay choices.
+7. Optimize animations and visual effects, including canvas, parallax, observers, and reduced-motion behavior.
+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, 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, 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, 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, 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

@@ -36,9 +36,10 @@ This repository uses **united-we-stand**, a spec-driven AI workflow framework th
 - If branch memory does not exist yet, explicit init requests such as `init the following`, `initialize this`, `let's init this`, `help me with the following idea, i want...`, `let's start building this`, `i want to build...`, `i want to create...`, or `let's work on...` should be treated as permission to create the branch spec and start `1-initializer`.
 - When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory.
 - 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, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework instead of inferring a numbered stage.
-- If the user confirms outside-framework work, continue outside the framework for the rest of the current chat and do not ask for the same confirmation again unless the user later asks to initialize or return to normal framework flow.
-- 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 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 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).
@@ -87,6 +88,7 @@ Canonical source of these rules:
 - `project-manager`
 - `refactorer`
 - `test-strategist`
+- `optimizer`
 - `performance-reviewer`
 - `accessibility-reviewer`
 - `api-contract-writer`

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

@@ -8,10 +8,10 @@ Before acting:
 3. Read and update branch state under `.spec-driven/<sanitized-current-branch>/`.
 4. If present, read `.spec-driven/.branch-routing.json` to resolve branch-folder exceptions.
 
-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 the framework, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework for the current chat.
+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 the framework, continue helping with the request normally and do not interrupt to explain framework setup. Do not create `.spec-driven/...` files unless the user explicitly asks to initialize or explicitly brings up the framework.
 
 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

@@ -8,10 +8,10 @@ Before acting:
 3. Read and update branch state under `.spec-driven/<sanitized-current-branch>/`.
 4. If present, read `.spec-driven/.branch-routing.json` to resolve branch-folder exceptions.
 
-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 the framework, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework for the current chat.
+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 the framework, continue helping with the request normally and do not interrupt to explain framework setup. Do not create `.spec-driven/...` files unless the user explicitly asks to initialize or explicitly brings up the framework.
 
 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

@@ -11,10 +11,10 @@ Before acting:
 3. Read and update branch state under `.spec-driven/<sanitized-current-branch>/`.
 4. If present, read `.spec-driven/.branch-routing.json` to resolve branch-folder exceptions.
 
-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 the framework, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework for the current chat.
+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 the framework, continue helping with the request normally and do not interrupt to explain framework setup. Do not create `.spec-driven/...` files unless the user explicitly asks to initialize or explicitly brings up the framework.
 
 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

@@ -77,10 +77,10 @@ This file is the canonical source for global framework invariants.
     Workflow metadata is not independent from the branch folder contents. `Current stage` must always match the highest existing numbered stage file among `01-init.md` through `06-finalization.md`, and status checks must validate that alignment.
 
 25. **No implicit framework entry when branch memory is missing**
-    If branch memory does not exist yet and the user requests concrete code changes or other persistent work without explicitly asking to initialize the framework, do not silently enter a numbered framework stage. Warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework.
+    If branch memory does not exist yet and the user requests concrete code changes or other persistent work without explicitly asking to initialize the framework, do not silently enter a numbered framework stage and do not interrupt the user to announce missing framework setup. Continue helping with the request normally unless the user explicitly asks to initialize or explicitly brings up the framework.
 
-26. **Outside-framework confirmation is sticky for the current chat**
-    If the user confirms that the work should continue outside the framework, continue helping outside the framework for the rest of the current chat without asking for the same confirmation again unless the user later asks to initialize or return to normal framework flow.
+26. **Framework guidance should be user-invoked when branch memory is missing**
+    If branch memory does not exist yet, do not keep re-raising initialization or framework setup on ordinary work. Only surface initialization/framework guidance when the user explicitly asks to initialize, mentions the framework, or references installed framework files or commands.
 
 27. **Finalizer requires explicit closure confirmation**
     `6-finalizer` never treats itself as definitively done on its own. It must surface final observations, ask the user to confirm that the final state is acceptable, and only then close the workflow.
@@ -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:
 
@@ -165,13 +167,14 @@ Interpretation rule:
 If branch memory does not exist yet and the user requests concrete code changes or other persistent work without explicitly asking to initialize the framework:
 
 1. do not infer entry into `2-planner`, `3-designer`, `4-implementer`, `5-code-reviewer`, or `6-finalizer`
-2. warn clearly that united-we-stand is not initialized for the current branch
-3. ask whether to proceed outside the framework for the current chat
-4. if the user confirms outside-framework work, continue normally outside the framework and do not repeat the same confirmation again in that chat unless the user later asks to initialize or return to framework mode
+2. do not warn about missing framework initialization by default
+3. continue helping with the requested repo work normally
+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 one-time outside-framework confirmation stays sticky on the default branch too. Do not keep re-asking in the same chat once the user already chose to continue outside the framework.
+This silent fallback applies on the default branch too. Do not interrupt ordinary work on `main`/default branches just to explain framework setup.
 
 Examples that should trigger this warning-and-confirm flow when branch memory is missing:
 
@@ -188,6 +191,7 @@ Examples that should trigger this warning-and-confirm flow when branch memory is
 - `manage this project` -> `project-manager`
 - `refactor this` -> `refactorer`
 - `plan tests for this` -> `test-strategist`
+- `check optimization` / `review website optimization` -> `optimizer`
 - `check performance` -> `performance-reviewer`
 - `check accessibility` -> `accessibility-reviewer`
 - `write api contracts` -> `api-contract-writer`
@@ -204,9 +208,9 @@ Standalone routes should not mutate stage files unless user asks explicitly.
 
 When branch memory does not exist yet and user requests implementation or other persistent repo changes without explicit framework initialization:
 
-- warn that united-we-stand is not initialized for the branch
-- ask whether to proceed outside the framework for the current chat
-- if user confirms, continue outside the framework and do not re-ask unless the user later asks to initialize or return to framework mode
+- continue helping with the implementation request normally
+- do not mention missing framework setup unless the user explicitly asks about initialization or framework flow
+- do not create `.spec-driven/...` files or enter `4-implementer` metadata unless the user explicitly asks to initialize or explicitly asks for framework-stage behavior
 - if user explicitly wants to start the framework from implementation or another later stage, require explicit confirmation of that bypass path first
 
 When branch memory exists and user requests implementation and stages `2-planner` and/or `3-designer` are missing:

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,9 +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`