open-mercato/cezar

🎯 Change The /new hero (What should the agent work on?) is where someone sits while they think about what to type. Today its backdrop is static-ish: fifteen pulsing brand squares (TwinkleBackdrop) plus the ghost-code typewriter layer. The request is to give that idle surface one moment of life — a shooting star that crosses the backdrop roughly once every 10 seconds — so the screen feels alive rather than frozen while the composer waits for input. Requested by the maintainer from the screenshot below. This is a decorative addition only: nothing about the composer, its controls, or task submission changes. 📋 Scope Affected area: packages/web/src/components/centered-state.tsx (the TwinkleBackdrop texture layer) and the motion section of packages/web/src/styles/index.css. The smallest change is a new decorative element inside the existing backdrop (or a sibling layer mounted next to it in packages/web/src/routes/new-task.tsx), driven by a CSS keyframe whose cycle is ~10s with th

Follow-up from #1113 cezar ships six runners after #1113 (claude, codex, opencode, cursor, pi, copilot), but several hand-written help strings still name three or four of them, so a user or an agent reading the usage line does not learn that the runner they want exists: Where Says packages/cezar/src/dispatch/task-cli.ts:28 [--runner claude|codex|opencode] packages/cezar/src/dispatch/prompts.ts:18 [--runner claude|codex|opencode] packages/cezar/src/automations/automation-cli.ts:45 [--runner claude|codex|opencode] packages/cezar/src/automations/prompts.ts:49 // optional: claude | codex | opencode | pi The two prompts.ts entries are the ones that bite hardest: they go into an agent's system prompt, so a dispatched or automated task is actively told that a runner it could pick does not exist. These are literals, which is why nothing caught them — the same class of gap as the ones #1113's reviews found in isRunner, defaultAgentProfile and the providers/connect rejection me

Follow-up from #1113 Settings → Agent accounts has a "Show details" read per account, served by readAccountIdentity (packages/cezar/src/agent-config/account-identity.ts:163). It answers for claude, codex and cursor, and everything else falls through to one hard-coded sentence about OpenCode: OpenCode keeps its login outside its config folder, so cezar cannot read it. So pi has been told about OpenCode since it shipped, and #1113 adds copilot to the same branch. The sentence is true of OpenCode and says nothing accurate about either of them — a user reading it on the Copilot tab is being told about a product they did not ask about. From the re-review on #1113 (link), filed rather than fixed there because pi proves the gap predates that PR. Acceptance criteria Every ProviderId resolves to a reason that names its own CLI, or to a shared wording that names none ("cezar cannot read this agent's login from its config folder"). The fallthrough is exhaustive the way defaultAgentProfile

What PUT /api/v1/workspace/config validates and accepts resources.idleTimeoutMinutes, answers 200, and returns it on GET — but the value is never written. The merge-write closure in packages/cezar/src/server/server.ts (the mergeWriteWorkspaceConfig block, ~lines 3155-3175) handles maxParallel, maxMonitoringSessions, monitoringWakeIntervalMinutes, autoResumeOnUsageLimit, memoryLimitMb, dispatchMaxConcurrent and worktreeRetentionDefault — idleTimeoutMinutes has no branch, so the value is silently dropped. Evidence Live probe on main (Node 24, clean env): PUT /api/v1/workspace/config {"resources":{"idleTimeoutMinutes":30}} -> 200 GET /api/v1/workspace/config -> resources.idleTimeoutMinutes: 15 (unchanged) ~/.cezar/config.json -> no idleTimeoutMinutes written shared workspace semaphore -> 15 (unchanged) Schema side (accepts the key): packages/cezar/src/server/server.ts, resources object in the PUT body schema (idleTimeoutMinutes: z.number().int().min(0).max(1440).nullable().optional