@rudinmax87/united-we-stand 0.1.2 → 0.2.1

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**: 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

@@ -18,22 +18,21 @@ When force/bypass is applied:
 - set new `Current stage` explicitly
 - update `Next recommended step` accordingly
 
-## Outside-Framework Work
+## Direct Work Before Initialization
 
-If branch memory does not exist yet, working outside the framework is a separate mode from force/bypass:
+If branch memory does not exist yet, direct repo work without explicit initialization is separate from force/bypass:
 
-- warn that united-we-stand is not initialized for the branch
-- ask the user to confirm they want to continue outside the framework
+- continue helping with the requested work normally
 - do not create `.spec-driven/...` files unless the user explicitly asks to initialize
-- once the user confirms outside-framework work for the current chat, continue without repeating that confirmation unless they later ask to initialize or return to framework flow
+- do not interrupt to explain framework setup unless the user explicitly asks to initialize or explicitly mentions the framework
 
 ## 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
 
@@ -41,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

@@ -19,10 +19,11 @@ A **gap** is any requirement, feature, or constraint requested in earlier stages
 
 Use for implementation review requests.
 
-Default scope includes both:
+Default scope includes all of:
 
 - Quality and Maintainability
 - Adversarial Security and Boundaries
+- Optimization (default third check)
 
 User may explicitly narrow scope.
 
@@ -36,14 +37,25 @@ 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
-4. **Testing**
+4. **Optimization**
+   - initial page work, lazy-loading, and startup cost
+   - 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, 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
-5. **Documentation**
+6. **Documentation**
    - implementation and finalization notes are complete and truthful
 
 ## Output Requirements
@@ -53,6 +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
@@ -61,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

package/.united-we-stand/framework/13-vulnerability-audit-matrix.md

@@ -0,0 +1,54 @@
+# Vulnerability Audit Matrix
+
+Use the safest available path first:
+
+1. Prefer repo-native or package-manager-native vulnerability audit commands that require no extra install.
+2. If no native command exists, use repo-configured tooling only when it is already present.
+3. Do not install a new audit tool during review unless the user explicitly asks.
+4. If no safe no-install command exists, state that explicitly in the review output.
+5. Any detected dependency vulnerability must be reported as a high-priority review finding, even if the underlying tool labels it lower severity.
+
+## JavaScript / TypeScript
+
+- `package-lock.json`: `npm audit`
+- `pnpm-lock.yaml`: `pnpm audit`
+- `yarn.lock`: `yarn audit`, or the repo-configured Yarn equivalent if the active Yarn version does not expose that command
+
+## PHP / Composer
+
+- `composer.lock`: `composer audit`
+
+## .NET / NuGet
+
+- SDK-style projects when supported: `dotnet list package --vulnerable`
+
+## Python
+
+- No guaranteed no-extra-install native audit command in this framework baseline
+- Use repo-configured tooling only if it already exists
+
+## Ruby
+
+- No guaranteed no-extra-install native audit command in this framework baseline
+- Use repo-configured tooling only if it already exists
+
+## Rust
+
+- No guaranteed no-extra-install native audit command in this framework baseline
+- Use repo-configured `cargo audit` only if it already exists
+
+## Go
+
+- No guaranteed no-extra-install native audit command in this framework baseline
+- Use repo-configured `govulncheck` only if it already exists
+
+## Java
+
+- No guaranteed no-extra-install native audit command in this framework baseline
+- Use repo-configured Maven/Gradle security tasks only if they already exist
+
+## General Review Notes
+
+- Preserve the original command output details in your notes when they matter.
+- If a command fails because the package manager or runtime is missing, disclose that rather than pretending the audit passed.
+- Dependency-audit results do not replace manual review for injection, authz, or data-exposure issues.

package/.united-we-stand/framework/profiles/csharp.md

@@ -8,3 +8,5 @@
 ## Verification Guidance
 
 - Run build, test, analyzer, and package safety checks appropriate to the repo.
+- When supported by the active SDK/project style, run `dotnet list package --vulnerable`.
+- Review deserialization, injection, path handling, SSRF, authz, and secret exposure when relevant.

package/.united-we-stand/framework/profiles/go.md

@@ -9,4 +9,5 @@
 ## Verification Guidance
 
 - Run formatting, vetting, tests, and module checks appropriate to the repo.
-- Review dependency safety when modules change.
+- If `govulncheck` is already available or already configured by the repo, run it; otherwise explicitly disclose that this framework baseline has no guaranteed no-extra-install native Go vulnerability audit command.
+- Review dependency safety, input validation, path handling, SSRF, command execution, and auth boundaries when relevant.

package/.united-we-stand/framework/profiles/java.md

@@ -8,4 +8,5 @@
 ## Verification Guidance
 
 - Run build, test, and static checks appropriate to Maven/Gradle or the repo build system.
-- Check dependency safety when dependencies change.
+- Run repo-configured dependency vulnerability tasks when present; otherwise explicitly disclose that this framework baseline has no guaranteed no-extra-install native Java audit command.
+- Review injection, unsafe deserialization, SSRF, file-path handling, command execution, and auth boundaries when relevant.

package/.united-we-stand/framework/profiles/javascript-typescript.md

@@ -24,13 +24,15 @@
 - Avoid introducing vulnerable, deprecated, or unmaintained packages.
 - Keep dependencies minimal and justify new ones.
 - Treat ESLint, parser-based AST analysis, and similar static-analysis tooling as mandatory quality inputs when the repository provides them.
