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.
Files changed (42) hide show
  1. package/.editorconfig +18 -0
  2. package/.env.example +3 -0
  3. package/.gitattributes +9 -0
  4. package/.githooks/pre-commit +52 -0
  5. package/.github/CODEOWNERS +2 -0
  6. package/.github/CODE_OF_CONDUCT.md +41 -0
  7. package/.github/CONTRIBUTING.md +194 -0
  8. package/.github/ISSUE_TEMPLATE/bug_report.yml +56 -0
  9. package/.github/ISSUE_TEMPLATE/config.yml +5 -0
  10. package/.github/ISSUE_TEMPLATE/feature_request.yml +38 -0
  11. package/.github/PULL_REQUEST_TEMPLATE.md +29 -0
  12. package/.github/SECURITY.md +23 -0
  13. package/.github/actions/setup/action.yml +20 -0
  14. package/.github/dependabot.yml +42 -0
  15. package/.github/scripts/bootstrap.sh +13 -0
  16. package/.github/scripts/ci.sh +245 -0
  17. package/.github/scripts/codeql-languages.sh +22 -0
  18. package/.github/scripts/doctor.sh +103 -0
  19. package/.github/scripts/init-repo.sh +109 -0
  20. package/.github/scripts/security.sh +51 -0
  21. package/.github/scripts/sitecustomize.py +17 -0
  22. package/.github/scripts/sync-protection.sh +124 -0
  23. package/.github/scripts/sync-template.sh +242 -0
  24. package/.github/template.yml.example +5 -0
  25. package/.github/workflows/ci.yml +72 -0
  26. package/.github/workflows/codeql.yml +56 -0
  27. package/.github/workflows/draft-pr.yml +62 -0
  28. package/.github/workflows/publish.yml +25 -0
  29. package/.github/workflows/release-pr.yml +61 -0
  30. package/.github/workflows/release.yml +23 -0
  31. package/.github/workflows/security.yml +38 -0
  32. package/.github/workflows/test.yml +84 -0
  33. package/.gitignore +73 -0
  34. package/.mise.toml +8 -0
  35. package/.prettierrc +6 -0
  36. package/AGENTS.md +154 -0
  37. package/LICENSE +616 -0
  38. package/NOTICE +7 -0
  39. package/README.md +94 -0
  40. package/package.json +42 -0
  41. package/ruff.toml +6 -0
  42. 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
@@ -0,0 +1,3 @@
1
+ # Copy this file to .env.local or the project-specific environment file.
2
+ # Add only non-secret, repository-specific variable names here.
3
+ # Never commit credentials, tokens, private keys, or production values.
package/.gitattributes ADDED
@@ -0,0 +1,9 @@
1
+ # Normalize text files to LF and keep binary assets untouched.
2
+ * text=auto eol=lf
3
+ *.png binary
4
+ *.jpg binary
5
+ *.jpeg binary
6
+ *.gif binary
7
+ *.webp binary
8
+ *.ico binary
9
+ *.pdf binary
@@ -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,2 @@
1
+ # Default owner for all repository files.
2
+ * @0xPlayerOne
@@ -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