Merge branch 'main' into chore/relax-dependency-review-policy

Author: Boyeep

.github/dependency-review-config.yml

@@ -0,0 +1,26 @@
+# Code of Conduct
+
+This project aims to be a welcoming, practical, and respectful place to build together.
+
+## Our Standard
+
+Contributors are expected to:
+
+- communicate with respect and patience
+- assume good intent and give constructive feedback
+- focus on the code and the idea, not the person
+- help keep the template reusable for many kinds of teams and projects
+
+Unacceptable behavior includes harassment, personal attacks, hateful language, doxxing, or deliberately disruptive conduct.
+
+## Scope
+
+This code of conduct applies to repository discussions, issues, pull requests, and other project spaces.
+
+## Reporting
+
+If you experience or witness unacceptable behavior, contact the repository maintainer privately through GitHub before opening a public thread.
+
+## Enforcement
+
+Project maintainers may remove comments, close threads, reject contributions, or block participation when behavior harms the project or its contributors.

.github/workflows/dependency-review.yml

@@ -95,10 +95,6 @@ npm run report:licenses
 
 That command writes generated reports into `reports/licenses/`.
 
-Dependency review also runs automatically on pull requests to catch newly introduced vulnerable dependency changes.
-
-That dependency review config also includes an allowlist for the licenses already present in the current dependency tree. If you intentionally add a dependency under a new acceptable license, update `.github/dependency-review-config.yml` in the same pull request.
-
 ## Changing the API Contract
 
 If you modify request or response shapes:

CODE_OF_CONDUCT.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Boyeep
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

CONTRIBUTING.md

@@ -123,12 +123,8 @@ The root check runs:
 
 CodeQL code scanning also runs on GitHub for `javascript-typescript`, `python`, and workflow files.
 
-Pull requests also run GitHub dependency review so new vulnerable dependency changes are easier to catch before merge.
-
 A separate GitHub workflow generates license-report artifacts for the root workspace, frontend workspace, and backend Python environment.
 
-The dependency-review config also keeps a conservative allowlist of licenses already present in the current dependency tree, so tightening policy does not start by breaking routine updates.
-
 An SBOM workflow also publishes SPDX artifacts for the repository source plus the frontend and backend runner images.
 
 ## Releases
@@ -159,3 +155,11 @@ An SBOM workflow also publishes SPDX artifacts for the repository source plus th
 5. Split training and experimentation into a separate workspace later.
 
 The short public roadmap lives in [soon.md](./soon.md).
+
+## Repository Standards
+
+- [CONTRIBUTING.md](./CONTRIBUTING.md)
+- [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)
+- [LICENSE](./LICENSE)
+- [SECURITY.md](./SECURITY.md)
+- [template-playbook.md](./template-playbook.md)

LICENSE

@@ -47,13 +47,17 @@ Build the second layer early, not after the repo gets messy.
 - `README.md`
 - `CONTRIBUTING.md`
 - `SECURITY.md`
+- `CODE_OF_CONDUCT.md` for public/community-facing templates
+- `LICENSE` for public templates
 - `AGENTS.md` or equivalent internal guidance
+- tool-specific agent guidance only if you actively maintain it
 - short roadmap file like `soon.md`
 
 ### Root Commands
 
 - `dev`
 - `check`
+- `e2e` if the repo ships real browser or full-stack user flows
 - `check:contract` if generated artifacts exist
 - `check:images` if the repo ships deployable containers
 - `check:workflows`
@@ -64,19 +68,21 @@ Build the second layer early, not after the repo gets messy.
 
 - workflow lint
 - secret scan
-- dependency review on pull requests
+- optional dependency review on pull requests if it stays low-noise for the repo
 - license reporting when dependency visibility matters
 - SBOM generation for source or publishable artifacts when relevant
 - app verification
+- browser E2E or integration coverage when the template markets real user flows
 - cross-platform check if relevant
 - packaging or Docker build check if relevant
 
 ### Release Layer
 
-- release drafter
+- release drafter or release-please
 - semver labels
 - label sync
 - publish workflow