-- Run package audit commands when dependency graph changes:
-  - `npm audit`
-  - `pnpm audit`
-  - `yarn audit`
-- In npm-based repos, prefer running `npm audit` at implementation close when feasible.
+- Run the package-manager-native audit command for the active repo when a no-extra-install path exists:
+  - `package-lock.json` -> `npm audit`
+  - `pnpm-lock.yaml` -> `pnpm audit`
+  - `yarn.lock` -> `yarn audit`, or the repo-configured Yarn equivalent if the active Yarn version does not expose `yarn audit`
+- If no safe native audit command is available in the active environment, disclose that explicitly in implementation/review notes instead of silently skipping it.
 - Ensure user-controlled values do not flow into unsafe sinks without validation.
+- Review for XSS, SQL/NoSQL injection, command injection, path traversal, SSRF, CSRF, open redirects, unsafe deserialization, and secret exposure when relevant.
 - Ensure authn/authz ownership checks for resource-level operations.
+- For React/Next/Vite-style frontend work, apply `../12-react-frontend-review-checklist.md`.
 
 ## Testing and Validation
 
@@ -48,4 +50,5 @@ Reviewers should additionally check:
 - stale or dead code
 - unsafe data exposure in API responses
 - dependency risk introduced by new packages
+- dependency vulnerability findings reported as high priority regardless of underlying tool severity
 - lint/parser/static-analysis findings for the changed scope and whether they were addressed or intentionally deferred

package/.united-we-stand/framework/profiles/php.md

@@ -8,3 +8,5 @@
 ## Verification Guidance
 
 - Run lint, tests, static analysis, and dependency checks appropriate to Composer and the repo.
+- When `composer.lock` is present, run `composer audit`.
+- Review input validation, injection boundaries, file-path handling, authz, and secret exposure when relevant.

package/.united-we-stand/framework/profiles/python.md

@@ -13,4 +13,5 @@
 ## Verification Guidance
 
 - Run formatter, linter, tests, and packaging/build checks appropriate to the repo.
-- Run dependency vulnerability checks appropriate to the environment when dependencies change.
+- Prefer repo-configured dependency vulnerability tooling when present; otherwise explicitly disclose that Python has no guaranteed no-extra-install native audit command in this framework baseline.
+- Review input handling, deserialization, SSRF/file-path boundaries, command execution, and secret exposure when relevant.

package/.united-we-stand/framework/profiles/ruby.md

@@ -8,3 +8,5 @@
 ## Verification Guidance
 
 - Run tests, linters, and dependency safety checks appropriate to the repo.
+- Prefer repo-configured Ruby dependency safety tooling when present; otherwise explicitly disclose that this framework baseline has no guaranteed no-extra-install native Ruby audit command.
+- Review injection, unsafe metaprogramming/deserialization, command execution, and secret exposure when relevant.

package/.united-we-stand/framework/profiles/rust.md

@@ -8,4 +8,5 @@
 ## Verification Guidance
 
 - Run formatting, clippy, tests, and build checks appropriate to the repo.
-- Review crate safety when dependencies change.
+- If `cargo audit` is already available or already configured by the repo, run it; otherwise explicitly disclose that this framework baseline has no guaranteed no-extra-install native Rust vulnerability audit command.
+- Review unsafe blocks, deserialization/input boundaries, command execution, path handling, and crate safety when dependencies change.

package/.united-we-stand/framework/profiles/web-app.md

@@ -3,9 +3,12 @@
 ## Product Boundaries
 
 - Consider routing, screen states, loading/error states, form validation, auth boundaries, and accessibility.
+- Consider user-controlled input paths, client-visible secrets, unsafe redirects, third-party script impact, and reduced-motion handling when relevant.
+- For React/Next/Vite-style web apps, apply `../12-react-frontend-review-checklist.md` during implementation and review.
 
 ## Verification
 
 - Verify affected pages, components, or flows render correctly in local/dev environment when applicable.
 - Confirm client-visible error handling and loading states where impacted.
-- Confirm impacted routes boot without runtime crashes.
+- Confirm impacted routes boot without runtime crashes.
+- After fixes, verify that key user-facing flows still work and that no intended functionality was removed while resolving the issue.

package/.united-we-stand/spec-driven/branch-template/01-init.md

@@ -22,3 +22,6 @@ TBD
 
 ## Success criteria
 TBD
+
+## Security / dependency concerns
+TBD

package/.united-we-stand/spec-driven/branch-template/02-plan.md

@@ -12,6 +12,9 @@ TBD
 ## Risks / unknowns
 TBD
 
+## Security / dependency risk plan
+TBD
+
 ## Suggested execution order
 TBD
 

package/.united-we-stand/spec-driven/branch-template/03-design.md

@@ -15,8 +15,11 @@ TBD
 ## Constraints
 TBD
 
+## Security boundaries / attack surface
+TBD
+
 ## Design decisions
 TBD
 
 ## Mermaid diagrams
-TBD
+TBD

package/.united-we-stand/spec-driven/branch-template/05-code-review.md

@@ -3,14 +3,26 @@
 ## Quality & maintainability findings
 TBD
 
+## Vulnerability audit findings
+TBD
+
 ## Security / boundary findings
 TBD
 
+## Optimization findings
+TBD
+
 ## Severity / priority
 TBD
 
 ## Recommended fixes
 TBD
 
+## Lint/parser/static-analysis observations
+TBD
+
+## Residual risks
+TBD
+
 ## Reviewed scope and non-reviewed scope
-TBD
+TBD