@rudinmax87/united-we-stand 0.2.0 → 0.2.1

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

package/PACKAGE-PUBLISHING.md

@@ -0,0 +1,403 @@
+# Package Publishing
+
+## Local Development
+
+Install dependencies:
+
+```bash
+npm install
+```
+
+Build the package:
+
+```bash
+npm run build
+```
+
+Run unit/integration tests:
+
+```bash
+npm test
+```
+
+Run built-CLI smoke tests:
+
+```bash
+npm run test:e2e
+```
+
+## Source Of Truth Areas
+
+- framework runtime assets: `.united-we-stand/**`
+- CLI behavior: `src/commands/**` and `src/lib/**`
+- package metadata: `package.json`
+- publish preparation for GitHub Packages: `scripts/prepare-github-publish.mjs`
+
+## Installed Editor Integration Files
+
+When users run `united-we-stand install`, the framework also installs lightweight editor/agent integration pointers that redirect tools back to the root `AGENTS.md` file instead of duplicating rules.
+
+Installed pointer files:
+
+- `.github/copilot-instructions.md`
+- `.agents/workflows/united-we-stand.md`
+- `.cursor/rules/united-we-stand.mdc`
+
+## Publish Targets
+
+This repository is prepared for two scoped publish targets.
+
+Current examples in this repository:
+
+- public npm package: `@rudinmax87/united-we-stand`
+- GitHub Packages package: `@mrudinal/united-we-stand`
+
+If you adapt this publish flow for your own fork or package, replace those scopes with your own npm scope and GitHub owner scope.
+
+Because the required scopes are different, the repository uses:
+
+- the root `package.json` for npm publishing
+- a generated temporary artifact for GitHub Packages publishing
+
+## Build The Publish Artifact
+
+When you publish to npm, you are publishing the package artifact generated from this repository, not a Docker image.
+
+The npm package artifact for this repository consists of:
+
+- compiled CLI output
+- `.united-we-stand/**`
+- `README.md`
+- `LICENSE`
+
+Those shipped files are defined in `package.json` under `files`.
+
+If you want to inspect the package tarball locally before publishing, run:
+
+```bash
+npm pack
+```
+
+That creates a local `.tgz` archive containing the exact npm package contents that would be published from the root package.
+
+## Publish To Scoped npm
+
+This repository is currently configured to publish the root package as:
+
+- `@rudinmax87/united-we-stand`
+
+If you are publishing your own scoped variant, replace that name with your own npm scope and package name.
+
+### Requirements
+
+Before publishing to npm, make sure all of the following are true:
+
+- you have Node.js 18+ installed
+- you have npm installed
+- you have an npm account
+- your npm account has access to the package scope you plan to publish under
+- you are logged in with the npm CLI
+- the package `version` in `package.json` is the version you want to publish
+- the package builds and tests pass locally
+
+Optional but recommended checks:
+
+- confirm the current npm user with `npm whoami`
+- confirm the target registry with `npm config get registry`
+- inspect the tarball with `npm pack`
+
+### Step-by-step
+
+#### 1. Install dependencies
+
+```bash
+npm install
+```
+
+#### 2. Build the package
+
+```bash
+npm run build
+```
+
+#### 3. Run the test suite
+
+```bash
+npm test
+npm run test:e2e
+```
+
+#### 4. Confirm the package version and scoped name
+
+Check `package.json` and confirm:
+
+- `name` is the package name you intend to publish
+- `version` is the release version you want to publish
+
+For this repository today, the configured name is `@rudinmax87/united-we-stand`.
+
+#### 5. Log in to npm
+
+```bash
+npm login
+```
+
+If you want to verify the authenticated user:
+
+```bash
+npm whoami
+```
+
+#### 6. Optionally build the publish tarball locally
+
+```bash
+npm pack
+```
+
+This lets you inspect the exact package contents before publishing.
+
+#### 7. Publish the scoped package
+
+```bash
+npm publish --access public
+```
+
+The root `package.json` already includes:
+
+- scoped package name for this repository
+- `publishConfig.access = public`
+
+So `npm publish` is usually enough, but `npm publish --access public` makes the intended access mode explicit for a scoped public package.
+
+### Quick publish command sequence
+
+```bash
+npm install
+npm run build
+npm test
+npm run test:e2e
+npm login
+npm whoami
+npm pack
+npm publish --access public
+```
+
+## Publish To GitHub Packages
+
+This repository can also be published to GitHub Packages as:
+
+- `@mrudinal/united-we-stand`
+
+GitHub Packages for npm uses:
+
+- registry: `https://npm.pkg.github.com`
+- scoped package name: `@mrudinal/united-we-stand`
+
+Treat `@mrudinal` as the current example owner scope for this repository. If you publish from your own fork or organization, replace it with your own GitHub Packages scope.
+
+### Requirements
+
+Before publishing to GitHub Packages, make sure all of the following are true:
+
+- you have Node.js 18+ and npm installed
+- you have a GitHub account with access to the repository that owns the package
+- you have a GitHub `personal access token (classic)`
+- that token has at least:
+  - `write:packages`
+  - `read:packages`
+- you are authenticated to `https://npm.pkg.github.com`
+- the package builds and tests pass locally
+
+Important:
+
+- GitHub Packages for npm currently uses `personal access token (classic)` authentication
+- for npm CLI v9+, GitHub recommends `--auth-type=legacy` when logging in from the command line
+
+### Step-by-step
+
+#### 1. Build and validate the package
+
+```bash
+npm install
+npm run build
+npm test
+npm run test:e2e
+```
+
+#### 2. Create a GitHub personal access token (classic)
+
+Create a token in GitHub with:
+
+- `write:packages`
+- `read:packages`
+
+If you also want to delete packages later, add:
+
+- `delete:packages`
+
+#### 3. Authenticate npm to GitHub Packages
+
+You can authenticate in either of these ways.
+
+Option A: add your token to `~/.npmrc`
+
+```ini
+//npm.pkg.github.com/:_authToken=YOUR_GITHUB_PAT_CLASSIC
+```
+
+Option B: log in with npm
+
+```bash
+npm login --scope=@YOUR_GITHUB_SCOPE --auth-type=legacy --registry=https://npm.pkg.github.com
+```
+
+Example for this repository:
+
+```bash
+npm login --scope=@mrudinal --auth-type=legacy --registry=https://npm.pkg.github.com
+```
+
+When prompted, use:
+
+- Username: your GitHub username
+- Password: your GitHub personal access token (classic)
+- Email: your GitHub account email
+
+#### 4. Prepare the GitHub-scoped publish artifact
+
+```bash
+npm run prepare:publish:github
+```
+
+That creates:
+
+- a temporary GitHub-scoped publish artifact
+- a GitHub-scoped package manifest
+- the compiled CLI output and installed framework assets needed for publication
+
+#### 5. Inspect the generated publish artifact
+
+Confirm that these files exist:
+
+- the generated GitHub-scoped package manifest
+- the generated compiled CLI output
+- the generated `.united-we-stand/` asset copy
+
+The generated `package.json` in that folder is already configured for:
+
+- package name: `@mrudinal/united-we-stand`
+- registry: `https://npm.pkg.github.com`
+
+#### 6. Publish from the generated folder
+
+Publish from the generated GitHub artifact directory created by `npm run prepare:publish:github`.
+
+The publish command is typically:
+
+```bash
+npm publish .publish/github
+```
+
+Run it from the repository root after inspecting the prepared package manifest.
+
+The generated GitHub Packages artifact uses:
+
+- package name: `@mrudinal/united-we-stand`
+- registry: `https://npm.pkg.github.com`
+
+### Quick GitHub Packages publish sequence
+
+```bash
+npm install
+npm run build
+npm test
+npm run test:e2e
+npm login --scope=@YOUR_GITHUB_SCOPE --auth-type=legacy --registry=https://npm.pkg.github.com
+npm run prepare:publish:github
+npm publish .publish/github
+```
+
+Example scope for this repository: `@mrudinal`
+
+
+```bash
+npm install
+npm run build
+npm test
+npm run test:e2e
+npm login --scope=@mrudinal --auth-type=legacy --registry=https://npm.pkg.github.com
+npm run prepare:publish:github
+npm publish .publish/github
+```
+
+### Verify The GitHub Package Exists
+
+After publishing, verify the package in both the CLI and the GitHub UI.
+
+#### Verify from the CLI
+
+If you already authenticated npm to GitHub Packages, run:
+
+```bash
+npm view @YOUR_GITHUB_SCOPE/united-we-stand version --registry=https://npm.pkg.github.com
+```
+
+Example for this repository:
+
+```bash
+npm view @mrudinal/united-we-stand version --registry=https://npm.pkg.github.com
+```
+
+You can also inspect more package metadata:
+
+```bash
+npm view @YOUR_GITHUB_SCOPE/united-we-stand --registry=https://npm.pkg.github.com
+```
+
+Example for this repository:
+
+```bash
+npm view @mrudinal/united-we-stand --registry=https://npm.pkg.github.com
+```
+
+If the package is visible and the publish succeeded, npm will return the published version and metadata instead of a not found or auth error.
+
+#### Verify in the GitHub UI
+
+Open GitHub and check the package in the UI:
+
+1. Go to your GitHub profile or the owning account.
+2. Open the `Packages` tab.
+3. Look for `united-we-stand`.
+4. Open the package page and confirm:
+   - package name matches your published scope and package name
+   - the newly published version is listed
+   - installation instructions and package metadata are visible
+
+For this repository today, the example package name is `@mrudinal/united-we-stand`.
+
+You can also check the repository sidebar for the linked package if GitHub associates the package with your repository.
+
+#### Visibility Warning for First GitHub Packages Publish
+
+If you publish a GitHub npm package under a personal account scope for the first time, GitHub may create it as `private` by default even if your package is intended to be public.
+
+After the first publish, check the package page in GitHub:
+
+1. Open the package.
+2. Go to `Package settings`.
+3. In the visibility controls, change the package to `Public` if needed.
+
+Important:
+
+- this visibility change is done in the GitHub UI, not by regenerating the package artifact
+- you do not need to publish a new package just to change a newly created package from private to public
+- once a GitHub package is made public, GitHub may not allow changing it back to private
+
+### Notes
+
+- publish to npmjs.com and publish to GitHub Packages are separate flows
+- the root package publishes to npm as `@rudinmax87/united-we-stand`
+- the generated temporary GitHub artifact publishes to GitHub Packages as `@mrudinal/united-we-stand`
+- replace those example scopes with your own if you publish from a different owner account or fork
+- if authentication fails during GitHub Packages publish, re-check that your token is a `personal access token (classic)` with `write:packages`