+- managed changelog and version files if your release tool owns them
 - provenance attestations for published artifacts when possible
 - attach SBOMs to releases when you publish installable artifacts or images
 - release smoke test
@@ -113,13 +119,16 @@ Generic takeaway:
 - every serious starter should have a contributor guide
 - every serious starter should have an internal or agent-facing rules file
 - every public starter should have a security reporting path
+- every public starter should usually ship a code of conduct and explicit license
+- tool-specific AI guidance should be optional and maintained, not sprayed everywhere by default
 
 ### Root Script Layer
 
 Keep:
 
 - `scripts/dev.mjs`
 - `scripts/check.mjs`
+- `scripts/e2e.mjs`
 - `scripts/check-contract-drift.mjs`
 - `scripts/check-docker-builds.mjs`
 - `scripts/check-release-smoke.mjs`
@@ -139,6 +148,7 @@ Generic takeaway:
 
 - keep a root `dev` command
 - keep a root `check` command
+- add a root `e2e` command when the product story depends on real user flows
 - add small focused helper scripts instead of giant shell blobs in workflows
 - prefer reusable scripts that can run locally and in CI
 
@@ -229,8 +239,10 @@ What it should cover:
 - draft releases from merged PRs
 - path-based autolabeling
 - semver bump guidance through labels
-- tag-triggered release workflow
+- one clear release spine such as release-please or draft-plus-publish
+- tag-triggered release workflow or release PR merge flow
 - package or image publishing
+- managed changelog and version files when the release tool owns them
 - provenance attestations for published artifacts
 - attached SBOM release assets for published source and runtime artifacts
 - release smoke test against published artifacts
@@ -246,6 +258,7 @@ Why it matters:
 Generic takeaway:
 
 - if the repo is public and meant to last, release automation is worth it
+- pick one release automation path and document it clearly instead of mixing multiple half-systems
 - release smoke tests are especially valuable because they test the thing users actually consume
 - provenance attestations strengthen trust in published artifacts without requiring manual signing steps
 - attaching SBOMs directly to releases makes supply-chain metadata easier for downstream users to consume
@@ -279,8 +292,6 @@ Keep:
 - `scripts/report-licenses.mjs`
 - `.github/workflows/template-ci.yml`
 - `.github/workflows/codeql.yml`
-- `.github/workflows/dependency-review.yml`
-- `.github/dependency-review-config.yml`
 - `.github/workflows/license-report.yml`
 - `.github/workflows/sbom.yml`
 - `SECURITY.md`
@@ -289,7 +300,7 @@ What it should cover:
 
 - tracked git content scanned with `gitleaks` or equivalent
 - CodeQL or equivalent static analysis
-- dependency review on pull requests
+- optional dependency review on pull requests if it behaves cleanly for the dependency ecosystems in the repo
 - generated license inventories for package ecosystems in the repo
 - SBOM artifacts for source and release artifacts
 - private disclosure guidance
@@ -304,7 +315,7 @@ Generic takeaway:
 
 - secret scanning is a near-default for public repos
 - CodeQL or equivalent static analysis is a strong baseline for maintained starters
-- dependency review gives fast signal before risky packages land
+- dependency review can be useful, but it should be kept non-blocking or removed if it creates more noise than signal
 - non-blocking license reporting is a good bridge before stricter allowlist enforcement
 - SBOM generation is a strong supply-chain visibility layer for deployable templates
 
@@ -325,6 +336,25 @@ Generic takeaway:
 
 - if a repo relies on Actions, lint the workflows
 
+### Browser E2E Or Full-Stack Smoke Coverage
+
+Keep when relevant:
+
+- `scripts/e2e.mjs`
+- browser smoke workflow
+- stable seeded test account or fixture data
+
+Why it matters:
+
+- verifies real user journeys before release, not just units and builds
+- catches auth, routing, startup, and environment-wiring regressions
+- makes a public starter feel much more trustworthy
+
+Generic takeaway:
+
+- if the template markets login, dashboard, forms, or other full-stack flows, ship at least one browser E2E smoke path
+- keep it focused on stable happy-path journeys rather than UI trivia
+
 ### Post-Release Smoke Testing
 
 Keep when relevant:
