DottaandPaperclip
13e5128164
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its control plane shares execution capacity across requests and agent orchestration. > - A dependency can return a small value while doing slow or repeated work underneath. > - Tests can check that value while mocks hide the behavior that affects other work. > - A later passing retry can also leave an earlier material failure unexplained. > - This pull request records general rules for dependency work, verification, and acceptance. > - The benefit is a durable review habit that applies beyond the runner incident. ## Linked Issues or Issue Description Refs #15683. Refs #16335. The staging runner incident exposed a gap in how we establish the operational cost of a dependency call. The original platform check read a small field from a process report. The call could block shared execution, and value-focused mocks did not exercise that behavior. The fix replaced that probe with bounded asynchronous work. This proposal addresses the reasoning and evidence gap, without assigning blame or prescribing one API or timeout for future work. The acceptance guidance also preserves material failures after a retry passes. It does not assert that every earlier test failure had the same cause as this incident. Related proposal checked: #14275 covers release sign-off templates. This PR covers implementation assumptions and verification evidence. ## What Changed - Add a scoped rule for dependency work in server, adapter, and runner execution paths. Cover blocking, repetition, cost growth, cancellation, and the effect on unrelated work. - Require evidence that can disprove the consequential assumption introduced by a change. Identify behavior removed by mocks and exercise the relevant boundary. - Register the rule in the Greptile manifest with matching path scope. Existing `AGENTS.md` instructions route coding agents to matching rules. - Add failure preservation to the verification skill. Link it from the repository-wide PR review rule. Keep recovery and resolution distinct. - Include examples and exceptions so cosmetic edits and ordinary pure transformations do not acquire unnecessary test requirements. ## Verification - Passed `git diff --check` and the repository PR template and duplicate-search validators. - Passed a local Python structural check: manifest JSON parses; rule globs and Greptile scopes match; seven representative runtime paths match; five unrelated paths do not; the evidence link and heading resolve; existing agent and reviewer loading instructions are present. - Manually applied the rule to a network-filesystem configuration getter, a repeated remote permission check, and an already-loaded map lookup. The first two need evidence about their new dependency risk. The last does not require fault testing by default. - Attempted `pnpm -r typecheck`, `pnpm test:run`, and `pnpm build`. The installed pnpm launcher could not fetch registry data to verify the requested pnpm version. Using the cached project version reached typecheck, which failed because workspace dependencies are absent (`@types/node` missing). Tests and build remain unverified locally. - Greptile reviewed commit `e56d1ec70f3ebffe697b35cc637975b8d8198681` at 5/5 with no unresolved review threads. CI is still running. These structural checks establish instruction wiring, not future compliance by an agent or reviewer. ## Risks - The main risk is adding ceremony to low-risk edits. The rule limits requests to concrete risks introduced by changed behavior and explicitly exempts unrelated work. - Instructions depend on contributors and reviewers reading and applying them. This change adds no automated runtime regression gate. - No application behavior, schema, dependency, lockfile, or workflow changes. ## Model Used OpenAI Codex, GPT-6 family. The exact serving model ID, context window, and configured reasoning effort are not exposed in this session. Used reasoning, repository inspection, shell tools, and patch editing. ## 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 available in this session) - [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 (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [ ] I have run tests locally and they pass - [x] I have added or updated tests where applicable (guidance-only change; structural validation described above) - [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 - [x] 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>
Greptile configuration
This directory tracks the supported review configuration for
paperclipai/paperclip. It was prepared from a read-only dashboard inventory
on 2026-10-13. No dashboard settings or custom context were changed.
config.jsonrecords the observed review settings supported by Greptile's documented file schema.files.jsonloads repository context and scopes architectural rule files.rules.mdexplains how to apply the canonical Markdown rules inrules/.
Settings migrated to Git
| Dashboard setting | Repository configuration |
|---|---|
| Automatic reviews on all events | autoReview: ["open", "push", "rebase"] |
Exclude dependabot[bot]; remaining reviews use Base |
excludeAuthors, effort: "base" |
| High strictness (dashboard says it does not comment on P2s) | strictness: 3 |
| Do not replace the PR description | shouldUpdateDescription: false |
| Include PR summary, confidence score, and findings; no sequence diagram | The four section settings in config.json |
| Summary is not collapsible; default-open option is off | summarySection.collapsible and defaultOpen are false |
| Include a prompt to fix findings | fixWithAI: true |
| Status checks and status comments enabled | statusCheck and statusCommentsEnabled are true |
| Auto-approval disabled; stored risk ceiling is Low | autoApprove.enabled: false, riskCeiling: "low" |
The existing PR-description and 1,000-line growth guidance is in
rules/pull-request-review.mdc. That file also preserves the active,
repository-specific rule not to request UI screenshots. This resolves the
contradiction with the older organization instruction asking for screenshots.
The active dashboard pattern **/[Aa][Gg][Ee][Nn][Tt][Ss].md reported two files:
AGENTS.md and docs/api/agents.md. Both are explicit references in
files.json; the latter remains API context, not contributor policy. Future
context files need explicit manifest entries. The inactive Contribution
guidelines context remains inactive; it is not added as a separate context
file. Rules scoped to other repositories are not copied here.
Settings still managed in Greptile
The following observed controls do not have equivalents in the published
.greptile/ schema used for this migration. They remain dashboard settings:
- Review draft pull requests: enabled.
- Required confidence to pass the status check: 5/5.
- Image badges: enabled.
- Comment header: empty.
- Default coding-agent badges: no agents shown.
Repository enablement, provider authentication, billing, integrations, and learned memory also remain service settings. Auto-approval risk instructions, if used later, are explicitly dashboard-only in Greptile's reference. Do not invent config keys for unsupported controls.
Cutover and maintenance
Greptile reads committed configuration from the reviewed branch. No reindex is required. Local changes alone are not visible to the hosted reviewer.
File-based review settings override dashboard defaults, but dashboard rules and instructions are additive. The existing dashboard copies are still active. This is a staged migration, not a completed dashboard cleanup. After a hosted review verifies the configuration, an authorized maintainer can retire duplicate dashboard context scoped to this repository. Do not remove shared organization instructions while other repositories still depend on them.
Keep each policy's body in rules/; update the files.json scope together with
the rule's MDC frontmatter. The chat-channel rule includes both the directory
and its sibling service entry point. See rules/README.md for authoring steps.
References: configuration and precedence, supported fields and file references.