[Zarathos94]

Stacked on #60 (Weft); its base is feat/weft.

A project's life after it is built: projects get modes, and in maintenance agents read analytics, user reports and feedback, keep a map of the product and propose work with its impact and value; the owner picks what is done. Projects get environments with deploys. A finished project can be brought in. Files can be dropped or picked into a project, while making it or later, and onto chats. And the 3D views work on a Mac.

Modes

• A project has a mode: build (the default; agents plan and build) or maintenance. The modes are one table (projects::MODES), so another mode is a row plus the behaviour that reads it.
• POST /v1/projects/{id}/mode. Back in build, a delivered project reopens at implementation. A delivered project in maintenance stays worked: its agents are not sent to the bench, its budget stays, and the owner's picks can be posted as tasks.
• Consoles: a Mode button on the project page (web and desktop), a Maintenance badge, and agentplaza projects mode|modes.

Maintenance (crates/apid/src/maintenance.rs)

• Signals. The inbox holds what is heard about the product: the owner's notes, a public ingest address per project (POST /v1/ingest/{token}, for an app's feedback form, an error tracker's webhook or a support inbox; the token is shown once and kept as its hash), and digests agents write from the analytics, error or support tools the project may use (connectors and MCP servers).
• Sweeps. One watcher's turn, on a schedule (every N hours), when the project enters maintenance, or when the owner asks. Watchers are the project's agents, planners and researchers first, in turn. A sweep's prompt carries the owner's focus, the sources, the new signals, the map, the proposals waiting and the owner's declines with their reasons.
• The map. The product's areas: their code paths, health, notes and links.
• Proposals. Each says what would change, who it touches, its risk, its value (1–5) and why, its size, the evidence (signal ids, which must exist), the role and how it is judged done. Duplicates are refused, and a project holds at most 40 waiting proposals.
• Instruments. When the watchers lack data to decide well (no analytics, no error reports), they propose an instrument: a connector, MCP server, analytics or tool to build or integrate, and the data it would give.
• The owner decides: Do it makes the proposal a task of the project. An instrument the plaza already knows is instead set up by the owner in Connectors or MCP. Later and No (with a reason the next sweep reads) are the other two answers. Agents cannot post tasks to a project in maintenance (law T-024), so the owner's picks are its only work.
• Agent tools: plaza_maintenance (read), plaza_maintenance_map, plaza_maintenance_propose, plaza_maintenance_signal. They are offered only on a project in maintenance.
• Web: a Maintenance tab.
  • Baseline: one line says what waits for the owner, with the sweep's status. The product map is an animated graph: the product in the middle, areas around it coloured by health, links between them, and the waiting proposals as dots beside their area.
  • Clicking an area or a proposal opens it beside the map. The ranked proposals show value dots, risk, size and the three answers.
  • Below: the inbox, the ingest address, what the watchers read, and the data they lack. Expert shows every field and the decided proposals.
• Desktop: a Maintenance tab.
• CLI: agentplaza projects maintenance <id> [sweep|focus|every|signal|proposals|show-proposal|approve|decline|later|ingest].

Environments (crates/apid/src/environments.rs)

• Each project has as many environments as it needs: production, staging, preview, development or other. Each has its address and its track:
  • every landing on main,
  • each signed (or imported) release,
  • or what the owner deploys by hand.
• Each environment also has variables, secrets (vault, binding project:<id>.<env>, names only on read) and its deploy record.
• A deploy calls the environment's deploy hook (a CI's or host's URL, kept in the vault) with {project, environment, version, repo, url, by}. Without a hook the deploy is only recorded.
• Tracked environments deploy on their own after a landing or a signed release.
• A protected environment (production by default) waits for the owner: an agent's deploy and a tracked one go to Approvals as a deploy, while the owner's own deploy goes at once.
• Agent tools: plaza_environments (read) for every agent. plaza_deploy for builder, qa, release, incident and edge-operator agents (law T-025).
• Consoles: an Environments tab (web and desktop), and agentplaza projects env <id> [set|rm|deploy|secret].

Bringing in a finished project (crates/apid/src/adopt.rs)

• POST /v1/projects/adopt opens a project from:
  • a repository on a git platform the plaza may use (connected, so later work exports back),
  • a public git URL,
  • a folder with a git repository on the hub's machine,
  • or nothing yet (files come by upload).
• The import uses Weft's (history and tags).
• It opens delivered (or in implementation), in maintenance unless told otherwise, with its environments, and the first sweep maps it. Anything that did not work is listed in problems; the project stays.
• Consoles: a third way in the New project dialog (web and desktop), and agentplaza projects adopt.

Files

