code-foundry 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.editorconfig +18 -0
- package/.env.example +3 -0
- package/.gitattributes +9 -0
- package/.githooks/pre-commit +52 -0
- package/.github/CODEOWNERS +2 -0
- package/.github/CODE_OF_CONDUCT.md +41 -0
- package/.github/CONTRIBUTING.md +194 -0
- package/.github/ISSUE_TEMPLATE/bug_report.yml +56 -0
- package/.github/ISSUE_TEMPLATE/config.yml +5 -0
- package/.github/ISSUE_TEMPLATE/feature_request.yml +38 -0
- package/.github/PULL_REQUEST_TEMPLATE.md +29 -0
- package/.github/SECURITY.md +23 -0
- package/.github/actions/setup/action.yml +20 -0
- package/.github/dependabot.yml +42 -0
- package/.github/scripts/bootstrap.sh +13 -0
- package/.github/scripts/ci.sh +245 -0
- package/.github/scripts/codeql-languages.sh +22 -0
- package/.github/scripts/doctor.sh +103 -0
- package/.github/scripts/init-repo.sh +109 -0
- package/.github/scripts/security.sh +51 -0
- package/.github/scripts/sitecustomize.py +17 -0
- package/.github/scripts/sync-protection.sh +124 -0
- package/.github/scripts/sync-template.sh +242 -0
- package/.github/template.yml.example +5 -0
- package/.github/workflows/ci.yml +72 -0
- package/.github/workflows/codeql.yml +56 -0
- package/.github/workflows/draft-pr.yml +62 -0
- package/.github/workflows/publish.yml +25 -0
- package/.github/workflows/release-pr.yml +61 -0
- package/.github/workflows/release.yml +23 -0
- package/.github/workflows/security.yml +38 -0
- package/.github/workflows/test.yml +84 -0
- package/.gitignore +73 -0
- package/.mise.toml +8 -0
- package/.prettierrc +6 -0
- package/AGENTS.md +154 -0
- package/LICENSE +616 -0
- package/NOTICE +7 -0
- package/README.md +94 -0
- package/package.json +42 -0
- package/ruff.toml +6 -0
- package/src/cli.mjs +134 -0
package/.editorconfig
ADDED
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
root = true
|
|
2
|
+
|
|
3
|
+
[*]
|
|
4
|
+
charset = utf-8
|
|
5
|
+
end_of_line = lf
|
|
6
|
+
insert_final_newline = true
|
|
7
|
+
indent_style = space
|
|
8
|
+
indent_size = 2
|
|
9
|
+
trim_trailing_whitespace = true
|
|
10
|
+
|
|
11
|
+
[*.py]
|
|
12
|
+
indent_size = 4
|
|
13
|
+
|
|
14
|
+
[*.rs]
|
|
15
|
+
indent_size = 4
|
|
16
|
+
|
|
17
|
+
[Makefile]
|
|
18
|
+
indent_style = tab
|
package/.env.example
ADDED
package/.gitattributes
ADDED
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
set -euo pipefail
|
|
3
|
+
|
|
4
|
+
git diff --cached --check
|
|
5
|
+
changed=$(git diff --cached --name-only)
|
|
6
|
+
|
|
7
|
+
has_script() {
|
|
8
|
+
[ -f package.json ] && node -e 'const p=require("./package.json"); process.exit(p.scripts?.[process.argv[1]] ? 0 : 1)' "$1"
|
|
9
|
+
}
|
|
10
|
+
|
|
11
|
+
package_manager() {
|
|
12
|
+
if [ -f bun.lock ] || [ -f bun.lockb ]; then echo bun
|
|
13
|
+
elif [ -f pnpm-lock.yaml ]; then echo pnpm
|
|
14
|
+
elif [ -f yarn.lock ]; then echo yarn
|
|
15
|
+
else echo npm
|
|
16
|
+
fi
|
|
17
|
+
}
|
|
18
|
+
|
|
19
|
+
run_lint_staged() {
|
|
20
|
+
if ! has_script lint-staged; then return 1; fi
|
|
21
|
+
case "$(package_manager)" in
|
|
22
|
+
bun) bun run lint-staged ;;
|
|
23
|
+
pnpm) corepack pnpm run lint-staged ;;
|
|
24
|
+
yarn) corepack yarn run lint-staged ;;
|
|
25
|
+
npm) npm run lint-staged ;;
|
|
26
|
+
esac
|
|
27
|
+
}
|
|
28
|
+
|
|
29
|
+
if printf '%s\n' "$changed" | grep -Eq '\.(js|jsx|ts|tsx|json|md|mdx|yml|yaml)$'; then
|
|
30
|
+
if ! run_lint_staged; then
|
|
31
|
+
bash .github/scripts/ci.sh format
|
|
32
|
+
bash .github/scripts/ci.sh lint
|
|
33
|
+
fi
|
|
34
|
+
fi
|
|
35
|
+
|
|
36
|
+
if printf '%s\n' "$changed" | grep -Eq '\.rs$|(^|/)Cargo\.toml$'; then
|
|
37
|
+
cargo fmt --check
|
|
38
|
+
cargo clippy --all-targets -- -D warnings
|
|
39
|
+
fi
|
|
40
|
+
|
|
41
|
+
if printf '%s\n' "$changed" | grep -Eq '\.py$|(^|/)(pyproject\.toml|requirements(-dev)?\.txt)$'; then
|
|
42
|
+
if [ -x .venv/bin/ruff ]; then
|
|
43
|
+
.venv/bin/ruff format --check .
|
|
44
|
+
.venv/bin/ruff check .
|
|
45
|
+
elif command -v ruff >/dev/null 2>&1; then
|
|
46
|
+
ruff format --check .
|
|
47
|
+
ruff check .
|
|
48
|
+
else
|
|
49
|
+
echo "Python files changed but Ruff is not installed; run the template setup first." >&2
|
|
50
|
+
exit 1
|
|
51
|
+
fi
|
|
52
|
+
fi
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Contributor Covenant Code of Conduct
|
|
2
|
+
|
|
3
|
+
## Our Pledge
|
|
4
|
+
|
|
5
|
+
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
|
|
6
|
+
|
|
7
|
+
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
|
|
8
|
+
|
|
9
|
+
## Our Standards
|
|
10
|
+
|
|
11
|
+
Examples of behavior that contributes to a positive environment:
|
|
12
|
+
|
|
13
|
+
- Demonstrating empathy and kindness toward other people
|
|
14
|
+
- Respecting differing opinions, viewpoints, and experiences
|
|
15
|
+
- Giving and gracefully accepting constructive feedback
|
|
16
|
+
- Accepting responsibility and apologizing to those affected by mistakes
|
|
17
|
+
- Focusing on what is best for the overall community
|
|
18
|
+
|
|
19
|
+
Examples of unacceptable behavior:
|
|
20
|
+
|
|
21
|
+
- Sexualized language or imagery, and sexual attention or advances
|
|
22
|
+
- Trolling, insulting or derogatory comments, and personal or political attacks
|
|
23
|
+
- Public or private harassment
|
|
24
|
+
- Publishing another person's private information without explicit permission
|
|
25
|
+
- Other conduct that could reasonably be considered inappropriate in a professional setting
|
|
26
|
+
|
|
27
|
+
## Enforcement Responsibilities
|
|
28
|
+
|
|
29
|
+
Project maintainers are responsible for clarifying and enforcing these standards. They may remove, edit, or reject comments, commits, code, issues, and other contributions that do not align with this Code of Conduct.
|
|
30
|
+
|
|
31
|
+
## Scope
|
|
32
|
+
|
|
33
|
+
This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the project in public spaces.
|
|
34
|
+
|
|
35
|
+
## Enforcement
|
|
36
|
+
|
|
37
|
+
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported privately to the project maintainers using the contact method documented in [SECURITY.md](SECURITY.md). Reports will be reviewed and investigated promptly and fairly.
|
|
38
|
+
|
|
39
|
+
## Attribution
|
|
40
|
+
|
|
41
|
+
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1.
|
|
@@ -0,0 +1,194 @@
|
|
|
1
|
+
# Contributing
|
|
2
|
+
|
|
3
|
+
This guide is the operating contract for humans and automation contributing to this repository.
|
|
4
|
+
|
|
5
|
+
It applies to TypeScript, Rust, Python, and mixed-language projects using this template.
|
|
6
|
+
|
|
7
|
+
Quick links: [Code of Conduct](./CODE_OF_CONDUCT.md) · [Security Policy](./SECURITY.md) · [Pull Request Template](./PULL_REQUEST_TEMPLATE.md)
|
|
8
|
+
|
|
9
|
+
### Contents
|
|
10
|
+
|
|
11
|
+
[Agent contract](#agent-operating-contract) · [Branches](#branching-model) · [Setup](#before-you-start) · [Validation](#local-validation) · [Internal](#internal-contribution-workflow) · [External](#external-contribution-workflow) · [Pull requests](#pull-request-standards) · [Reviews](#review-and-merge-protocol) · [Security](#security-and-emergencies)
|
|
12
|
+
|
|
13
|
+
## Agent operating contract
|
|
14
|
+
|
|
15
|
+
Agents must follow these rules before changing code:
|
|
16
|
+
|
|
17
|
+
1. Read this file, `AGENTS.md`, and the relevant project documentation.
|
|
18
|
+
2. Inspect the current branch, worktree, remotes, and existing changes before editing.
|
|
19
|
+
3. Preserve user-owned changes. Never discard or overwrite unrelated work.
|
|
20
|
+
4. Branch from `staging` and target pull requests at `staging`; do not work directly on `main`.
|
|
21
|
+
5. Keep the change focused. Do not expand scope without documenting why.
|
|
22
|
+
6. Run the applicable format, lint, type-check, build, unit, integration, E2E, smoke, and security checks.
|
|
23
|
+
7. Report exact validation results, skipped checks, known limitations, and remaining risks.
|
|
24
|
+
8. Never commit secrets, credentials, local environment files, generated artifacts, or machine-specific paths.
|
|
25
|
+
|
|
26
|
+
Agents must not:
|
|
27
|
+
|
|
28
|
+
- Use destructive Git operations, force pushes, or history rewriting without explicit authorization.
|
|
29
|
+
- Bypass hooks or required checks to hide a failure.
|
|
30
|
+
- Change branch protections, secrets, deployments, or external systems unless that action is explicitly in scope.
|
|
31
|
+
- Claim completion when tests, deployment checks, or required reviews are still pending.
|
|
32
|
+
|
|
33
|
+
## Branching model
|
|
34
|
+
|
|
35
|
+
```text
|
|
36
|
+
release PR
|
|
37
|
+
┌──────────────┐
|
|
38
|
+
│ ▼
|
|
39
|
+
feat/* fix/* chore/* ──PR──▶ staging ──PR──▶ main
|
|
40
|
+
docs/* test/* refactor/* │ │
|
|
41
|
+
│ └── protected release branch
|
|
42
|
+
└── integration branch
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
| Branch | Purpose | Contribution rule |
|
|
46
|
+
| -------------------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------- |
|
|
47
|
+
| `main` | Protected release branch | Merge through the `staging` → `main` release PR. No direct pushes. |
|
|
48
|
+
| `staging` | Integration branch | Target normal pull requests here. Required checks must pass before merge. |
|
|
49
|
+
| `feat/*`, `fix/*`, `chore/*`, `refactor/*`, `docs/*`, `test/*` | Focused work | Branch from `staging`; keep changes small and reviewable. |
|
|
50
|
+
|
|
51
|
+
Use squash merges unless the repository documents another strategy. Re-align `staging` with `main` after a release when needed.
|
|
52
|
+
|
|
53
|
+
## Before you start
|
|
54
|
+
|
|
55
|
+
### Toolchain
|
|
56
|
+
|
|
57
|
+
1. Install [mise](https://mise.jdx.dev/).
|
|
58
|
+
2. Run `bash .github/scripts/bootstrap.sh` to install the pinned toolchain, enable hooks, and validate the checkout.
|
|
59
|
+
3. Use `bash .github/scripts/doctor.sh` when setup, lockfiles, or hooks appear out of sync.
|
|
60
|
+
4. Use the repository's existing package manager and lockfile. Do not introduce a second package manager.
|
|
61
|
+
5. Copy `.env.example` to the appropriate local environment file when provided. Never commit the copy.
|
|
62
|
+
|
|
63
|
+
### Worktree and branch
|
|
64
|
+
|
|
65
|
+
```sh
|
|
66
|
+
git status --short --branch
|
|
67
|
+
git fetch origin
|
|
68
|
+
git switch staging
|
|
69
|
+
git pull --ff-only origin staging
|
|
70
|
+
git switch -c feat/short-description
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
If the worktree is dirty, stop and understand the existing changes before switching branches or editing overlapping files.
|
|
74
|
+
|
|
75
|
+
## Local validation
|
|
76
|
+
|
|
77
|
+
The template scripts detect supported tools and skip checks that do not apply:
|
|
78
|
+
|
|
79
|
+
```sh
|
|
80
|
+
bash .github/scripts/ci.sh format
|
|
81
|
+
bash .github/scripts/ci.sh lint
|
|
82
|
+
bash .github/scripts/ci.sh type_check
|
|
83
|
+
bash .github/scripts/ci.sh build
|
|
84
|
+
bash .github/scripts/ci.sh unit
|
|
85
|
+
bash .github/scripts/ci.sh integration
|
|
86
|
+
bash .github/scripts/ci.sh e2e
|
|
87
|
+
bash .github/scripts/ci.sh smoke
|
|
88
|
+
bash .github/scripts/security.sh
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
Run the checks relevant to the change. For a release or security-sensitive change, run the complete set. Record the commands and results in the pull request.
|
|
92
|
+
|
|
93
|
+
## Internal contribution workflow
|
|
94
|
+
|
|
95
|
+
For maintainers, trusted contributors, and automation agents:
|
|
96
|
+
|
|
97
|
+
1. Start from an up-to-date `staging` branch.
|
|
98
|
+
2. Create a focused branch with a descriptive prefix.
|
|
99
|
+
3. Inspect the relevant code and tests before making changes.
|
|
100
|
+
4. Implement the smallest complete change.
|
|
101
|
+
5. Add or update tests, documentation, configuration, and migration notes as needed.
|
|
102
|
+
6. Run local validation and inspect the final diff.
|
|
103
|
+
7. Commit with a clear message, preferably using Conventional Commits:
|
|
104
|
+
|
|
105
|
+
```text
|
|
106
|
+
feat(auth): add passkey recovery
|
|
107
|
+
fix(api): handle expired session tokens
|
|
108
|
+
chore(ci): cache Rust dependencies
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
8. Push the branch and open a pull request into `staging`.
|
|
112
|
+
9. Address review feedback and failed checks on the same branch.
|
|
113
|
+
10. Squash-merge only after required checks pass and the change is ready.
|
|
114
|
+
|
|
115
|
+
### Internal agent handoff
|
|
116
|
+
|
|
117
|
+
Every agent handoff should state:
|
|
118
|
+
|
|
119
|
+
```text
|
|
120
|
+
Summary: what changed and why
|
|
121
|
+
Files: important files changed
|
|
122
|
+
Validation: exact commands and pass/fail results
|
|
123
|
+
Skipped: checks skipped and why
|
|
124
|
+
Risks: known limitations or follow-up work
|
|
125
|
+
Branch/PR: branch name and pull request link
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
## External contribution workflow
|
|
129
|
+
|
|
130
|
+
For contributors who do not have direct write access:
|
|
131
|
+
|
|
132
|
+
1. Fork the repository on GitHub.
|
|
133
|
+
2. Add the upstream repository as `upstream`.
|
|
134
|
+
3. Branch from the upstream `staging` branch.
|
|
135
|
+
4. Make a focused change and follow the local setup instructions.
|
|
136
|
+
5. Add tests and documentation for behavior changes.
|
|
137
|
+
6. Run all applicable checks locally.
|
|
138
|
+
7. Push to the fork and open a pull request targeting `staging`.
|
|
139
|
+
8. Explain the problem, proposed solution, validation, compatibility, and rollout impact.
|
|
140
|
+
9. Address maintainer feedback without rewriting unrelated history or scope.
|
|
141
|
+
|
|
142
|
+
External contributors should never need repository secrets or production access to validate a normal change.
|
|
143
|
+
|
|
144
|
+
## Pull request standards
|
|
145
|
+
|
|
146
|
+
Every pull request should make these questions easy to answer:
|
|
147
|
+
|
|
148
|
+
- What changed?
|
|
149
|
+
- Why was it needed?
|
|
150
|
+
- How was it tested?
|
|
151
|
+
- What could break?
|
|
152
|
+
- Does it require migration, deployment, configuration, or rollback work?
|
|
153
|
+
- Which files or areas deserve focused review?
|
|
154
|
+
|
|
155
|
+
Keep pull requests focused and reviewable. Include screenshots or recordings for user-facing changes. Link related issues and use `Closes #123` when appropriate. Complete the [pull request template](./PULL_REQUEST_TEMPLATE.md).
|
|
156
|
+
|
|
157
|
+
## Workflow and check behavior
|
|
158
|
+
|
|
159
|
+
| Event | Expected automation |
|
|
160
|
+
| -------------------------------- | ---------------------------------------- |
|
|
161
|
+
| Push to `main` or `staging` | CI, Test, Security, and CodeQL workflows |
|
|
162
|
+
| Pull request targeting `staging` | CI, Test, Security, and CodeQL workflows |
|
|
163
|
+
| Push to a working branch | Draft PR workflow |
|
|
164
|
+
| Push to `staging` | Release PR workflow |
|
|
165
|
+
| Version tag such as `v1.2.3` | Release workflow |
|
|
166
|
+
|
|
167
|
+
The workflows use separate concurrency groups. A newer run for the same branch or pull request cancels its older run, while independent CI, test, security, and CodeQL workflows continue in parallel.
|
|
168
|
+
|
|
169
|
+
Required checks are enforced by branch protection. Do not duplicate their checklists in the pull request description; document validation commands and results instead.
|
|
170
|
+
|
|
171
|
+
Security checks can be skipped when repository visibility or the GitHub plan does not support a feature. A skipped optional check must not be configured as a required status check.
|
|
172
|
+
|
|
173
|
+
## Review and merge protocol
|
|
174
|
+
|
|
175
|
+
| Change | Target | Merge gate |
|
|
176
|
+
| ----------------- | --------- | --------------------------------------------------------- |
|
|
177
|
+
| Working branch | `staging` | All applicable required checks pass |
|
|
178
|
+
| `staging` release | `main` | Current staging checks, release review, and rollout notes |
|
|
179
|
+
|
|
180
|
+
Reviewers focus on correctness, security, maintainability, test coverage, operational impact, and compatibility. Authors remain responsible for responding to feedback and verifying the final commit.
|
|
181
|
+
|
|
182
|
+
## Security and emergencies
|
|
183
|
+
|
|
184
|
+
Report vulnerabilities privately using [SECURITY.md](./SECURITY.md), never in a public issue or pull request.
|
|
185
|
+
|
|
186
|
+
For an urgent production or security issue:
|
|
187
|
+
|
|
188
|
+
1. Create a focused branch from `staging`.
|
|
189
|
+
2. Document the urgency and affected systems without exposing secrets.
|
|
190
|
+
3. Open a pull request and run the narrowest complete validation available.
|
|
191
|
+
4. Request the appropriate maintainer review.
|
|
192
|
+
5. Record follow-up work, remediation, and rollback information.
|
|
193
|
+
|
|
194
|
+
CI bypasses are for documented infrastructure emergencies only and require a follow-up fix. Never use a bypass to hide a code or test failure.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
name: Bug report
|
|
2
|
+
description: Report a reproducible problem or unexpected behavior
|
|
3
|
+
title: '[bug] '
|
|
4
|
+
labels: [bug]
|
|
5
|
+
body:
|
|
6
|
+
- type: textarea
|
|
7
|
+
id: environment
|
|
8
|
+
attributes:
|
|
9
|
+
label: Environment
|
|
10
|
+
description: Include the commit, branch, runtime/tool versions, operating system, and affected app or package.
|
|
11
|
+
placeholder: |
|
|
12
|
+
Commit:
|
|
13
|
+
Branch:
|
|
14
|
+
Runtime/tool versions:
|
|
15
|
+
OS:
|
|
16
|
+
App/package:
|
|
17
|
+
validations:
|
|
18
|
+
required: true
|
|
19
|
+
- type: textarea
|
|
20
|
+
id: description
|
|
21
|
+
attributes:
|
|
22
|
+
label: Description
|
|
23
|
+
description: Explain what happened, what you expected, and what actually occurred.
|
|
24
|
+
validations:
|
|
25
|
+
required: true
|
|
26
|
+
- type: textarea
|
|
27
|
+
id: reproduction
|
|
28
|
+
attributes:
|
|
29
|
+
label: Steps to reproduce
|
|
30
|
+
description: Provide the smallest reliable reproduction.
|
|
31
|
+
placeholder: |
|
|
32
|
+
1.
|
|
33
|
+
2.
|
|
34
|
+
3.
|
|
35
|
+
validations:
|
|
36
|
+
required: true
|
|
37
|
+
- type: textarea
|
|
38
|
+
id: diagnostics
|
|
39
|
+
attributes:
|
|
40
|
+
label: Error output and diagnostics
|
|
41
|
+
description: Include relevant logs, stack traces, CI run links, dependency changes, or screenshots. Remove secrets first.
|
|
42
|
+
- type: checkboxes
|
|
43
|
+
id: impact
|
|
44
|
+
attributes:
|
|
45
|
+
label: Impact
|
|
46
|
+
options:
|
|
47
|
+
- label: Blocks a deployment or pull request.
|
|
48
|
+
- label: Security or privacy impact is suspected; I will report details privately.
|
|
49
|
+
- label: Low priority or cosmetic.
|
|
50
|
+
- type: checkboxes
|
|
51
|
+
id: checks
|
|
52
|
+
attributes:
|
|
53
|
+
label: Checks
|
|
54
|
+
options:
|
|
55
|
+
- label: I searched existing issues and found no duplicate.
|
|
56
|
+
required: true
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
blank_issues_enabled: false
|
|
2
|
+
contact_links:
|
|
3
|
+
- name: Security vulnerability reporting
|
|
4
|
+
url: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory
|
|
5
|
+
about: Use this repository's Security tab to report vulnerabilities privately; do not open a public issue.
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
name: Feature request
|
|
2
|
+
description: Suggest an idea or improvement
|
|
3
|
+
title: '[feat] '
|
|
4
|
+
labels: [enhancement]
|
|
5
|
+
body:
|
|
6
|
+
- type: textarea
|
|
7
|
+
id: problem
|
|
8
|
+
attributes:
|
|
9
|
+
label: Problem
|
|
10
|
+
description: What problem would this feature solve? Be specific.
|
|
11
|
+
validations:
|
|
12
|
+
required: true
|
|
13
|
+
- type: textarea
|
|
14
|
+
id: proposal
|
|
15
|
+
attributes:
|
|
16
|
+
label: Proposed solution
|
|
17
|
+
description: Describe the desired behavior and relevant technical details.
|
|
18
|
+
validations:
|
|
19
|
+
required: true
|
|
20
|
+
- type: checkboxes
|
|
21
|
+
id: impact
|
|
22
|
+
attributes:
|
|
23
|
+
label: Impact
|
|
24
|
+
options:
|
|
25
|
+
- label: Breaking change
|
|
26
|
+
- label: New dependency required
|
|
27
|
+
- label: Changes CI, security, deployment, or configuration
|
|
28
|
+
- label: Low risk or additive only
|
|
29
|
+
- type: textarea
|
|
30
|
+
id: alternatives
|
|
31
|
+
attributes:
|
|
32
|
+
label: Alternatives
|
|
33
|
+
description: What alternatives have you considered?
|
|
34
|
+
- type: textarea
|
|
35
|
+
id: context
|
|
36
|
+
attributes:
|
|
37
|
+
label: Additional context
|
|
38
|
+
description: Add screenshots, mockups, links, acceptance criteria, or related issues.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
## Summary
|
|
2
|
+
|
|
3
|
+
<!-- What changed, why was it needed, and which issue or requirement does it address? -->
|
|
4
|
+
|
|
5
|
+
## Validation
|
|
6
|
+
|
|
7
|
+
<!-- List the commands, local checks, CI links, screenshots, or recordings used to validate this change. Required repository checks are enforced automatically. -->
|
|
8
|
+
|
|
9
|
+
- Commands run:
|
|
10
|
+
- CI or deployment links:
|
|
11
|
+
- Screenshots/recordings, when applicable:
|
|
12
|
+
|
|
13
|
+
## Impact and rollout
|
|
14
|
+
|
|
15
|
+
- [ ] No migration or rollout action is required
|
|
16
|
+
- [ ] Migration or rollout steps are documented below
|
|
17
|
+
- [ ] Environment or secret changes are documented below
|
|
18
|
+
- [ ] Security, privacy, compatibility, or performance impact is documented below
|
|
19
|
+
- [ ] Rollback or follow-up work is documented below
|
|
20
|
+
|
|
21
|
+
<!-- Add the relevant details here. -->
|
|
22
|
+
|
|
23
|
+
## Review notes
|
|
24
|
+
|
|
25
|
+
<!-- Call out tradeoffs, known limitations, generated files, dependency changes, or areas that need focused review. -->
|
|
26
|
+
|
|
27
|
+
## Related issue
|
|
28
|
+
|
|
29
|
+
<!-- Use `Closes #123` when applicable. -->
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Security Policy
|
|
2
|
+
|
|
3
|
+
## Supported Versions
|
|
4
|
+
|
|
5
|
+
The latest commit on `staging` receives security patches. Patches are promoted to `main` through the next release cycle.
|
|
6
|
+
|
|
7
|
+
| Branch | Supported |
|
|
8
|
+
| ---------------- | --------- |
|
|
9
|
+
| `staging` | ✅ |
|
|
10
|
+
| `main` | ✅ |
|
|
11
|
+
| Feature branches | ❌ |
|
|
12
|
+
|
|
13
|
+
## Reporting a Vulnerability
|
|
14
|
+
|
|
15
|
+
Do not open a public GitHub issue for a security vulnerability. Report it privately through the repository's Security tab, GitHub security advisory flow, or the private contact method listed on the repository page.
|
|
16
|
+
|
|
17
|
+
Include the affected version or commit, impact, reproduction steps, relevant logs, and suggested mitigation when possible.
|
|
18
|
+
|
|
19
|
+
Maintainers will acknowledge receipt, provide an assessment timeline, coordinate a fix, and agree with the reporter on responsible disclosure. Public disclosure should occur only after a fix or mitigation is available.
|
|
20
|
+
|
|
21
|
+
## Scope
|
|
22
|
+
|
|
23
|
+
This policy covers the code, configuration, dependencies, workflows, and generated artifacts maintained in this repository. Review `Security / Dependency Audit` results for supported ecosystems. Never commit credentials, tokens, private keys, or sensitive environment files. Report accidental secret exposure privately and rotate the credential immediately.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
name: Repository Setup
|
|
2
|
+
description: Install the pinned mise toolchain and optionally project dependencies.
|
|
3
|
+
|
|
4
|
+
inputs:
|
|
5
|
+
install:
|
|
6
|
+
description: Install dependencies for the detected project ecosystems.
|
|
7
|
+
required: false
|
|
8
|
+
default: 'false'
|
|
9
|
+
|
|
10
|
+
runs:
|
|
11
|
+
using: composite
|
|
12
|
+
steps:
|
|
13
|
+
- name: Setup
|
|
14
|
+
uses: jdx/mise-action@v4
|
|
15
|
+
with:
|
|
16
|
+
cache: true
|
|
17
|
+
- name: Install
|
|
18
|
+
if: inputs.install == 'true'
|
|
19
|
+
shell: bash
|
|
20
|
+
run: bash .github/scripts/ci.sh install
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
version: 2
|
|
2
|
+
updates:
|
|
3
|
+
- package-ecosystem: github-actions
|
|
4
|
+
directory: /
|
|
5
|
+
target-branch: staging
|
|
6
|
+
schedule:
|
|
7
|
+
interval: weekly
|
|
8
|
+
day: sunday
|
|
9
|
+
open-pull-requests-limit: 99
|
|
10
|
+
groups:
|
|
11
|
+
github-actions:
|
|
12
|
+
patterns: ['*']
|
|
13
|
+
- package-ecosystem: npm
|
|
14
|
+
directory: /
|
|
15
|
+
target-branch: staging
|
|
16
|
+
schedule:
|
|
17
|
+
interval: weekly
|
|
18
|
+
day: sunday
|
|
19
|
+
open-pull-requests-limit: 99
|
|
20
|
+
groups:
|
|
21
|
+
npm-dependencies:
|
|
22
|
+
patterns: ['*']
|
|
23
|
+
- package-ecosystem: cargo
|
|
24
|
+
directory: /
|
|
25
|
+
target-branch: staging
|
|
26
|
+
schedule:
|
|
27
|
+
interval: weekly
|
|
28
|
+
day: sunday
|
|
29
|
+
open-pull-requests-limit: 99
|
|
30
|
+
groups:
|
|
31
|
+
cargo-dependencies:
|
|
32
|
+
patterns: ['*']
|
|
33
|
+
- package-ecosystem: pip
|
|
34
|
+
directory: /
|
|
35
|
+
target-branch: staging
|
|
36
|
+
schedule:
|
|
37
|
+
interval: weekly
|
|
38
|
+
day: sunday
|
|
39
|
+
open-pull-requests-limit: 99
|
|
40
|
+
groups:
|
|
41
|
+
python-dependencies:
|
|
42
|
+
patterns: ['*']
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
set -euo pipefail
|
|
3
|
+
|
|
4
|
+
git config core.hooksPath .githooks
|
|
5
|
+
|
|
6
|
+
if command -v mise >/dev/null 2>&1; then
|
|
7
|
+
mise install
|
|
8
|
+
else
|
|
9
|
+
printf '%s\n' "mise is not installed; install it from https://mise.jdx.dev/ and rerun this script." >&2
|
|
10
|
+
exit 1
|
|
11
|
+
fi
|
|
12
|
+
|
|
13
|
+
bash .github/scripts/doctor.sh
|