Plan

First, the plan.

Before meaningful changes, Picasso maps the repo and writes a reviewable plan while mutation is blocked.

Try Plan mode.

picassoplan modeplan · draft

sonnetplan

picasso›picasso›plan draftsonnetplan

Composition.

Repair the expired-session test and keep the auth suite green.

Changes

EDITsrc/auth/session.tsenforce one-hour max age.

CREATEsrc/auth/session.test.tscover expired and current tokens.

Verification

Run `pnpm test src/auth/session.test.ts` and report any remaining failures.

⏎approveeeditescreject

∠maintools4ctx28k / 200kcost$0.00modeplanwaiting

What you see.

A plan is a real work artifact. It confirms read-only architect mode, names the goal, explains the repository architecture, identifies affected boundaries, lists files, risks, and verification, and keeps the repo untouched until execution is approved.

agent loopplan / act / observe / reflect

01Planread repo, draft plan

02Actedit files, run tools

03Observetests, logs, diffs

04Reflectcontinue or stop

completion criteria

# Read-Only Software Architect

# Goal

## Repository Architecture

## Functional Capabilities

## Data Flow

## Approach

## Changes

EDIT packages/core/src/loop.ts

CREATE packages/core/test/loop.test.ts

## Risks

## Verification

You stay in control.

Approve.

Let Picasso carry out the plan and verify the result.

Edit.

Change the composition before any file moves.

Reject.

Stop the work while the repo is still untouched.

Ask.

Resolve open questions before giving the agent write access.

Architecture before action.

Plan mode locates entry points, parses package files and configs, follows imports, clusters business logic, traces data from UI to API to storage, and isolates what must change from what should remain untouched.

Entry points.

Find main files, route roots, app launches, package scripts, and service boundaries.

Dependencies.

Read package manifests, Dockerfiles, workspace configs, and framework settings.

Impact.

Identify exact modules, contracts, tests, and ownership edges likely to change.

Big work, staged.

Large changes are split into smaller pieces, each with its own verification, so review happens before the diff becomes hard to reason about.

Built for review.

The plan can be discussed before it becomes a diff. It gives maintainers a shared object: what will change, why it should change, and how it will be proven.