@@ -390,6 +420,8 @@ For a strong public starter, this is a good baseline:
 README.md
 CONTRIBUTING.md
 SECURITY.md
+CODE_OF_CONDUCT.md
+LICENSE
 AGENTS.md
 soon.md
 .github/CODEOWNERS
@@ -398,9 +430,7 @@ soon.md
 .github/ISSUE_TEMPLATE/*
 .github/release-drafter.yml
 .github/labels.json
-.github/dependency-review-config.yml
 .github/workflows/template-ci.yml
-.github/workflows/dependency-review.yml
 .github/workflows/release-drafter.yml
 .github/workflows/release.yml
 .github/workflows/release-smoke.yml
@@ -410,6 +440,7 @@ soon.md
 .github/workflows/codeql.yml
 scripts/dev.mjs
 scripts/check.mjs
+scripts/e2e.mjs
 scripts/check-actionlint.mjs
 scripts/check-secrets.mjs
 scripts/report-licenses.mjs
@@ -421,11 +452,20 @@ Add these if relevant:
 scripts/check-contract-drift.mjs
 scripts/check-docker-builds.mjs
 scripts/check-release-smoke.mjs
+.github/dependency-review-config.yml
+.github/workflows/dependency-review.yml
 docs/assets/*
 docs/openapi.yaml
 tests/fixtures/*
 tests/snapshots/*
 src/app/docs-preview/*
+CHANGELOG.md
+version.txt
+release-please-config.json
+.release-please-manifest.json
+.github/copilot-instructions.md
+.cursor/rules/*
+CLAUDE.md
 ```
 
 ## Suggested Template Blueprint
@@ -437,13 +477,15 @@ For most future non-domain-specific starters, preserve this rough shape:
 - strong README
 - contributor guide
 - security policy
+- code of conduct and license for public templates
 - agent guidance
 - roadmap file
 
 ### Local DX
 
 - root `dev`
 - root `check`
+- root `e2e` when real user journeys matter
 - focused helper scripts
 - reproducible screenshots or docs previews if there is UI
 
@@ -452,13 +494,14 @@ For most future non-domain-specific starters, preserve this rough shape:
 - workflow lint
 - secret scan
 - app, test, and build verification
+- browser E2E when the product story promises real workflows
 - platform-specific verification if relevant
-- dependency review
+- optional dependency review if it is trustworthy for the repo
 - Docker or packaging check if deployable
 
 ### Release Layer
 
-- release drafter
+- release drafter or release-please
 - label sync
 - semver labeling rules
 - publish workflow
@@ -509,9 +552,10 @@ This is the minimum point where a repo starts feeling dependable.
 If you want the version that scales better for open source or long-term reuse, also add:
 
 - `AGENTS.md`
+- `CODE_OF_CONDUCT.md`
+- `LICENSE`
 - workflow lint
 - CodeQL
-- dependency review
 - label sync
 - release drafter
 - release smoke tests
@@ -558,14 +602,16 @@ These patterns are still generic even though the local implementation is CV-shap
 - generated files should have drift checks
 - local scripts and CI should use the same commands
 - published artifacts should get smoke-tested
+- repos with real user flows should have at least one browser E2E confidence path
 - workflows should be linted
 - secrets should be scanned
-- dependency changes should be reviewed on pull requests
+- dependency changes should be reviewed on pull requests when the signal is reliable enough to justify the maintenance cost
 - dependency licenses should be reportable without manual digging
 - SBOMs should be generated for source trees or release artifacts when supply-chain visibility matters
 - published artifacts should have provenance attestations when the platform supports them
 - release notes should tell consumers how to verify what you published
 - release steps should be automated
+- release automation should have one explicit owner path such as release-please or release-drafter-plus-publish
 - docs should explain maintainer flow, not just user setup
 
 ## Good Default Questions For Any New Template