mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-15 03:51:22 +02:00
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>
37 lines
1.9 KiB
Markdown
37 lines
1.9 KiB
Markdown
# 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:
|
|
|
|
1. State the scope, required behavior, examples, exceptions, and review criteria.
|
|
2. Add its path to `.greptile/files.json`. Copy its `globs` into that entry's
|
|
`scope` array, one pattern per element. For `alwaysApply: true`, omit `scope`.
|
|
3. Keep the rule's frontmatter and the Greptile scope synchronized. Verify that
|
|
the scope covers representative files and excludes unrelated directories.
|
|
4. Keep detailed policy in the rule file instead of copying it into tool settings.
|
|
|
|
Product behavior is covered by
|
|
[`product-harness-responsibility.mdc`](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](https://www.greptile.com/docs/code-review/greptile-config-reference)
|
|
for the manifest format.
|