mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-25 02:26:12 +02:00
DottaandPaperclip
10d0555189
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Issue interactions give agents and people a structured decision record. > - Resolver routes used different authorization rules. > - Some routes blocked valid agents, including task watchdogs with normal issue access. > - The API did not show who could resolve a pending interaction. > - This pull request gives every interaction kind one resolver policy evaluator. > - The benefit is a clear decision path with consistent governance and company isolation. ## Linked Issues or Issue Description Fixes: #8087 Refs: #7403 Related PR: #11082 proposes board-only confirmation rules. This change keeps human-only review as an explicit policy. **What happened?** Agents could create issue interactions. Some resolver routes still required board access. This left valid agent confirmations pending. Task watchdogs could see the same problem without board identity. **Expected behavior** Every interaction kind must use one resolver policy contract. The contract must support `anyone`, `not_creator`, and `human_only`. It must also apply all normal governance controls. **Steps to reproduce** 1. Create a `request_confirmation` interaction as an agent. 2. Resolve it with another authorized agent. 3. Observe the board-only denial. **Paperclip version or commit** The problem exists on `master` before this change. **Deployment mode** Local development with `pnpm dev`. ## What Changed - Add canonical policies for `anyone`, `not_creator`, and `human_only`. - Use one server evaluator for every interaction kind. - Apply named addressees, company limits, review rules, and task watchdog scope. - Charge cross-issue resolutions to the existing per-run action limit. - Return the effective resolver audience in attention and interaction data. - Show the audience, governance choices, and denial reasons in the board UI. - Add telemetry, API documents, product documents, and regression fixtures. - Add migration provenance for safe legacy behavior. - Make migration `0218` safe for complete replays and partial prior runs. ## Product Rules - An interaction records a response. It does not grant authority for the next action. - `anyone` lets any authorized issue participant respond. - `not_creator` requires a responder other than the interaction creator. - `human_only` requires an authorized person. - A named addressee, company policy, or governed action can narrow the audience. - These controls cannot widen the audience. - A task watchdog uses the same rules as an ordinary agent. - A task watchdog does not receive board authority. - An agent resolution on another issue uses the shared cross-issue action limit. - Legacy pending interactions keep their earlier restrictions. - The UI shows the effective audience and a permanent denial reason. ## Verification - `pnpm --filter @paperclipai/db check:migrations` - `pnpm --filter @paperclipai/db typecheck` - `pnpm exec vitest run packages/db/src/issue-thread-interaction-resolver-policy-migration.test.ts` - The focused PostgreSQL test applies migration `0218` twice. - The test also completes a partial prior run and preserves existing provenance. - The latest GitHub head has 29 successful checks. - The opt-in Storybook visual check skipped as expected. - Greptile reports 5/5 with no open comments. ## Risks - New interaction writes use `anyone` by default. - Callers must select `not_creator` or `human_only` when they need stricter review. - Legacy pending interactions keep the old creator and human restrictions. - Migration `0218` fills only missing provenance fields during recovery. - Cross-issue resolutions can reach the existing action limit. - The shared evaluator affects every interaction kind. - Route, service, database, shared contract, and UI tests cover these rules. > This work matches the Agent Reviews and Approvals direction in `ROADMAP.md`. It does not duplicate a planned item. ## Model Used OpenAI Codex, GPT-5. The runtime does not expose the exact deployment ID or context window. The agent used reasoning, repository tools, shell commands, and test 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 linked public issues or described the issue with the required labels - [x] I have not referenced internal Paperclip issues or links - [x] My branch name describes the change and contains no internal ticket id - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation - [x] I have considered and documented the risks - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open comments - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
51 lines
2.2 KiB
TypeScript
51 lines
2.2 KiB
TypeScript
/**
|
|
* Telemetry retention contract.
|
|
*
|
|
* Defines the retention class for each Paperclip telemetry event and the
|
|
* corresponding retention window in days. This is a housekeeping/cost
|
|
* concern separate from the event schema: it is updated by data-infra
|
|
* and does not require a schema version bump.
|
|
*
|
|
* Retention class definitions
|
|
* ─────────────────────────────────────────────────────────────────────────
|
|
* operational_enum_count
|
|
* Events that carry only enums, booleans, counts, and coarse buckets.
|
|
* No token material (I5-clean) and no PII. Retention is a housekeeping
|
|
* and query-cost concern, not a privacy concern.
|
|
* Window: 90 days.
|
|
*/
|
|
|
|
/** Retention window in days for each telemetry event class. */
|
|
export const RETENTION_DAYS = {
|
|
/**
|
|
* Enum/count/bucket events: no token material, no PII.
|
|
* Retention is a housekeeping and query-cost concern only.
|
|
*/
|
|
operational_enum_count: 90,
|
|
} as const satisfies Record<string, number>;
|
|
|
|
/** Identifies which retention class an event belongs to. */
|
|
export type RetentionClass = keyof typeof RETENTION_DAYS;
|
|
|
|
/**
|
|
* Maps first-party event names to their retention class.
|
|
*
|
|
* Key type is intentionally `string` rather than a tighter union because this
|
|
* contract also covers events emitted by external systems (e.g. the Codex CLI)
|
|
* that are not part of the shared generated `PaperclipEventName` type. When an
|
|
* event is promoted to the first-party schema, prefer tightening its entry to
|
|
* the named union type via an overloaded record.
|
|
*
|
|
* codex.credential_health
|
|
* Emits credential-observability fields: enums (credential source, sync
|
|
* outcome), booleans (rotation detected, refresh succeeded), and coarse
|
|
* counts (rotations detected). No token material and no PII.
|
|
* External-system event (Codex CLI) — not yet in PaperclipEventName.
|
|
* Class: operational_enum_count — 90-day window.
|
|
*/
|
|
export const EVENT_RETENTION_CLASS: Partial<Record<string, RetentionClass>> = {
|
|
"codex.credential_health": "operational_enum_count",
|
|
"interaction.created": "operational_enum_count",
|
|
"interaction.resolved": "operational_enum_count",
|
|
};
|