package/README.md

@@ -55,6 +55,7 @@ The built package ships:
 
 - compiled CLI output
 - `.united-we-stand/**`
+- `PACKAGE-PUBLISHING.md`
 - `README.md`
 - `LICENSE`
 
@@ -168,11 +169,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 |
 
 Each stage document can be updated later, either manually or by asking the agent in the chat, if the work changes or the plan evolves. When moving to the next stage, the AI should use the latest version of those written documents as the main source of truth, instead of depending only on the chat.
@@ -246,7 +247,7 @@ what is the current status of united-we-stand
 
 ## Creating Your Own Package
 
-If you want to generate and publish your own package variant of this framework, follow [the maintainer guide](https://github.com/mrudinal/united-we-stand-framework/blob/main/docs/generate-your-own-package.md).
+If you want to generate and publish your own package variant of this framework, follow [PACKAGE-PUBLISHING.md](./PACKAGE-PUBLISHING.md).
 
 ## Contents in this repository
 
@@ -279,6 +280,7 @@ repo-root/
 |   `-- lib/
 |-- tests/
 |-- LICENSE
+|-- PACKAGE-PUBLISHING.md
 |-- package-lock.json
 |-- package.json
 |-- README.md

package/dist/commands/branch-init.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"branch-init.d.ts","sourceRoot":"","sources":["../../src/commands/branch-init.tsx"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAiCH,MAAM,WAAW,kBAAkB;IAC/B,gBAAgB,EAAE,MAAM,CAAC;IACzB,QAAQ,EAAE,OAAO,CAAC;IAClB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,KAAK,CAAC,EAAE,OAAO,CAAC;CACnB;AAgMD,wBAAsB,oBAAoB,CAAC,OAAO,EAAE,kBAAkB,GAAG,OAAO,CAAC,IAAI,CAAC,CA4NrF"}
+{"version":3,"file":"branch-init.d.ts","sourceRoot":"","sources":["../../src/commands/branch-init.tsx"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAiCH,MAAM,WAAW,kBAAkB;IAC/B,gBAAgB,EAAE,MAAM,CAAC;IACzB,QAAQ,EAAE,OAAO,CAAC;IAClB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,KAAK,CAAC,EAAE,OAAO,CAAC;CACnB;AAgMD,wBAAsB,oBAAoB,CAAC,OAAO,EAAE,kBAAkB,GAAG,OAAO,CAAC,IAAI,CAAC,CA8NrF"}