mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-23 09:07:46 +02:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its feature map describes user journeys and their verification paths. > - The map already defines feature IDs and full capability IDs. > - The README and child pages did not show those IDs consistently. > - Readers need those IDs to connect issues, tests, stories, and evidence. > - This pull request adds a recipe index and displays the existing IDs. > - The benefit is clear references across the product and agent access maps. ## Linked Issues or Issue Description **Issue type** Missing documentation. **Where is the issue?** `maps/feature-map/README.md`, the child recipes, and their agent access companions. **What's wrong?** The README sends readers to Storybook to browse features. Child pages show local keys, such as `installation`, without the full `plugins/installation` ID. Readers must inspect the generator to find the full reference. **Suggested fix** List recipe links and existing IDs in the README. Show each feature ID and full capability ID in its child pages. Explain capability IDs and entry-point references. Keep the current keys and anchors. Related work: Refs #15288. Refs #16052. Refs #15983. No duplicate open PR or issue was found by title search. ## What Changed - Add an index grouped by feature area. It lists every recipe, feature ID, and full capability ID. - Explain how IDs are formed and used in issues, tests, Storybook, and evidence. - Add feature IDs to all product recipes and agent access companions. - Show full capability IDs beside recipe keys and below access and Storybook guidance headings. - Preserve existing keys, heading anchors, and generated ID values. Keep the latest upstream company capability in the index. ## Verification - `node scripts/check-maps.mjs` passes for 34 feature families and 175 capability IDs. - `node --test scripts/check-maps.test.mjs scripts/storybook-feature-index.test.mjs` passes all 17 tests. - `node scripts/storybook-feature-index.mjs` passes on this checkout and generates the feature indexes and overview inputs. - `git diff --check` passes. - A source comparison confirms that the README matches the recipe index. After removal of the added ID labels, all 68 child pages match the upstream prose and headings. - Full workspace checks were attempted: `pnpm -r typecheck`, `pnpm test:run`, and `pnpm build`. They could not start because the local pnpm wrapper could not fetch and verify the pinned pnpm 9.15.4 release. This checkout also has no workspace dependencies installed. - `node scripts/storybook-catalog.mjs` could not run because `storybook/internal/csf-tools` is not installed. The direct map and index checks above pass without that dependency. - Remote typecheck, release-registry, and full build checks passed. The first attempts of [server shard 3/12](https://github.com/paperclipai/paperclip/actions/runs/39460473910/job/118758430448) and [server shard 12/12](https://github.com/paperclipai/paperclip/actions/runs/39460473910/job/118758429932) stopped after their runners received a shutdown signal. The test steps were canceled. GitHub rejects the rerun request with HTTP 403: "The workflow run containing this job is already running". Five other CI jobs remain active. The next action is to rerun the two interrupted shards after workflow 39460473910 ends. No application changes were made to address these runner interruptions. - To inspect the result, open the feature-map README, follow a recipe link, and compare its full capability IDs with its access companion. ## Risks - Low risk. The change updates map documentation only. It changes no application code or ID schema. - The readable README index and child labels repeat source IDs. Keep them aligned when a capability changes. - Generated capability descriptions now include the visible ID prefix. Generated IDs, labels, navigation order, and verification fields remain the same. - Full local workspace checks and catalog generation remain unverified for the environment reasons above. > 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, model `gpt-6.1-sol`, with a 475,000-token context window and `xhigh` reasoning effort. The model used local file tools, shell commands, and GitHub CLI access. ## 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: Paperclip <noreply@paperclip.ing>
168 lines
11 KiB
Markdown
168 lines
11 KiB
Markdown
---
|
||
navigation: {"section":"Agents and reusable capabilities","sectionOrder":30,"order":20}
|
||
---
|
||
|
||
# Runs, harnesses, and model accounts
|
||
|
||
Operators choose an agent harness and model account, inspect execution history and transcripts, and distinguish a working configuration from a successful task result.
|
||
|
||
Feature ID: `runs-adapters`.
|
||
|
||
Implementation: [adapter manager](../../ui/src/pages/AdapterManager.tsx), [run host](../../ui/src/pages/AgentDetail.tsx), [configuration](../../ui/src/components/AgentConfigForm.tsx).
|
||
|
||
Agent access: [companion](../agent-access-map/runs-adapters.md).
|
||
|
||
## Sub-features
|
||
|
||
- `availability`: `runs-adapters/availability` — discover installed adapters and available models/accounts.
|
||
- `validation`: `runs-adapters/validation` — test an adapter in the selected execution environment and surface authentication failures.
|
||
- `runs`: `runs-adapters/runs` — inspect run status, events, output, costs, and the source task.
|
||
- `session`: `runs-adapters/session` — preserve or reset execution context through supported lifecycle actions.
|
||
|
||
## How to get to it (user POV)
|
||
|
||
### `adapter-setup`
|
||
|
||
Open an agent’s model/adapter configuration or the instance adapter settings page when permitted.
|
||
|
||
### `run-history`
|
||
|
||
Open an agent run at `/agents/:agentId/runs/:runId` from the agent or task activity.
|
||
|
||
For latency diagnosis with an operator OTLP endpoint, search the hashed run ID
|
||
without restricting the root span name. Compare workspace preparation with its
|
||
`workspace_<step>` intervals. Measure controller readiness separately through
|
||
`controller.startup.<phase>`. A recovery pause or deployment drain is not model
|
||
execution time. See the [tracing contract](../../doc/observability.md#controller-preparation-phases).
|
||
These source-level diagnostics do not establish a live response-time budget.
|
||
Inspect `native.controller.<phase>` for backend construction, assigned-tool
|
||
discovery and post-turn cleanup. Compare those intervals with the actual model
|
||
turn; do not count a nested discovery interval twice.
|
||
|
||
## Driving it with Playwright and the Paperclip CLI
|
||
|
||
Preconditions: follow the [baseline](./README.md#before-driving-a-journey). Record adapter, model, account, native/legacy runtime, and environment. Capabilities vary; one harness result is not a matrix-wide qualification.
|
||
|
||
### `adapter-setup`
|
||
|
||
Automated: [adapter validation routes](../../server/src/__tests__/agent-adapter-validation-routes.test.ts) and [model refresh](../../server/src/__tests__/adapter-model-refresh-routes.test.ts) cover server behavior.
|
||
|
||
Claude native setup uses the existing Anthropic API-key or subscription connection
|
||
flow. Record the selected account separately from successful execution; unavailable
|
||
models/authentication and unsupported Legacy-only options must fail visibly.
|
||
|
||
Manual: Select the intended adapter and account, refresh model choices, and run its environment test. Save, reload, then execute a small task. Repeat with a deliberately unavailable account and verify the failure remains visible.
|
||
|
||
Choose Codex as the harness; the UI displays its name/icon for both runners.
|
||
Advanced identifies the automatic default and offers Paperclip Runner or Legacy.
|
||
New Codex agents default to the native runner on supported macOS or GNU/Linux
|
||
targets; the [shared selection contract](../../packages/shared/src/agent-runner.ts)
|
||
and [runtime prerequisites](../../packages/paperclip-runner/README.md) define the
|
||
platform/libc boundary. Windows and Alpine/musl remain Legacy. Claude follows
|
||
its qualified rollout described above. Disabled adapters, external overrides, and selected-target
|
||
qualification also affect availability.
|
||
On a fresh forced-Kubernetes instance without an environment row, inspect discovery
|
||
and create with automatic selection. Both must retain Legacy without provisioning;
|
||
an explicit Paperclip request must give target-qualification guidance. Begin the
|
||
ordinary task to exercise the existing lazy environment path. This live journey
|
||
remains separate from the resolver's source controls.
|
||
|
||
For sandbox defaults, follow the [environment probe](./execution-environments.md#environment-settings)
|
||
recipe first. Discovery/creation read company-bound immutable-image evidence
|
||
without allocating a target. A mutable image or snapshot name does not establish
|
||
native compatibility. Then test the actual selected runtime with its selected
|
||
account/model: a legacy CLI or authentication probe alone cannot establish native
|
||
readiness. For an image-provided Codex harness, verify both final executables
|
||
after concurrent artifact preparation on an eligible provider. Repeat with a
|
||
failed runner probe and confirm the harness work has settled before failure
|
||
returns. Providers without concurrent sync and explicit harness installs remain
|
||
serial. The [real-shell artifact controls](../../server/src/services/native-runtime/native-artifact-preparation.test.ts)
|
||
cover these source contracts; they do not establish live reply latency.
|
||
For remote native Codex with managed GitHub access, inspect the controller
|
||
preparation spans for overlapping GitHub setup and assigned MCP discovery.
|
||
Provider startup must wait for both. Force either preparation to fail while the
|
||
other is pending; confirm that the pending operation settles and run-owned access
|
||
is released before failure returns. Repeat a warm follow-up and retain its actual
|
||
reply time. The [executor controls](../../server/src/services/native-runtime/native-session-executor.test.ts)
|
||
cover ordering, failure drain and credential projection; they do not qualify a
|
||
live response-time target.
|
||
Missing dependencies, failed authentication, invalid models and
|
||
incompatible custom settings must remain actionable errors without silent runner
|
||
switching. Saved unchanged execution can still be tested without applying new
|
||
selection policy, but runtime/account validation must still run.
|
||
|
||
Verify an automatic Codex hire and an explicit Legacy control through a useful
|
||
file artifact, follow-up and reload. Preserve Codex reasoning effort and account
|
||
isolation; retain explicit Legacy permission choices, including false. Reopen an
|
||
existing agent, make an unrelated edit, and confirm both its persisted runner and
|
||
next run stay unchanged. Use [hiring/import preservation](./agents.md#hire-agent)
|
||
for approval and portability controls.
|
||
|
||
Test native Codex with a saved subscription whose setup auth file is a managed
|
||
link, as well as a regular file and an API-key account. Setup must seed the
|
||
isolated probe from the checked account without exposing credentials or changing
|
||
its saved runner. With subscription authentication, an unbound configured
|
||
`CODEX_HOME` with linked credentials must fail setup with managed-account or explicit Legacy guidance; it must not claim
|
||
readiness when task isolation would omit the file. Dangling or incorrectly owned
|
||
credentials must also fail clearly. A selected `CODEX_API_KEY` or
|
||
`OPENAI_API_KEY` takes precedence over an unrelated subscription file. Test valid,
|
||
dangling and invalid subscription links with that selected key; setup must test
|
||
the key without reading or refreshing the unrelated account. The private probe copy must be removed after confirmed retirement following success,
|
||
failure or cancellation. Unconfirmed shutdown remains a cleanup failure.
|
||
Exercise an unavailable local daemon and a preparation failure before probe
|
||
handoff. No owned temporary credential copy may remain, and original account
|
||
files must be unchanged. A probe whose shutdown is unconfirmed must retain its
|
||
recovery state; do not treat it as a preparation-only failure.
|
||
Existing setup controls use fake credentials; real account execution remains
|
||
a separate acceptance requirement.
|
||
|
||
### `run-history`
|
||
|
||
Automated: [live run routes](../../server/src/__tests__/agent-live-run-routes.test.ts) and [run event sequencing](../../server/src/__tests__/heartbeat-run-event-sequencing.test.ts) cover run data contracts.
|
||
|
||
Manual: Start a disposable task, open its running transcript, and follow it to a terminal outcome. Reload and compare task/run IDs, status, output, and cost. Verify a failed run remains distinguishable from a completed run with useful output.
|
||
|
||
An explicit runner change starts a configuration revision and invalidates the
|
||
eligible session. Active runs, restart recovery and historical transcript parsing
|
||
retain their recorded execution configuration; do not infer their runner from a
|
||
later edit to the agent. Account/harness branding and execution identity are
|
||
different observations, both required in the evidence.
|
||
|
||
For an onboarding child-completion callback, verify actual session/turn events
|
||
and the source-correlated reply. A `succeeded` row alone is insufficient: the
|
||
literal `ea6c8eb5e16d61111968f633a66748b397b64a3e` managed attempt was marked
|
||
successful during startup without a provider turn. The recovery correction
|
||
preserves the existing validated Done-parent handoff; process-death and ownership
|
||
checks remain active. Its PostgreSQL controls are separate from the required
|
||
revised-source live onboarding and follow-up proof.
|
||
|
||
## Gotchas
|
||
|
||
- Model accounts are managed in Apps and inline agent account controls.
|
||
`/company/settings/connections` configures decision/fast-response models,
|
||
not the general model-account library.
|
||
|
||
- The run log is instance database data; it is not the opt-out first-party Telemetry system or operator-configured OpenTelemetry tracing.
|
||
- Authentication/model discovery does not establish tool, image, steering, or resumption capability parity.
|
||
- Use [recovery](./recovery.md) for interrupted runs and [execution environments](./execution-environments.md) for local/SSH/sandbox differences.
|
||
|
||
Native setup retirement joins owned startup before cleanup can be confirmed.
|
||
[Transport ownership controls](../../packages/paperclip-runner/src/live/runnerd-codex-transport.test.ts)
|
||
hold preparation or registration without launching a provider, then check bounded
|
||
close, rejected duplicate requests, no later launch and retention of unconfirmed
|
||
state. Readiness observes shutdown; resumed startup cannot reactivate ingress
|
||
after close. These are lifecycle controls, separate from installed provider proof.
|
||
The real daemon readiness and recovery controls require their existing native
|
||
fixtures in hosted CI; passing credential-free controls does not qualify them.
|
||
A primary setup timeout remains a failure even when teardown also fails.
|
||
|
||
For remote setup shutdown, verify that each durable-state read respects the
|
||
remaining suspension deadline. A late result cannot establish suspension or
|
||
queue a replacement command after that deadline. An intentional ingress close
|
||
must observe physical socket closure before retiring its connection owner and
|
||
releasing the endpoint; an unresponsive peer must not extend the setup budget.
|
||
The existing transport and ingress suites exercise these conditions without a
|
||
provider. Repeat the actual managed setup and useful task journey separately;
|
||
the literal `651a3de64fc943216cc414b64b1443809f9499da` Test attempt failed
|
||
cleanup before hire and retains its unconfirmed recovery state.
|