Files
PaperClipAI/rules
DottaandClaude b5f62b3384 docs(rules): correct the scope of the API route and company-scope rules (#20596)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - `rules/*.mdc` holds the architecture rules that reviewers and agents
apply to a change
> - Pull request #20585 added two rules: API route expectations and
company-scope exceptions
> - Review found that both rules state more than is true for the current
code
> - A rule that is too broad makes reviewers flag correct code and can
make an agent add a wrong check
> - This pull request corrects the scope of both rules and fixes one
stale pointer
> - The benefit is rules that match the code they describe

## Linked Issues or Issue Description

Refs #20585

**Issue type**

Incorrect contributor documentation.

**Where is the issue?**

`rules/api-route-expectations.mdc`,
`rules/company-scope-exceptions.mdc`, `AGENTS.md` section 8, and
`.agents/skills/honeycomb-tracing/SKILL.md`.

**What's wrong?**

- The API route rule said that every route checks company access.
Instance-level routes such as `health.ts`, `liveness.ts`, `ready.ts`,
`public-mcp.ts` and `org-chart-svg.ts` do not, and must not.
- The API route rule told reviewers to flag each status code outside a
list of seven. `429` and `503` are correct in some routes.
- The company-scope rule said that it lists the only instance-wide data.
`user_sidebar_preferences` is instance-wide and was not in the list.
- The company-scope rule said that it applies to new files that its
`globs` cannot match.
- The `honeycomb-tracing` skill pointed to `AGENTS.md` for the Telemetry
workflow. That text is now in `rules/data-paths.mdc`.

**Suggested fix**

Limit each rule to what is true, and repoint the skill.

## What Changed

- The API route rule and `AGENTS.md` section 8 now apply to routes that
read or write company data.
- The API route rule names the instance-level routes and says not to add
a company check to them.
- The status code list is now a list of common codes. Reviewers flag an
incorrect code, not an unlisted code.
- The company-scope rule lists the sidebar company order as an
instance-wide exception, in the text, the `globs`, and the Greptile
scope.
- The company-scope rule says "known data" and no longer claims to match
new files.
- The `honeycomb-tracing` skill points to `rules/data-paths.mdc`.

## Verification

- Read the two rules and confirm that each named file exists. A local
script checked the `globs` and the route names.
- Confirm that `.greptile/files.json` is valid JSON and that its scope
matches the rule `globs`.
- No source code changed. No test suite ran locally.

## Risks

- Low risk. The change is documentation only.
- The list of instance-level routes can go out of date when a route is
added.

## Model Used

- Claude (Anthropic), in Claude Code with tool use.
- `claude-fable-5-2`.

## 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
- [ ] 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
- [ ] 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

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <noreply@anthropic.com>
2026-11-10 11:19:31 -06:00
..

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 list the rule headers, follow the descriptions that cover their files, and read a rule body when they make a design decision in its area or a reviewer cites it. Write each description as one sentence that states the required behavior, because it is what an agent reads first. 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: 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.

Background execution is covered by sleep-aware-background-work.mdc: new or expanded work must become quiet, use events and real scheduler deadlines, and preserve recovery across transactions, drain, and restart. This rule covers server/src/index.ts and the worker/producer paths in its scope. It does not require unrelated legacy polling to be migrated in the same PR.