Commit Graph
7 Commits
Author SHA1 Message Date
DottaandPaperclip 8725d6ce09 fix: make answered Slack conversations idle (#13809)
Settle published, successful Slack turns as Idle; resume the same conversation on an admitted message. Preserve unfinished work, delivery errors, and explicit dispositions.

Verified through focused lifecycle/API/UI tests, full CI, and a real staging Slack conversation in the embedded browser.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-22 10:35:33 -05:00
9b7bd41833 feat(ui): refine dashboard cards, charts, and recent lists (#13269)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Operators use the dashboard and Live runs page to inspect current
and recent runs.
> - Large transcript cards take space and make it hard to compare run
states.
> - A compact card must show the agent, linked task, and time, with
access to run details.
> - This pull request applies the supplied card design to both views.
> - Operators can scan more runs and open a run or task for details.

## Linked Issues or Issue Description

**What existing behavior does this improve?**

The agent run cards on the dashboard and Live runs page, plus dashboard
charts and recent lists.

**Subsystem affected**

`ui/` — React board UI.

**Current behavior**

Both views show large cards with embedded transcripts. Queued and
running cards share a live treatment. The dashboard chart grid leaves an
empty column, recent lists use different row sizes, and some activity
labels expose raw event names.

**Proposed behavior**

Both views use the same compact grid. Each card shows the existing
initials avatar, the agent name, one linked task row, and a
right-aligned timestamp. There is no status chip next to the agent name.
The timestamp uses small Inter text and the same muted gray as dashboard
metric descriptions. Recovery details remain in the task view. Run
status remains in the header tooltip and accessible label, and run
transcripts remain in the run detail view. The shared in-progress task
icon is now an animated circular spinner across the app.

**Reason and benefit**

Operators can scan task states without scrolling through embedded
output. The in-progress spinner keeps the shared task icon sizes,
circular shape, and stroke width. It honors reduced-motion preferences.

**Breaking changes**

The dashboard and Live runs page no longer show transcripts inside
cards. Open the agent header to inspect a run. There are no API or
database changes.

**Additional context**

Related public work found during the duplicate search:

- Refs #4317 — related run-state display concerns. This change does not
change server state reconciliation.
- Refs #11394 — related live-run cache updates. This change retains the
existing data flow.
- Refs #2118 — related navigation from agent cards. The card header here
opens the specific run.

## What Changed

- Apply compact cards to the dashboard and Live runs page, with status
icons and theme tokens.
- Use 16 × 16px status icons in the shared cards, including the
missing-task clock.
- Keep the existing circular initials avatar. Remove the status chip
beside the agent name while preserving the run label for tooltips and
accessibility.
- Replace the shared in-progress task glyph with an animated open
circle. Use the same 10-unit radius and 2-unit stroke as the other task
glyphs, with a reduced-motion guard across all task status surfaces.
This is the requested workflow-status indicator across the app,
including between runs; live indicators separately report active
execution.
- Use the same Tailwind blue tokens as nav dots and Live labels for the
progress icon: blue-400 in dark mode and blue-600 in light mode.
Covered-blocked icons follow the same blue token.
- Match the Tasks by Status chart's In Progress bar and legend to the
spinner's theme-aware color token.
- Distribute the three visible dashboard charts across equal-width
desktop columns, preserving existing gaps, card padding, and page
margins. Retain four columns when the optional priority chart is
enabled.
- Use the done task icon's `--status-task-icon-done` token for green
bars in Run Activity, Tasks by Status, and Success Rate, including their
legends.
- Use the blocked task icon's `--status-task-icon-blocked` token for red
bars and legends in Run Activity, Tasks by Status, Success Rate, and
priority charts.
- Align Recent Tasks live counts to the sidebar's right edge. Reveal the
ellipsis over a fading row surface on hover, keyboard focus, and while
its menu is open, without moving the label or count.
- Keep the ellipsis backdrop synchronized with the row background during
fade-out, using the actual sidebar surface in both themes to prevent a
darker flash.
- On coarse-pointer devices, reserve space for the always-visible
ellipsis and disable its fade so the live count remains readable beside
it.
- Order desktop dashboard Recent Tasks as status icon, task title, agent
avatar/name, 11px monospace task ID, then timestamp. In narrow cards,
keep the ID right-aligned beside the truncated title and place the agent
and timestamp on the second line.
- Give both dashboard lists the same 48px desktop rows, 24px leading
slots, 80px desktop task ID columns, and 64px right-aligned timestamp
columns. Use an 8px icon-to-content gap matching the task detail
heading. Narrow layouts use matching 76px rows with intrinsic-width IDs
on the title line; activity timestamps stay below.
- Order dashboard Recent Activity as actor avatar, actor name, verb,
task title, 11px monospace task ID, then timestamp. Use direct verbs
such as “Board read …” instead of “issue read marked”. Truncate titles
to preserve IDs and timestamps; keep full names and titles in tooltips.
- Use 12px task status icons in the top breadcrumb and Properties status
row. Keep the main task title icon at 20px.
- Reduce monospace task IDs to the 11px micro type token in breadcrumbs
and shared run cards, aligning them to the adjacent task titles' text
baseline while keeping status icons centered.
- Show the task title and identifier in one bordered row. Keep
missing-task links usable and show lookup failures.
- Remove the recovery chip and place the timestamp below the task row.
- Keep the link to all runs available when the dashboard has four or
fewer runs.
- Avoid transcript polling for compact cards.
- Fix bundled Inter font URLs and update the design guide and Storybook
fixtures.
- Cover run navigation, task status, failed lookups, shared icon sizes
and stroke, and reduced-motion-safe animation in tests.

## Verification

- Latest review fixes: targeted SidebarRecentTasks, SidebarNavItem,
StatusGlyph, StatusIcon, ActiveAgentsPanel, activity-format,
ui-font-assets, and Dashboard suites — 65 tests pass, including
read/unread verbs and reduced-motion-safe task animation.
- `pnpm --filter @paperclipai/ui typecheck` — passes.
- `pnpm check:token-gates` — all gates pass.
- `git diff --check` — passes.
- Related component suites passed during development: run cards, status
glyphs, breadcrumbs, issue properties, charts, sidebar navigation,
recent-task actions, and settings sidebar.
- Full repository `pnpm -r typecheck` and `pnpm build` pass on the final
commit using the temporary Rust toolchain. Storybook build passed
earlier in preparation.
- All CI gates pass on `c85e949b12b471d425d216caa609aee41dc58bde`: all
general/workspace and serialized server test shards, all three browser
shards, build/runner verification, typecheck/release registry, canary
dry run, policy, and security checks. The duplicate local `pnpm
test:run` was stopped after CI completed the same test suites; it is not
claimed as a completed local pass. The two Storybook jobs are skipped by
the configured draft-PR workflow.
- Greptile reviewed the final commit at 5/5 with no actionable findings
and zero unresolved review threads.
- Browser measurements at 1654px, 860px, and 390px confirm matching 48px
desktop and 76px narrow rows (plus 1px dividers), right-aligned IDs on
the title line, 64px timestamp slots, and no horizontal overflow. Narrow
Recent Tasks rows retain readable agent names below the title. Activity
reads as actor, verb, title, ID, time. Additional reference details can
expand an activity row.
- Verified three equal-width desktop charts with 16px gaps and aligned
outer edges. Chart blues, greens, and reds resolve to the matching
task-icon tokens.
- Verified real queued, running, succeeded, failed, cancelled, and
timed-out runs in the dev dashboard. Checked compact cards, task/run
links, timestamps, light/dark themes, and narrow layout.
- To inspect: open Dashboard, then Live runs. Both pages use the same
small cards. Open an agent header for run output, or the task row for
task details.
- Verified the updated spinner on the real dashboard cards, Recent
tasks, and task list. Checked actual SVG circle radius, rendered size,
and stroke width. Confirmed the spinner, nav dots, and Live labels
resolve to the identical blue-400 color in the dark-mode preview; light
mode uses their shared blue-600 token.
- Verified 12px computed width and height in the task breadcrumb and
Properties pane, the restored 20px main task icon, and 11px task IDs
with baseline alignment in the breadcrumb and shared dashboard/Live runs
cards.
- Verified the chart bar and legend resolve to the spinner color; Recent
Tasks counts align with Dashboard's count. Checked the fading ellipsis
overlay with keyboard focus and its open-menu state, then dismissed the
menu.

## Risks

- Operators must open run details to read output that was previously
embedded.
- Run outcomes are available in the header tooltip and run details
instead of a visible status chip. An in-progress task icon reflects task
status, independently of an individual run's outcome.
- Long names and task titles truncate within the compact layout. Full
labels remain available through links and tooltips.
- Font loading changes affect all UI text that uses the bundled Inter
font. The files remain served from the existing public fonts directory.
- No schema, API, adapter, or execution-policy changes.

## Model Used

OpenAI Codex, GPT-6 Astra (`gpt-6-astra`), with extended reasoning,
repository tools, code execution, and browser verification. The session
does not expose the context-window size.

## 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: Scott Tong <scott@scotts-mbp-m5-max.local>
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-09-11 17:02:40 -07:00
Nicky LeachandPaperclip 86c2e0ac4a feat(server): log an activity row for each queued-comment queue mutation (#13159)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The server records actions that change issues and their queued
comments
> - The queued-comment edit, reorder, and discard routes changed queue
state without activity rows
> - Operators could not inspect these queue mutations in the activity
feed
> - This pull request adds one identifier-only activity row for each
successful queue mutation
> - The benefit is a durable audit trail with no comment text in the
activity log

## Linked Issues or Issue Description

**What existing behavior does this improve?**

The queued-comment edit, reorder, and discard routes now record their
successful mutations in the activity feed.

**Subsystem affected**

Cross-cutting (server and ui).

**Current behavior**

The three queue mutation routes change queued comments but do not write
an activity row. The activity feed has no label for these actions.

**Proposed behavior**

Each successful route writes one activity row with the actor fields,
entity fields, queue identifiers, and queue revision. The discard row
also includes the cancelled run identifier. The activity feed shows a
label for each action.

**Reason and benefit**

Operators need a durable record of queue changes. Identifier-only
details support audit and troubleshooting without storing comment text.

**Breaking changes**

None. The routes keep their existing response and authorization
behavior.

**Additional context**

Each mutation writes its activity row on the same locked transaction
that applies the mutation, so the two commit or roll back together. The
route publishes the live activity event only after that transaction
commits. The separate comment-cancel route opts out of this write and
keeps its existing single activity row.

## What Changed

- Add activity rows for queued-comment edit, reorder, and discard
mutations.
- Include queue identifiers, revisions, ordered comment identifiers, and
cancelled run identifiers as applicable.
- Add activity-feed labels for the three new actions.
- Add route and activity-format tests for the new behavior.
- Write each activity row on the same transaction as the mutation it
records, through a new port method that the adapter implements.
- Keep the comment-delete route opted out of that write, so a
cancellation does not log two rows.

## Verification

- [x] `npx vitest run
server/src/__tests__/issue-queued-comments-routes.test.ts` passes.
- [x] `npx vitest run ui/src/lib/activity-format.test.ts` passes.
- [x] `pnpm --filter @paperclipai/server typecheck` exits 0.
- [x] `pnpm --filter @paperclipai/ui typecheck` exits 0.
- [x] `node scripts/check-module-boundaries.mjs` passes.
- [x] The full CI suite is green.

## Risks

Low risk. The change adds activity rows after successful mutations and
does not change route responses, authorization, or stored comment text.

## Model Used

OpenAI Codex, GPT-5 Codex. The model used repository inspection, Git
operations, and command execution. The context window and reasoning mode
are not exposed by this runtime.

## 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>
2026-09-10 10:47:17 -07:00
DottaandClaude Opus 5 8ee1fb21a6 feat(ui): badge the review policy when it constrains approval (#10938)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Agents move their work into review, and a reviewer must then give a
verdict on it
> - By default anyone with write access can give that verdict, including
the agent that did the work
> - The server can constrain that default per issue with a
`reviewPolicy` column, but no screen showed the value
> - A reviewer could therefore press Approve on a review that the server
refuses, and get a 403
> - This pull request shows the policy as a badge on the two surfaces
where a person gives a verdict
> - It also makes an agent verdict read as a verdict in the activity
timeline
> - The benefit is that a reviewer sees who can approve before they try

## Linked Issues or Issue Description

No public GitHub issue exists for this change. The description below
follows
`.github/ISSUE_TEMPLATE/enhancement.yml`.

**What existing behavior does this improve?**

The issue review flow. A reviewer cannot see the approval constraint on
an issue
before they give a verdict.

**Subsystem affected**

Web UI (`ui/`), with one supporting change in the server attention
service.

**Current behavior**

The server stores an optional approval constraint for each issue in a
`reviewPolicy` column. The column has three meaningful states: the
default
(`NULL` or `anyone`), `not_creator`, and `human_only`. The server
enforces the
constraint when it receives a verdict.

No screen shows the value. Two problems follow:

1. A reviewer presses Approve on a review that the server refuses. The
server
   answers 403, and the reason is not visible on the card.
2. An agent that accepts or rejects a review renders in the activity
timeline as
the raw action id, for example "issue thread interaction accepted". A
person
   who reads the timeline cannot tell that a verdict was given.

**Proposed behavior**

Show the constraint as a read-only badge on the two surfaces where a
person
gives a verdict. Show no pixels for the default state, because the
default is
what every issue already does. Make an agent verdict read as a verdict
in the
timeline.

Only agents set the column today, so this change adds no control to set
it.

**Reason and benefit**

A reviewer sees the constraint before they act. This prevents the 403,
and it
removes the need to explain the 403 afterwards. The timeline also
becomes
complete, because it now shows agent verdicts and human verdicts in the
same way.

**Breaking changes**

None. The change adds a badge and changes copy. It adds no column, no
endpoint,
and no request.

**Additional context**

The server-side column and the verdict enforcement landed earlier in
#10931.
This pull request is the user interface for that column. The default
state stays
unchanged on screen, so the badge appears on a small number of issues.

## What Changed

- **A read-only "Approvals" row** in the issue Execution properties. The
row
renders *only* for a constrained policy: "Anyone else" (`not_creator`)
or
"Human only" (`human_only`). A `NULL` or `anyone` column adds no row, so
the
  panel is untouched on the overwhelming majority of issues.
- **The same badge on the stalled-review card** in `/decisions`, above
the three
review verbs. A reviewer now sees the constraint before they press
Approve.
  The condition is the same, so the default card is unchanged.
- **Agent verdicts read as verdicts in the activity timeline.** An agent
that
accepted or rejected a review request previously rendered the raw action
id
("issue thread interaction accepted"). It now reads "approved the
request". A
  stalled-review decision names the verb that the actor chose.
- **A cleared policy reports as "anyone", not "none",** in the
field-change
receipt. The `reviewPolicy` column is nullable by default, so an absent
value
  is a real setting rather than a missing one.
- **All copy comes from `ui/src/lib/review-policy.ts`.** Its badge
lookup returns
`null` for the default. This makes "no pixels for the default" one
enforced
decision instead of a condition repeated at each call site. It also
keeps the
  badge, the activity line, and the receipt reading alike.
- **The server attention service carries the policy** on the review
attention
  subject, so the stalled-review card can read it.

## Verification

Automated tests:

- `ui/src/lib/review-policy.test.ts` — the default returns no badge,
however the
column spells it (`null`, `undefined`, `"anyone"`). An unrecognised
policy from
  the wire shows nothing rather than leaking an enum value.
- `ui/src/components/AttentionQueueRow.test.tsx` — no badge on the
default card,
and the verbs still render. Suppression of the badge must not suppress
the card.
- `ui/src/components/IssueProperties.test.tsx` — no Approvals row on the
default.
  The constrained row contains no `button`, so nothing there can PATCH.
- `server/src/__tests__/attention-service.test.ts` — the review
attention subject
carries the policy, and subjects built from narrower selects do not
claim one.

Run them with:

```sh
pnpm vitest run ui/src/lib/review-policy.test.ts \
  ui/src/components/AttentionQueueRow.test.tsx \
  ui/src/components/IssueProperties.test.tsx \
  server/src/__tests__/attention-service.test.ts
```

Manual steps:

1. Open an issue that has no `reviewPolicy`. Confirm that the Execution
   properties panel shows no Approvals row.
2. Set the column to `not_creator`. Reload the issue. Confirm that the
Approvals
   row reads "Anyone else", and that the row has no control.
3. Move that issue into review. Open `/decisions`. Confirm that the
stalled
   review card shows the same badge above the review verbs.
4. Let an agent approve the review. Confirm that the activity timeline
reads
   "approved the request" and not "issue thread interaction accepted".

Screenshots were captured at 1440x900 and 390x844, in light mode and
dark mode,
with the three policy states side by side. The leftmost column in each
capture is
the default. It carries no badge and no extra row.

## Risks

Low risk.

- The change is additive on screen. Every new surface is behind a
constrained
  policy, so the default path renders exactly as before.
- The badge is read-only. It has no control and sends no request, and a
test
  asserts that the row contains no `button`.
- An unknown policy value from the wire renders nothing. It does not
render the
  raw enum.
- No migration, no schema change, and no endpoint change.

## Model Used

Claude Opus 5 (Anthropic), model id `claude-opus-5[1m]`, 1M context
window,
with extended thinking and tool use enabled. Used through Claude Code
for the
implementation, the tests, and this description.

## 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
- [ ] 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: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-14 20:29:36 -04:00
DottaandPaperclip 454edfe81e Add recovery handoff system notices (#5289)
## Thinking Path

> - Paperclip orchestrates AI agents for zero-human companies.
> - Agent runs can end productively while the source issue still lacks a
durable final disposition.
> - That leaves the control plane unsure whether to resume, escalate, or
close the work.
> - Issue comments also need a presentation contract so system-authored
recovery notices can render as first-class thread messages without
overloading normal comments.
> - This pull request adds successful-run handoff recovery, comment
presentation metadata, and system notice rendering.
> - The benefit is stricter task liveness with clearer operator-facing
recovery state.

## What Changed

- Added successful-run handoff decisions, wake payloads, escalation
behavior, and recovery tests.
- Added issue comment presentation metadata with migration
`0078_white_darwin.sql` and shared/server/company portability support.
- Rendered recovery/system notices in issue chat with dedicated UI
components, fixtures, tests, and storybook/lab coverage.
- Included the current recovery model-profile hint patch so automatic
recovery follow-ups use the cheap profile.

## Verification

- `pnpm install --frozen-lockfile`
- `pnpm exec vitest run
server/src/services/recovery/successful-run-handoff.test.ts
ui/src/components/SystemNotice.test.tsx
ui/src/lib/system-notice-comment.test.ts
ui/src/components/IssueChatThreadSystemNotice.test.tsx`

## Risks

- Migration-bearing PR: merge this before any other branch that might
later add a migration.
- The branch touches both recovery services and issue-thread rendering,
so review should pay attention to recovery wake idempotency and comment
metadata compatibility.

## Model Used

- OpenAI GPT-5 Codex via Paperclip `codex_local` adapter, with
shell/git/GitHub CLI tool use.

## 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 run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-05-06 06:05:58 -05:00
DottaandPaperclip 57229d0f24 [codex] Add issue monitor liveness controls (#4988)
## Thinking Path

> - Paperclip is a control plane for autonomous AI companies where work
must stay observable, governable, and recoverable.
> - The task/heartbeat subsystem owns agent execution continuity, issue
state transitions, and visible recovery behavior.
> - Waiting on an external service is not the same as being blocked when
the assignee still owns a future check.
> - The gap was that agents had no first-class one-shot monitor state
for external-service waits, so recovery could look stalled or require ad
hoc comments.
> - This pull request adds bounded issue monitors that can wake the
owner, clear exhausted waits, and produce explicit recovery behavior.
> - It also surfaces monitor status in the board UI and documents when
to use monitors versus `blocked`.
> - The benefit is clearer liveness semantics for asynchronous waits
without weakening single-assignee task ownership.

## What Changed

- Added issue monitor fields, shared types, validators, constants, and
an idempotent `0075` migration for scheduled monitor state.
- Added server-side monitor scheduling, dispatch, recovery bounds,
activity logging, and external-ref redaction.
- Added board/agent route coverage for monitor permissions and child
monitor scheduling.
- Added issue detail/property UI for monitor state, a monitor activity
card, and Storybook stories for review surfaces.
- Documented monitor semantics and recovery policy behavior in
`doc/execution-semantics.md`.
- Addressed Greptile review feedback by preserving monitor state in
skipped-stage builders and making board monitor saves send `scheduledBy:
"board"`.

## Verification

- `pnpm install --frozen-lockfile`
- `pnpm run preflight:workspace-links && pnpm exec vitest run
server/src/__tests__/issue-execution-policy-routes.test.ts
server/src/__tests__/issue-execution-policy.test.ts
server/src/__tests__/issue-monitor-scheduler.test.ts
server/src/__tests__/recovery-classifiers.test.ts
ui/src/components/IssueMonitorActivityCard.test.tsx
ui/src/components/IssueProperties.test.tsx
ui/src/lib/activity-format.test.ts`
- First run passed 5 files and failed to collect 2 server suites because
the worktree was missing the optional `acpx/runtime` dependency.
- After `pnpm install --frozen-lockfile`, reran the 2 failed suites
successfully.
- `pnpm exec vitest run
server/src/__tests__/issue-monitor-scheduler.test.ts
server/src/__tests__/recovery-classifiers.test.ts`
- `pnpm --filter @paperclipai/shared typecheck && pnpm --filter
@paperclipai/db typecheck && pnpm --filter @paperclipai/server typecheck
&& pnpm --filter @paperclipai/ui typecheck`
- `pnpm exec vitest run
server/src/__tests__/issue-execution-policy.test.ts
ui/src/components/IssueProperties.test.tsx`
- `pnpm --filter @paperclipai/server typecheck && pnpm --filter
@paperclipai/ui typecheck`
- `pnpm exec vitest run
ui/src/components/IssueMonitorActivityCard.test.tsx
ui/src/components/IssueProperties.test.tsx`
- `pnpm --filter @paperclipai/ui typecheck`
- Storybook screenshot captured from
`http://127.0.0.1:6006/iframe.html?viewMode=story&id=product-issue-monitor-surfaces--monitor-surfaces`
with Playwright.

## Screenshots

![Issue monitor Storybook
surfaces](https://raw.githubusercontent.com/paperclipai/paperclip/PAP-2945-when-a-task-is-waiting-for-an-_external-service_-what-state-should-it-be-in-and-what-recovery-method-could-it-h/docs/pr-screenshots/pap-2945/monitor-surfaces.png)

## Risks

- Medium: this changes heartbeat recovery behavior for scheduled
external-service waits, so regressions could affect wake timing or
recovery issue creation.
- Migration risk is reduced by using `IF NOT EXISTS` for the new issue
monitor columns and index.
- External monitor references are treated as secret-adjacent and are
intentionally omitted from visible activity/wake payloads.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

- OpenAI Codex, GPT-5 coding agent with repository tool use and terminal
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 run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] If this change affects the UI, I have included before/after
screenshots or Storybook review surfaces
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-05-03 08:58:53 -05:00
dotta 3baebee2df Track blocker and review activity events 2026-04-09 06:16:41 -05:00