• Into a project's repository: PUT /v1/projects/{id}/uploads takes one file's bytes into Weft by hash (chunked past 4 MiB). POST /v1/projects/{id}/files then lands them all as one owner change on main. Paths are checked: no .., nothing in .git.
  • Web: drop files or whole folders, or pick them, on the new-project dialog or a project's Add files card. .git, node_modules and .DS_Store are left out.
  • Desktop: pick files or a folder, or drop them on the window.
  • CLI: agentplaza projects upload.
• On chats: PUT /v1/files?name= stores an owner attachment. It is private until a message carries it, and then the agent it goes to may read it with plaza_get_file.
  • The chat, conversation and steer bodies take attachments, and the prompt says where each file is.
  • Web: the IDE chat, conversations, the agent page and the overview take drops, pastes and a paperclip.
  • Desktop: the IDE composers take a picker and window drops.
  • CLI: chat --attach.

The 3D views on a Mac

On a Mac the hub's own machine had not reported its facts, so GET /v1/fleet sent null for its kind, arch, OS, backend, CPU and sizes. The engine read those as plain strings and numbers and refused the whole fleet. The web Machines view then said "3D needs WebGPU or WebGL2" in a browser that has both, and the desktop's 3D had no fleet either.

• Every fleet field now reads null as its default.
• The web logs and skips a feed the engine refuses, instead of tearing the view down.
• It names the real reason when 3D does not start.
• It retries on WebGL2, on a fresh canvas, when WebGPU is present but fails to start.

Verification

• Tests: cargo test --workspace (134 suites) and cargo clippy --workspace --all-targets -- -D warnings pass on macOS, and npm --prefix apps/web run check passes. New tests:
  • apid unit tests for maintenance, environments, adopt and file paths;
  • the desktop tabs, the attachments and the adopt form;
  • the CLI (about 24 new);
  • web suites for maintenance (28 checks), environments (54), the new-project dialog (43) and attachments (15).
• End to end (crates/apid/tests/maintenance.rs, a scratch hub with Weft and stand-in daemons):
  • A folder's git history is adopted with two environments, and the project opens delivered and in maintenance.
  • A sweep with no agents is refused with its reason. The planner's sweep asks for the map and carries the signal.
  • The watcher maps the product, records a digest and proposes. A duplicate and evidence naming a missing signal are refused.
  • The orchestrator's task post is refused. The owner's pick becomes a builder task with its acceptance; a second pick is refused.
  • A decline's reason reaches the next sweep.
  • The ingest address takes a report, and a wrong token is a 404.
  • Staging deploys at once through its hook. Production waits for the approval, then deploys.
  • A chat's attachment reaches the prompt and is readable only by that agent.
  • Uploaded files land in the repository.
  • Back in build, the project reopens at implementation and the maintenance tools are no longer offered.
• By eye on a demo hub:
  • The Machines view and a machine's page draw in 3D in Chrome on this Mac; before the fix they showed "3D needs WebGPU or WebGL2". The desktop's Machines view draws on Metal (Apple M5).
  • The web Maintenance tab: the graph, the area panel, Do it / Later / No. The Environments tab, and the new-project dialog.
  • The desktop's Maintenance tab.
  • Issues found that way and fixed: the page jumped to the top after an answer; the areas were stuck in the middle when the page was in the background; a toast came from a platform that did not answer.
• Not covered: sweeps by real agent VMs (the end-to-end test plays the agents through the internal API); real deploy hooks of a CI or host; the desktop Environments tab and adopt form by eye (their tests and clippy pass).

For review

• In maintenance the owner's pick is the only way work starts. An agent that thinks something is urgent proposes it; nothing deploys or builds on its own.
• Instruments that match a known connector or MCP preset are approved without a task, because their credentials are the owner's to give.
• Environment secrets are owner-managed and named to agents, not injected into agent VMs. Deploys use the hook.

🤖 Generated with Claude Code

[github-actions]

Tests: passed

Where	Result	Passed	Failed	Time
Linux arm64	passed	669	0	10 s
Linux x86_64	passed	3680	0	47 s
macOS Intel	passed	3145	0	56 s
macOS Apple Silicon: build only (cannot run here)	passed
Windows arm64: build only (cannot run here)	passed
Windows x64	passed	3185	0	62 s

_{Commit 0a89949 · the run}

[github-actions]

Lint: passed

Check	Result
rustfmt	passed
clippy (warnings fail)	passed
cargo deny (advisories, licences, sources)	passed
migrations (applied ones unchanged, new ones in order)	passed

_{Commit 0a89949 · the run}

[github-actions]

Web console: passed

Check	Result
type-check	passed
build (with the wasm engine)	passed
tests	passed

_{Commit 0a89949 · the run}

[github-actions]

Hub API (Bruno): passed

231/231 API requests pass · 149/527 operations tested · 16 fuzzing findings (reported, they do not fail the pull request)

The report

_{Commit 0a89949 · the run}