DottaandPaperclip
9cb3e157b3
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The runtime and server handle routine execution and recovery. > - Product flows can expose internal steps that the system can handle safely. > - Users then have to operate infrastructure to achieve their original goal. > - This pull request adds a short rule that assigns this work to the harness. > - The benefit is a calm product experience with useful details and real choices. ## Linked Issues or Issue Description **Issue type** Missing documentation. **Where is the issue?** `rules/` and the repository review configuration. **What's wrong?** The repository has no shared product rule for harness responsibility and useful user-facing detail. Recovery can become a user checklist even when the system knows the next safe step. Related implementation: #15824. **Suggested fix** Require the harness to perform routine work within its existing authority. Require visible controls and details to serve a real decision or useful outcome. Keep progress truthful and apply the rule to changed flows. ## What Changed - Add the short product rule in `rules/product-harness-responsibility.mdc`. - Register it as a repository-wide review rule in `.greptile/files.json`. - Link the rule from `rules/README.md`. ## Verification - `git diff --check origin/master...HEAD` passed. - Node assertions passed for rule frontmatter, unique reviewer registration, repository-wide scope, all registered file paths and the README link. - The diff contains only three rule/documentation files. No application behavior changes. Application typecheck, tests and build were not run for this documentation change. - Review the rule's scope and read its four product requirements and review criterion. All applicable CI checks passed on head `89803a6cd7`. Greptile gave 5/5 with no unresolved findings. ## Risks The rule affects future product design and review. It applies to changed flows and does not require unrelated redesigns. Existing permissions, approvals and runtime safeguards remain in force. No migration or deployment is required. ## Model Used OpenAI Codex, GPT-6, with repository inspection, tool use and code execution. The exact serving model ID and context-window size were not exposed in this session. The user edited and approved the final short rule. ## 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 (e.g. `docs/...`, `fix/...`) 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] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] 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>
1.9 KiB
Repository rules
Keep architectural guidance in focused .mdc files here. Each file is Markdown
with YAML frontmatter containing a description and an alwaysApply boolean.
For scoped rules, set alwaysApply: false and provide comma-separated,
repository-relative globs. For repository-wide rules, set alwaysApply: true
and omit globs. Use ** for all descendants of a directory. Include sibling
entry points explicitly when needed.
Root AGENTS.md tells coding agents to read matching rules before editing or
reviewing code. This directory is a repository convention: Cursor does not
automatically load it as .cursor/rules/, and the .mdc extension alone does not
make a tool apply a rule.
Greptile reads matching rule files through .greptile/files.json and receives
loading instructions from .greptile/rules.md. The rule body remains here as
the single source of truth. Repository configuration takes effect when the
files are available on the reviewed branch; local files alone are not visible
to the hosted reviewer.
When adding or changing a rule:
- State the scope, required behavior, examples, exceptions, and review criteria.
- Add its path to
.greptile/files.json. Copy itsglobsinto that entry'sscopearray, one pattern per element. ForalwaysApply: true, omitscope. - Keep the rule's frontmatter and the Greptile scope synchronized. Verify that the scope covers representative files and excludes unrelated directories.
- Keep detailed policy in the rule file instead of copying it into tool settings.
Product behavior is covered by
product-harness-responsibility.mdc: routine
work belongs to the harness, and user-facing detail must support an outcome or a
real decision. This applies to orchestration as well as UI.
See the Greptile file-reference documentation for the manifest format.