ora-284-opencode-prompt-pad
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Devin Foley
|
4518f272b2 |
fix(release): publish all remaining @paperclipai workspace packages from CI + guard unpublishable edges (#8365)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work, distributed primarily via the `paperclipai` npm package and its `@paperclipai/*` workspace packages. > - The release subsystem (`scripts/release-package-*`) decides which workspace packages CI republishes at the unified calver version each release, and `replaceWorkspaceDeps()` rewrites every internal `workspace:` dependency to that calver version at publish time. > - The gap: a package that publishes from CI can declare a `workspace:` dependency on a package that is NOT enrolled for CI publish. The dependency spec gets rewritten to a calver version that is never actually published, so the dependent becomes uninstallable. > - This shipped for real: a recent change made `@paperclipai/server` depend on `@paperclipai/skills-catalog`, but skills-catalog was not on the calver release train — so canary builds after that merge failed to resolve `@paperclipai/skills-catalog@<calver>` and `npx paperclipai@canary run` broke. > - This PR addresses it durably by (a) putting every remaining internal package on the CI release train so no internal dependency can dangle, and (b) adding a fail-fast guard so this class of break can never ship again. > - The benefit is that canary and stable installs resolve all internal dependencies, and any future unpublishable workspace edge fails the release build with a clear, named error instead of producing a broken package. ## Linked Issues or Issue Description Refs #8327 (introduced the `server -> skills-catalog` runtime dependency that surfaced the gap). No public issue tracks this; describing it in-PR: - **Problem:** After #8327, `npx paperclipai@canary run` failed for builds past the merge because `@paperclipai/skills-catalog` was rewritten to a calver version that was never published (the package was not enrolled for CI publish). Versions before the merge still ran. - **Root cause:** A `publishFromCi:true` package can declare a `workspace:` dependency on a package that is not `publishFromCi:true`; the release-time version rewrite then points at a non-existent published version. ## What Changed - Enrolled every remaining internal package on the calver release train by setting `publishFromCi: true` in `scripts/release-package-manifest.json`: `skills-catalog`, `teams-catalog`, `plugin-workspace-diff`, `plugin-kubernetes`, `plugin-novita-sandbox`. There are now zero `publishFromCi:false` entries. - `skills-catalog`, `teams-catalog`, `plugin-workspace-diff` already existed on npm — CI simply republishes them at calver. - `plugin-kubernetes` and `plugin-novita-sandbox` were not on npm; their one-time first publish was bootstrapped so the `check-release-package-bootstrap` gate passes. - Added `findUnpublishableWorkspaceEdges()` to `scripts/release-package-map.mjs`, wired into `buildReleasePackagePlan()`. The release map build now fails fast (surfaced by the `check` CI already runs) whenever a `publishFromCi:true` package declares a runtime `workspace:` dependency (`dependencies`/`optionalDependencies`/`peerDependencies`) on a non-`publishFromCi:true` `@paperclipai/*` package, naming the offending edge. - Added tests covering positive/negative detection, all three dependency sections, unknown-package edges, off-train edges, and the live manifest. ## Verification - `node --test scripts/release-package-map.test.mjs` → 9/9 pass (includes a test asserting the live manifest has no unpublishable edges). - `node scripts/check-release-package-bootstrap.mjs scripts/release-package-manifest.json` → passes, naming all five newly-enabled packages (all confirmed present on npm). - Confirmed via `npm view` that all five packages resolve on the public registry. ## Risks - Low risk. The change only enrolls already-existing (or freshly-bootstrapped) packages onto the existing release train and adds a build-time validation. No runtime code paths change. The new guard can only *fail* a release that was already going to ship a broken package. ## Model Used Claude Opus 4.7 (claude-opus-4-7), extended thinking, with tool use / code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots (N/A — no UI changes) - [x] I have updated relevant documentation to reflect my changes (N/A — no doc-facing behavior change) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge |
||
|
Devin Foley
|
47bd02647c |
fix(commitperclip): stop security gate from hanging the review check (#7847)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The commitperclip review workflow runs a security gate as part of CI on every PR > - The security script's header promises it always exits 0 and stays silent/informational, but PRs that triggered a flag were failing with a 5-minute timeout > - Two compounding bugs: `findExistingDraftAdvisory` paginated without an upper bound, and the workflow step did not have `continue-on-error: true`, so any hang inside the script turned into a hard `review` check failure that blocked merge > - This pull request caps the advisory pagination at 20 pages and adds `continue-on-error: true` to the workflow step, aligning runtime behavior with the script's documented "always exit 0" contract > - The benefit is that future PRs flagged by the security gate no longer block merge on a 5-minute timeout, and the gate stays silent/informational as intended ## Linked Issues or Issue Description Fixes: #7849 ## What Changed - `.github/workflows/commitperclip-review.yml`: added `continue-on-error: true` to the `Run security gates` step so a hang or non-zero exit cannot fail the `review` check (matches the script's documented "always exit 0" contract). - `.github/scripts/check-pr-security.mjs`: capped `findExistingDraftAdvisory` pagination at 20 pages (= 2000 advisories) and short-circuited with a `console.warn` when the cap is hit; if no match is found within the cap, callers will simply create a new draft instead of hanging forever. - `.github/scripts/tests/check-pr-security.test.mjs`: added a test asserting the pagination cap is enforced. ## Verification - `node .github/scripts/tests/check-pr-security.test.mjs` — 31/31 pass, including the new cap test. - Step-level guarantee: `continue-on-error: true` makes the `Run security gates` step non-blocking for the job, so even an unexpected hang/timeout in this step can no longer fail the `review` check. ## Risks - Low risk. Pagination cap is a defensive bound; the worst case is a duplicate draft advisory (acceptable — the workflow continues). `continue-on-error: true` is exactly what the script header already promised; the workflow now matches its stated contract. ## Model Used - Claude (claude-opus-4-7), extended thinking, tool use ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Devin Foley
|
d5889919a9 |
feat(commitperclip): widen linked-issue gate, add dedup-search check (#7632)
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work
> - Contributor onboarding leans on a small set of CI gates
("commitperclip") that read PR metadata and enforce the rules in
CONTRIBUTING.md
> - We recently landed two new contributor rules: every PR must either
link an existing issue or inline an issue-template-shaped description,
and the author must affirm they searched for duplicate PRs first
> - The existing `check-pr-linked-issue` gate only accepted
`Fixes/Closes/Resolves #N`, and there was no gate at all for the
dedup-search affirmation, so the new rules were unenforced
> - This pull request widens the linked-issue gate (accept `Refs #N`,
accept inline template-shaped descriptions) and adds a new dedup-search
gate wired into `run-quality-gates`
> - The benefit is that the rules we ask contributors to follow are now
mechanically enforced, lowering review noise without raising contributor
friction
## Linked Issues or Issue Description
Refs #4260 — the PR cited in the original rule discussion, whose body is
the canonical example of the inline-issue-description shape this gate
now accepts.
**Problem or motivation**
The repo recently adopted two contributor rules: (1) link the issue your
PR fixes or inline a description in the issue-template shape, and (2)
confirm you searched for duplicate PRs before opening one. Neither rule
was enforced — the existing linked-issue check only matched
`Fixes/Closes/Resolves #N`, and nothing looked for the dedup-search
affirmation. Reviewers had to remember and re-state the rules by hand on
every PR.
**Proposed solution**
Widen `check-pr-linked-issue.mjs` and add a new
`check-pr-dedup-search.mjs` so commitperclip enforces the rules already
documented in CONTRIBUTING.md and the PR template:
- Accept `Refs #N` as a valid link verb alongside `Fixes`, `Closes`,
`Resolves`.
- Accept a PR body with an inline issue-template-shaped description (≥3
fields matched against the bug, feature, or adapter templates) as a
valid alternative to a linked issue.
- New `check-pr-dedup-search.mjs` looks for a checked checkbox affirming
the author searched for similar/duplicate/prior PRs, wired into
`run-quality-gates.mjs` with the same skip/override semantics as the
other gates.
**Alternatives considered**
- A single regex over the whole PR body looking for issue-template field
names — rejected, too brittle and gave no useful error message when it
failed. The per-field counter lets us tell the author exactly how many
template fields we matched and which template they're closest to.
- Making the dedup-search check live inside `check-pr-linked-issue` —
rejected, the two rules are orthogonal and a separate gate gives a
cleaner error message and respects `[skip-quality-gates]` independently.
**Roadmap alignment**
This is contributor-workflow plumbing for rules that already landed on
`master`. It is not a roadmap feature and does not overlap with planned
core work.
## What Changed
- `check-pr-linked-issue.mjs`: accept `Refs #N`; add
`hasInlineIssueDescription` (per-template field counter, ≥3 fields) so a
fully inlined description satisfies the gate.
- `check-pr-dedup-search.mjs`: new gate, looks for a checked
dedup-search checkbox in the PR body, with clear failure guidance.
- `run-quality-gates.mjs`: wire the new gate in alongside the existing
checks.
- `CONTRIBUTING.md`: "Before You Start: Search First" callout pointing
at the PR-template checkbox the gate enforces.
- Tests: unit tests for `Refs #N`, the inline-description threshold
(bolded labels, plain labels, headings), and the dedup-search gate
across checked/unchecked/missing/skip-prefix paths.
## Verification
- `node --test .github/scripts/tests/check-pr-linked-issue.test.mjs` →
all pass
- `node --test .github/scripts/tests/check-pr-dedup-search.test.mjs` →
all pass
- Full repo test matrix: 116/116 pass locally
For the gate itself, this PR exercises both new code paths: the body
inlines a feature-template-shaped description with ≥3 matched fields,
and the dedup-search checkbox below is checked.
## Risks
Low risk. The change is contributor-CI plumbing — no runtime or
migration impact. The widened linked-issue gate is strictly more
permissive (it can only flip prior FAILs to PASS), and the new
dedup-search gate honors the existing `[skip-quality-gates]` prefix, so
an author can always bypass it the same way as the other gates if
needed.
## Model Used
Claude Opus 4.7 (`claude-opus-4-7`), extended-thinking enabled, tool use
for filesystem + shell.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [ ] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge
Co-authored-by: Paperclip <noreply@paperclip.ing>
|
||
|
Devin Foley
|
c369d3d357 |
fix: exempt Dependabot PRs from manual-lockfile block and quality gates (#7457)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies, including how we ship the public `paperclip` repo itself > - The `PR` and `commitperclip PR Review` workflows are the CI gating layer that decides whether any pull request — human or bot — can be merged to `master` > - Dependabot opens dependency PRs that always carry a `pnpm-lock.yaml` diff and an auto-generated PR body, but our `policy` job hard-fails any non-`chore/refresh-lockfile` lockfile change, and our `commitperclip` quality gate requires a Thinking-Path / What-Changed / Verification / Risks / Model template Dependabot can't produce > - Because `policy` fails first, every downstream lane (`Build`, `Typecheck + Release Registry`, `General tests`, `Verify serialized server`, `Canary Dry Run`, `e2e`, and the required `verify` check) skips and `verify` fails — so we never see whether the upgrade is actually safe > - Socket.dev (PR Alerts + Project Report) and Snyk already run on every dependency PR and are the supply-chain compensating control against malicious upgrades; the missing piece is just letting our own build/test signal run so a human can merge with confidence > - This pull request adds a narrow Dependabot bypass to the two gates that block on lockfile diffs and PR-template prose, while leaving every other policy and security check active > - The benefit is that Dependabot PRs like #7331 will now run the full PR matrix, giving reviewers real evidence to approve or reject — without weakening any check that targets supply-chain or build-correctness risk ## What Changed - `.github/workflows/pr.yml` — extended the existing `chore/refresh-lockfile` bypass on the `policy` job's "Block manual lockfile edits" step to also skip when `github.actor == 'dependabot[bot]'`. Every other policy step (Dockerfile deps stage validation, `no-git-push` enforcement, release-package map check, release bootstrap, manifest-driven `pnpm install --lockfile-only` resolution) keeps running on Dependabot PRs. - `.github/workflows/commitperclip-review.yml` — gated the `Run quality gates` step and the dependent `Fail if quality gates failed` step on `github.event.pull_request.user.login != 'dependabot[bot]'`. `Run security gates` (`check-pr-security.mjs`) stays unconditional so supply-chain visibility into Dependabot lockfile churn is preserved. No changes to `.github/scripts/*.mjs` — keeping the bypass at the workflow level avoids churning unit-tested code. ## Verification - CI on this PR: `policy` should pass and the downstream lanes (`Build`, `Typecheck + Release Registry`, `General tests`, `Verify serialized server`, `Canary Dry Run`, `e2e`, `verify`) should all run normally (this PR isn't from Dependabot, so the bypass condition is false — proves we didn't accidentally widen the exemption). - After merge, ask Dependabot to rebase #7331 (`@dependabot rebase`) and confirm: - `PR / policy` → `success` (lockfile step now `skipped`, other policy steps `success`) - `PR / Build`, `PR / Typecheck + Release Registry`, `PR / General tests (server|workspaces-a|workspaces-b)`, `PR / Verify serialized server (1/4..4/4)`, `PR / Canary Dry Run`, `PR / e2e` → all execute (none `skipped`) - `PR / verify` → `success` once the matrix passes - `commitperclip PR Review / review` → `success` (quality-gates steps `skipped` for Dependabot; security gates ran) - Socket and Snyk checks unchanged - Local sanity-check: `git diff origin/master..HEAD` shows only the two workflow files, 7 added / 2 removed lines. ## Risks - **Auto-merging a poisoned dep.** Mitigated by Socket.dev + Snyk + human merge approval. This change only affects CI gating, not who clicks "Merge". - **Spoofing `github.actor` as `dependabot[bot]`.** GitHub sets `github.actor` from the push actor; spoofing requires a compromised Dependabot install token, which is the same threat model that already lets an attacker push anything to a Dependabot-controlled branch — not a new risk surface. - **Policy "Validate dependency resolution when manifests change" step running `pnpm install --lockfile-only --no-frozen-lockfile` on a Dependabot lockfile.** That step intentionally uses `--lockfile-only`, so it only verifies the manifest resolves and does not push or commit the result. Existing behavior is unchanged. - Low overall: the diff is two workflow-level `if:` conditions in steps that already had bypasses. ## Model Used - Provider: Anthropic Claude (via Claude Code in the Paperclip executor) - Model ID: claude-opus-4-7 - Context window: 200K - Reasoning mode: standard tool-use; no extended thinking required for this change - Capabilities used: file edit, bash, GraphQL/REST API calls - Plan was drafted, approved by board, and split into child issues before implementation; see [PAPA-490](https://paperclip.ing/PAPA/issues/PAPA-490) for the planning thread. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass (this change is workflow-only — no code under test; lint via `yamllint` clean) - [x] I have added or updated tests where applicable (workflow gating; no script changes, no unit-testable surface) - [x] If this change affects the UI, I have included before/after screenshots (no UI changes) - [x] I have updated relevant documentation to reflect my changes (no docs reference these gates) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge |
||
|
Devin Foley
|
03e1e3abd2 |
Revert "Remove linked-issue gate from commitperclip" (#7426)
Reverts paperclipai/paperclip#7423 Decided to keep this in place so we can automate issue reproduction in the future. We all make mistakes. Even me, if you can believe it. |
||
|
Devin Foley
|
68401f82f3 |
Remove linked-issue gate from commitperclip (#7423)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - The `commitperclip` PR quality gates enforce hygiene on every PR before merge > - One of those gates required PRs to link to a tracking issue, which adds friction for small/internal changes that don't need a tracker entry > - The repository owner decided the linked-issue requirement is no longer the right default > - This pull request removes the linked-issue gate (the script, its tests, and the orchestrator wiring) > - The benefit is fewer false-failing PR checks and one less mandatory authoring step ## What Changed - Deleted `.github/scripts/check-pr-linked-issue.mjs` - Deleted `.github/scripts/tests/check-pr-linked-issue.test.mjs` - Removed the `checkLinkedIssue` import, the `Promise.resolve(checkLinkedIssue(...))` entry in the `Promise.all` block, the `issueResult` destructured binding, and the `...issueResult.failures` spread from `.github/scripts/run-quality-gates.mjs` ## Verification - `node --test .github/scripts/tests/*.test.mjs` — 72/72 tests pass across the remaining 4 gate suites - `git grep -n 'check-pr-linked-issue\|checkLinkedIssue\|check-pr-linked'` — no matches - Inspected `run-quality-gates.mjs` — no orphaned `issueResult` references ## Risks - Low risk. Pure removal of one optional gate; the `.github/workflows/commitperclip-review.yml` workflow only invokes the orchestrator and needs no changes. PR template and `CONTRIBUTING.md` do not mention linked issues, so no docs change is required. ## Model Used - Claude (Anthropic), `claude-opus-4-7`, extended-thinking mode, tool use enabled ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable (existing gate-suite tests still pass; removed gate's tests deleted with it) - [x] If this change affects the UI, I have included before/after screenshots (n/a — CI script change) - [x] I have updated relevant documentation to reflect my changes (no docs reference the removed gate) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
brandonburr
|
96feaa331a |
feat(commitperclip): add automated PR quality and security gates (#6469)
Fixes #6470 ## Thinking Path > - Paperclip is an open-source AI agent platform receiving a high volume of community PRs — currently 2,398 open > - The contributor experience is broken: PRs sit for months with no feedback, contributors don't know why they're stuck, and maintainers spend review time on PRs that are missing basics > - Common problems: no linked issue, no test coverage, incomplete PR template, manually-edited lockfile — all catchable before human review > - At the same time, accepting untrusted PRs from unknown contributors is a real attack surface: malicious packages, secret injection, tampering with CI scripts, and code touching the sensitive paths from the April security advisories > - This PR adds automated gates that run on every PR: quality failures get a clear comment telling contributors exactly what to fix, security concerns are silently flagged as draft advisories and block merge via a pending check run > - The benefit is a dramatically faster feedback loop for good-faith contributors and a meaningful security layer for the maintainers reviewing them ## What Changed - **`.github/workflows/commitperclip-review.yml`** — new workflow using `pull_request_target` (runs in base branch context, has secrets, never executes PR code). Runs quality gates + security gates on every PR open/update. - **`.github/dependabot.yml`** — weekly automated dependency vulnerability PRs for npm and GitHub Actions. - **`.github/scripts/get-bot-token.mjs`** — generates a short-lived commitperclip installation token from `COMMITPERCLIP_KEY` secret. - **`.github/scripts/run-quality-gates.mjs`** — orchestrates 5 quality gates, posts/updates a single consolidated comment on the PR. - **`.github/scripts/check-pr-template.mjs`** — validates all 5 required template sections, Thinking Path depth (≥3 sentences), Model Used not placeholder. - **`.github/scripts/check-pr-linked-issue.mjs`** — requires `Fixes #NNN` or issue URL in PR body. - **`.github/scripts/check-pr-test-coverage.mjs`** — requires at least one test file in the diff. - **`.github/scripts/check-pr-lockfile.mjs`** — blocks manual `pnpm-lock.yaml` edits (only the refresh bot may change it). - **`.github/scripts/check-pr-dependencies.mjs`** — informational comment when new npm packages are added. - **`.github/scripts/check-pr-security.mjs`** — 6 silent security checks: secret patterns, CI workflow tampering, build script changes, supply chain (new packages in lockfile), suspicious test patterns (outbound network/shell exec/env var reads), and changes to the 9 sensitive path prefixes from the April advisories. When any fire: creates a draft security advisory + sets `security-review` check to `in_progress` (blocks merge). When clean: sets `security-review` to `success`. - **`actions/dependency-review-action@v4`** — per-PR dependency vulnerability check (fails if new dep has known CVE). - **44 unit tests** across all gate modules (`node:test`, no external deps). ## Verification Run all unit tests locally: ```bash node --test .github/scripts/tests/*.test.mjs ``` Expected: 44 pass, 0 fail. End-to-end: open a PR missing the template, linked issue, and test files → commitperclip posts a consolidated comment listing all failures. Open a PR with all gates satisfied → `✅ All checks passing` comment posted, all check runs green. ## Risks **`pull_request_target` security model:** This workflow runs in base branch context and has access to secrets. It explicitly checks out `ref: master` (never PR code) and reads the PR diff via GitHub API only — no PR code is ever executed. This is the correct pattern for running secret-bearing checks on fork PRs; deviating from it (e.g. checking out the PR branch) would be a security vulnerability. **False positives on security gates:** The sensitive-path gate flags any PR touching the 9 path prefixes from the April advisories. Legitimate fixes to those paths will trigger draft advisories. This is intentional — those paths warrant a human look regardless. The `security-review` check can be manually resolved by a maintainer once reviewed. **commitperclip not yet installed:** Until the app is installed on this repo and the `COMMITPERCLIP_KEY` secret is added, the workflow will fail on the token generation step. The quality gate comment won't post, but Dependency Review will still run independently. ## Model Used Claude Sonnet 4.5, 200k context window, extended thinking enabled, tool use: read/edit files, bash execution, GitHub API calls ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass (44/44) - [x] I have added or updated tests where applicable (44 unit tests across all gate modules) - [ ] If this change affects the UI, I have included before/after screenshots (N/A — CI only) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --- ## One-time setup needed from you, Dotta 1. **Install commitperclip app** on this repo: https://github.com/apps/commitperclip/installations/new 2. **Add `COMMITPERCLIP_KEY`** as a repository secret (Actions → Secrets) — ask @brandonburr for the key 3. **Add `security_advisories: write` and `checks: write`** to the commitperclip app permissions (commit-capital org → Settings → Apps → commitperclip → Permissions) 4. **Install Socket.dev** from GitHub Marketplace for supply chain scanning 5. **Branch protection** (optional but recommended): require `commitperclip-review` and `security-review` checks to pass before merge ## Dashboard integration note The `commitperclip-review` check run result maps cleanly to your PR triage dashboard. A single filter on your Worker: ```javascript const gatesCheck = checkRuns.find(r => r.name === 'commitperclip-review'); if (gatesCheck?.conclusion === 'failure') return null; // filter from queue ``` For security flags: `GET /repos/paperclipai/paperclip/security-advisories?state=draft` — advisory titles include `PR #NNN` for cross-referencing. PRs with a matching draft advisory have `security-review` in `in_progress` state (grey spinner, can't merge via branch protection). --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Devin Foley <devin@devinfoley.com> Co-authored-by: Paperclip <noreply@paperclip.ing> |