mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-25 02:26:12 +02:00
TonioandClaude Fable 5
889f5853f9
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A cloud customer meets it as one walk that crosses two applications: Cloud names the organization, then hands off to the tenant for the agent, the model and the review > - The tenant's progress strip counted only its own three steps, so the count restarted at the crossing — four dots on the naming screen, then three beginning again at one > - The strip that spans the whole walk already existed and simply was not chosen on that path, which made the walk read as two products rather than one > - This pull request picks the four-step strip when the run came from Cloud, so the count runs 1, 2, 3, 4 straight through > - The benefit is that the hand-off stops announcing itself ## Linked Issues or Issue Description **What existing behavior does this improve?** The onboarding progress strip on a cloud tenant. It restarted its count at the hand-off from Cloud, so a customer went from "1 of 4" to "1 of 3" mid-walk. **Subsystem affected** Tenant onboarding wizard — `ui/src/components/OnboardingWizard.tsx`. **Current behavior** `showsAgentArcStepper` is `isAgentArcStep && entryStep >= 3`. Every run entering on the agent step gets the three-step strip, including a cloud tenant whose organization was named one screen earlier in Cloud. **Proposed behavior** A cloud tenant gets the four-step strip, positioned 2, 3 and 4. A self-hosted run entering on the same step keeps three. **Reason and benefit** The count describes the walk the customer is on rather than the half of it this application happens to render. **Breaking changes** None. No API or schema change; the self-hosted path is unchanged. ## What Changed - Adds `enteredFromCloud`, read from `enableManagedSandboxOnly` — the cloud-tenant shape the connect step already resolves its login environment through. - Excludes that case from `showsAgentArcStepper`, so it falls to the existing four-step strip. `ONBOARDING_STEP_LABELS` and `onboardingStepPositionFor` already produce 2, 3 and 4; neither needed changing. - Widens the experimental-settings query from step 4 to steps 3–5, so the strip can read it on every step of the arc. - Adds tests for both strip lengths. ## Verification - `pnpm vitest run src/components src/adapters storybook` in `ui/` — 2309 tests pass. - `pnpm typecheck` in `ui/` — clean. - Storybook, `Onboarding/Agent arc`: its fixture is cloud-shaped, so the three steps now announce "Step 2 of 4", "Step 3 of 4" and "Step 4 of 4" with four dots. - The two new tests fail without the change — the cloud case reports `expected 'Step 1 of 3' to be 'Step 2 of 4'`. ## Risks - **The two runs entering on the agent step are genuinely different, and only one signal separates them.** A cloud tenant walked a naming screen in Cloud; a self-hosted company with no agents walked nothing before this. Getting it backwards would either restart the count or credit a step nobody walked. Both directions are now tested, which they were not before — the suite covered `agentArcStepFor` but nothing asserted which strip renders. - `enableManagedSandboxOnly` is being read as a proxy for "came from Cloud". It is the same signal the connect step already trusts for its environment, so this does not introduce a new dependency, but it is inference rather than a fact passed at the hand-off. If the step count ever needs to vary, Cloud should seed the position explicitly instead. - The widened query means the value can be unresolved on first paint, and the strip briefly renders three dots before settling to four. The query key is shared and usually already cached, so this is rare rather than routine — worth watching on staging, and the fix if it shows is to hold the strip until the value resolves. - Cosmetic only. Nothing here changes which steps run, what they collect, or where the walk goes. ## Model Used Claude Opus 5 (`claude-opus-5`), via Claude Code with extended thinking, tool use, and browser-driven verification of the rendered strip. ## 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 - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
@paperclipai/ui
Published static assets for the Paperclip board UI.
What gets published
The npm package contains the production build under dist/. It does not ship the UI source tree or workspace-only dependencies.
Storybook
Storybook config, stories, and fixtures live under ui/storybook/.
pnpm --filter @paperclipai/ui storybook
pnpm --filter @paperclipai/ui build-storybook
Typical use
Install the package, then serve or copy the built files from node_modules/@paperclipai/ui/dist.