Keelen

List the projects in this workspace, with what each one is building.

Takes no parameters.

Start building something new: creates a GitHub repo and begins work on it. For a NEW repo. Given an existing repo, import_project(repo_full_name) is the right call — this one would create a second, empty repo beside it (list_github_repos() browses what the workspace can see). Scaffolds a new GitHub repo, a bootstrap-mode project, and submits `build_description` as the project's first Roadmap Request. `name` is a concise GitHub short repo slug (no owner); `project_kind` is REQUIRED and one of library | node_library | python_library | service | cli | web_app | godot_game | roblox_game; `preview_command` is required iff `project_kind == 'web_app'`. `engine` is OPTIONAL — one of claude_code | codex | glm | kimi | grok (defaults to claude_code); codex, glm, kimi, and grok require the workspace to have a matching connected credential. `org` is OPTIONAL — a GitHub organization login to create the repo inside (e.g. your company org); omit it to land the repo on a member's personal account. `private` defaults to True. `ci_runs_on` is OPTIONAL — the CI runner labels for the scaffolded workflow, e.g. ["self-hosted", "linux", "x64", "my-fleet"]. Omit it to inherit the workspace default (ubuntu-latest if unset). Labels no registered org runner carries are rejected, because GitHub would queue such a job forever rather than fail it. `framework` is OPTIONAL and `web_app`-only — one of vite | next (defaults to vite). It picks the scaffolded frontend rails: `vite` a vanilla-TypeScript SPA, `next` a Next.js app-router app. Passing it with any other `project_kind` is an error. The repo is created on the GitHub account of a workspace member with repo-create OAuth access (this path has no specific caller user), so the returned `repo` owner is whichever member's token resolved (or the chosen `org`). If no member has repo-create access — or the resolving member can't c

Ask for a change in plain English: a feature, a bug fix, or a new direction. Each call carries ONE feature or intent; a multi-feature ask belongs in separate requests. `text` must be under 16000 characters. Returns {thread_id, status, next_action, poll_after_seconds, next_step}; next_step names the re-check of get_request_status after poll_after_seconds.

Check what happened to a request, and read any questions it asked back. Intake is async (~5min cadence), so the status changes between calls. `next_action` is one of: "wait" (still processing), "answer_questions" (answer_request takes one answer per question), "done" (see generated_roadmap_item_ids), "cancelled" (terminal, no items), "failed" (see intake_failure_reason), "approve_plan" (a planned request's plan awaits the user's approval in the dashboard). A planned request also carries `stage`, `plan_cycle` and `max_cycles`.

Say what this product is for, so every run knows what it is building toward. `vision_md` is free-form markdown and must be non-empty. Tenant-scoped: a project not in the caller's workspace 404s. Returns {project_id, product_vision_md, updated_at, next_step}.

Set the outcome to aim at right now, so work is prioritised toward one thing. `goal_md` is free-form markdown and must be non-empty. Tenant-scoped: a project not in the caller's workspace 404s. Returns {project_id, product_goal_md, updated_at, next_step}.

See what is planned for a project and in what order. Queued rows also say whether the expand picker would elect them (`electable`) and, when not, why it skips them (`skip_reason`: awaiting_intake_thread | awaiting_clarification | crash_capped | noop_capped | crash_cooldown | noop_cooldown | held_on_open_pr | other). The first reason that applies, in that order, is the one returned. `awaiting_clarification` means the planner asked a planning question about the item and waits for the answer: `list_escalations` returns that card with the item's `roadmap_item_id`. A skipped item ahead of yours does not delay it.

Change what gets built first. `ordered_ids` is the desired front-to-back order of queued roadmap-item ids (list_roadmap returns them). The first id becomes the highest priority — the cadence expands the lowest-priority_int queued item next. Horizon pins still dominate: a pinned-later item stays at the back and a pinned-now item at the front, regardless of position in `ordered_ids`. Ids that are unknown or no longer queued are skipped; duplicates are rejected. Returns {updated, queue, next_step}.

Cancel / close a single roadmap item (list_roadmap returns its id). For a DELIVERED or duplicate item that keeps re-parking: once the work has shipped, every expand produces no dev-ready tasks and files a recurring `roadmap_item_parked` escalation that has to be acked. Cancelling drops the item out of the expand queue AND resolves any open expand-lane escalation for it. Business-level replay guard: an already expanded/cancelled item changes no state, and the dashboard can restore a cancelled item. Refuses (409) while the item is actively being expanded (a retry once that iteration ends succeeds). Returns {id, status, changed, next_step}.

Clear a queued roadmap item's horizon pin (now/next/later → none). A horizon pin dominates the queue sort, so `reorder_roadmap` cannot move a pinned item out of its band — a stale `now` pin on a delivered/duplicate item clogs the front of the queue. This unpins it and reprices the queue so the item follows plain priority order again (and reorder_roadmap can then move it). Only queued items carry a settable pin (in-flight / shipped items derive theirs), so this refuses (422) on a non-queued item — a delivered item is closed with cancel_roadmap_item. Returns {id, previous_pin, horizon_pin, next_step}.

Roll a Roblox project's place back to a previously-published version. For a `roblox_game` project, re-publishes the RETAINED build artifact for `version_number` (the web Roblox Publishing card lists published versions) — it never rebuilds from source, so rollback is fast + deterministic. This mints a NEW Roblox version pointing at the old build. Unknown version → 404; a version with no retained artifact → 422; a place open in Studio / rate-limited → 409 (a retry can succeed); an invalid or unscoped Open Cloud key → 409 / 403. Returns {version_number, env, published_at, status, next_step}.

Check how a project is doing: what is in flight, what shipped, what is stuck. Returns lifecycle status, open task count, queued roadmap item count, runs today, verification pass rate, open blockers, pause state, and freshness. Zero `open_tasks` does not mean an empty roadmap: `queued_roadmap_items` counts planned work awaiting expansion, including work held while the scheduler is disabled. list_roadmap returns those items. `glm_peak_paused` is NOT a fault and sets no pause columns: it is the ephemeral GLM peak-hours skip. True means clean PRs hold and runs stop until `glm_peak_resumes_at`. It is an intentional cost gate, so the accurate description is "waiting for off-peak", not a failure. For `web_app` projects the optional `ui_review` block can mint a GitHub installation token and read the default branch's `ui-review.json`, so this status call is not guaranteed to be a purely local read. `model_roles` (only when the Researcher/Integrator feature is enabled for the project) reports each optional stage's on/off configuration and last outcome.

Close a task that should not be built — a duplicate, or work already shipped. For a task on the board that is obsolete: the change already landed in another PR, a sibling task covers it, or the user changed direction. The task is marked `cancelled` and keeps ALL of its history (acceptance criteria, QA steps, iterations) — nothing is deleted. `reason` is REQUIRED and is recorded on the audit trail in one line. `superseded_by_pr_number` (or `superseded_by_task_id`) records verified provenance when the work was genuinely delivered somewhere else, instead of a bare abandon. Closing does NOT claim the content is on the default branch, so any task that declared a dependency on this one keeps waiting; those are delivered or re-planned separately. Refuses with 409 while the task is being worked on by a running iteration (an in-flight iteration must finish, or its machine must be stopped, before the close succeeds). A task in another workspace 404s. Business-level replay guard: closing an already-closed task changes no task state. The call is not idempotent end to end — an authenticated request also persists credential-use state. The response echoes `open_tasks`: how many tasks are still open on the project, counted after the close commits. A count that did not drop means the ticket was already closed and this call changed nothing. It is the same count `project_status` returns, and neither counts a closed task as open. This is preferable to leaving a dead task on the board: unfinished tasks count against the project's planning capacity, so stale duplicates quietly stop new roadmap items from being expanded.

Read a project's current product goal (the outcome work is aimed at). The paired setter `set_product_goal` replaces the whole document rather than appending to it, so a write without a prior read silently discards whatever the user already recorded; adding a line means reading the current text, editing it, and setting the full result back. Returns {project_id, product_goal_md, updated_at}. `product_goal_md` is None when no goal has been set. Tenant-scoped: a project not in the caller's workspace 404s.

Read a project's current product vision (what the product is for). The paired setter `set_product_vision` replaces the whole document rather than appending to it, so a write without a prior read silently discards whatever the user already recorded; adding a line means reading the current text, editing it, and setting the full result back. Returns {project_id, product_vision_md, updated_at}. `product_vision_md` is None when no vision has been set. Tenant-scoped: a project not in the caller's workspace 404s.

See what the work is stuck on and waiting for a human decision about. `project_status` only COUNTS open escalations; this returns each one with its kind, reason, detail_md, recommended_action, and (when task-scoped) the blocked task's title + PR url. A card about a roadmap item carries its `roadmap_item_id` (null for a task-only, project-level or synthetic row), which matches the `id` in `list_roadmap`. A "forever-paused" project with no open `project_pause` row is surfaced as a synthetic `orphan:<project_id>` row. Each row carries a server-derived `task_retry_available` flag and an exact `next_tool`: eligible recovery blocks route to `retry_blocked_task`, roadmap parks to `rearm_roadmap_item`, platform conflicts to their structured resolver, an orphan block whose task keeps its own PR to the owner tool `requeue_for_review` (it takes the row's task_id, not its id), other stale work to `replan_task`, an open planning question (reason `expand_needs_clarification`, with its `planning_questions`) to the owner tool `answer_planning_question`, and only safe auxiliary cards to `resolve_escalation`. For an active workspace owner, an eligible platform conflict on a web_app task also lists `evidence_selector_cells`, the input of the owner-only `correct_evidence_selector` decision.

Acknowledge a handled ask only when no blocked task becomes invisible. `decision_md` is a required short note (why/how it was resolved), appended to the escalation's detail_md as an audit trail. Resolving a project_pause / orphan_pause RESUMES the project (clears the pause). A blocked task's final task_block/operator_action cannot be acknowledged: its typed retry, platform-policy resolution, replan, close, or supersede operation is the correct path instead. An open planning question is refused too: answer it with `answer_planning_question` (or `cancel_roadmap_item` if the item is no longer needed), because an acknowledgement would drop the answer. The acknowledgement itself is replay-guarded (a repeat changes nothing), but the call is not idempotent end to end: resuming a paused project lets queued refinement run, and that refinement can DELETE tasks. Accepts a real escalation UUID or a synthetic `orphan:<project_id>`.

Answer an open planning question and release its roadmap item. Use this for a `list_escalations` row with reason `expand_needs_clarification` (its `next_tool` names this tool). The planner asked one or more product questions about one roadmap item; give ONE answer that covers every question (1-4,000 characters). The answer is stored with the item, the card is resolved, and the next planning run of that item reads the answer. It is stored once: a second answer to the same round is refused. Requires the personal connection of an active workspace owner; a workspace key or a member who is not an owner is refused. A paused project refuses until it is resumed. A refusal returns ok=false with a fixed `refusal_code`, and nothing is stored. `resolve_escalation` does not answer a planning question.

Grant one fresh attempt after fixing a recovery-budget task block. ``escalation_id`` is the task_block id returned by ``list_escalations``. Eligibility, tenant, task, failure class, task status, and competing blockers are all derived server-side. This is distinct from ``resolve_escalation``, which remains acknowledgement-only for task blocks. Business-level replay guard: an already-retried block is not retried again; the call is not idempotent end to end, because an authenticated request also persists credential-use state.

Return one blocked task's existing pull request to normal review. Requires a personal OAuth connection of an active workspace owner; workspace keys are refused. Pass the task id (not an escalation id), the PR's exact 40-character head SHA, a reason (1-2000 characters) and a request_id you choose (1-128 of letters, digits, `.`, `:`, `_`, `-`). The task's own open keelen/iter-* PR must be green and cleanly mergeable at that head, and its latest DEV run must have verified that head. Status becomes done (implementation awaiting review), never delivered. Review, CI, acceptance and merge gates still apply; no retry starts and no budget resets. The same request_id and arguments replay the stored receipt. A refusal returns ok=false, reason review_requeue_refused, a stable cause_code and a fixed message.

Run the dashboard's replay-guarded same-item dependency re-arm. ``escalation_id`` is an ``expand_produced_nothing`` or ``roadmap_item_parked`` escalation id. Keelen verifies delivered structural prerequisites, grants one bounded expand retry, preserves the roadmap item id and ``depends_on_item_ids``, and resolves the matching cards in one transaction. A bounded live GitHub check may be used when the local merge state is stale, so a call can reach out even when the re-arm itself changes nothing.

Resolve a platform-policy dead-end with a structured plan decision. Choose ``decision`` from ``reuse_existing_evidence``, ``raise_project_cap``, ``remove_scenario``, or ``correct_evidence_selector``. ``raise_project_cap`` also requires ``project_cap`` (6..32). The decision becomes a new task-plan section; the same task lineage is requeued before the escalation resolves. ``split_task`` is not a recommended decision: it does NOT decompose the task and does NOT create a follow-up task. Never use it to create a follow-up; to split work, use ``replan_task`` or submit a new Request. ``correct_evidence_selector`` (web_app tasks, active workspace owner only; a workspace key or a non-owner gets ``owner_decision_required``) fixes a frozen ``ready_selector`` no scenario can prove, such as an interaction criterion frozen with the selector its static sibling proves at route load. ``selector_corrections`` maps each acceptance-criterion id (the ``criterion_id`` of a list_escalations ``evidence_selector_cells`` entry) to ``{"expected_ready_selector": <the frozen value>, "ready_selector": <replacement>}`` (at most 10). Only those selectors change; a stale expected value, an invalid selector, a cell left with two selectors, or an interaction criterion that would still share a static sibling's selector changes nothing. The old and new specs are audited. On a project that runs the ui-review evidence lifecycle (``ui-review.json`` is a retained evidence catalog), ``raise_project_cap`` changes the per-run capture budget -- how many scenarios one capture run holds -- not catalog capacity: the catalog has no scenario limit, so no decision is needed to make room in it. On a ``web_app`` task, ``reuse_existing_evidence`` also repairs a frozen theme-only collision in the same transaction: criteria whose evidence specs differ only by a light/dark variant token (for example ``setup

Set this web_app project's ui-review scenario budget, or reset it. ``scenario_cap`` is an integer from 6 through 32, or ``null`` to reset to the platform default of 12. The screenshot cap derives from it and moves with it, so the two can never starve each other. Raising is always allowed, including from a completely full manifest. LOWERING is refused when the default branch already declares more scenarios or screenshots than the smaller budget allows, and is also refused when that manifest cannot be read — both caps are enforced when keelen pushes and not in your CI, so an over-cap manifest fails every push while CI stays green. On a project with the retained evidence catalog (the response carries ``evidence_lifecycle: true``) the same parameter is a CAPTURE-RUN setting: it limits how many scenarios and screenshots one capture run holds, a pull request that needs more is split into capture batches, and the catalog keeps every scenario whatever the value. The response then also reports ``catalog`` (the retained counts) separately from ``run_limits``, and a lower is not refused for catalog size once the catalog is migrated. ``project_status.ui_review`` reports the live occupancy. Repeated calls with the same value change nothing.

List this project's active and pending steering rules. Steering rules are prepended to every planning, development and QA prompt. Each rule has `state` (`active` = in the prompt, `pending` = waiting for a project member's approval, `expired` = past its expiry and no longer in the prompt) and `origin`: `owner_request` (written from a Request), `retro_kaizen` (a sprint retrospective kaizen), `failure_pattern` (a recurring failure), `automatic` (activated without human review from another source) or `unknown` (a legacy rule with no recorded source). `auto_approved` is true when no person reviewed it. Retired rules are not listed. Use approve_steering_rule and retire_steering_rule with a rule's `id`.

Approve one pending steering rule so it reaches the iteration prompts. Pass the project id and the rule `id` from list_steering_rules. Only a `pending` rule changes; an already active rule returns `changed: false`. A retired rule is refused (409): approval never re-activates it. Your identity comes from this connection and is recorded on the audit trail.

Retire one steering rule so no later iteration prompt carries it. Pass the project id and the rule `id` from list_steering_rules. Works for an active or a pending rule, including a retro kaizen the automatic curation pass protects. The rule's text and history are kept and the retirement appears in Loop Activity. A rule that is already retired returns `changed: false`. There is no un-retire: to bring a convention back, submit it as a new Request. Running iterations keep the prompt they started with.

Replace an unretryable blocked task without losing its lineage. Creates a fresh, explicitly planned task under the same roadmap item and attempt lineage, transfers prerequisites and downstream dependents, and cancels the stale task with supersession provenance. The old PR, task, failures, criteria, and evidence remain in the audit history; nothing is marked delivered.

List or remove a dependency on a task cancelled without delivery. ``escalation_id`` is a ``prerequisite_hold_stalled`` card. A waiting task whose dependency points at a task cancelled without proof of delivery can never start. Without ``task_id`` and ``predecessor_task_id`` this lists every such dependency in the card's project and changes nothing. With both, it removes that ONE dependency, so the waiting task can be groomed and built without the cancelled work; any other dependency is refused. The card then refreshes, or resolves when no held prerequisite remains.

Start, pause, or resume a project's autonomous work. `action` is one of: "enable" | "disable" | "resume" | "process_now". - enable/disable flip scheduler_enabled (the loop dispatches only enabled, status='active' projects). - resume clears a pause (peak/backoff/manual) so the project dispatches again. - process_now durably prioritizes and immediately attempts the next intake batch, independent of the dev scheduler switch. A gate returns a typed reason and recovery step instead of a spawn promise. - enable/resume can execute pending refinement that DELETES tasks, and process_now can start an intake batch, so the tool is destructive even when the echoed scheduler state looks unchanged. Returns the resulting scheduler state.

Archive a project (reversible shelve) — frees a project slot in-tool. Stops any in-flight machine, then flips the project to `archived`: it drops out of the per-tier project cap (freeing a slot for a new project) and the loop stops dispatching it, but the project + its history are kept and can be restored from the dashboard project page. Stopping a machine DESTROYS the running process state — restoring the project later cannot bring that execution back, so this is destructive despite being reversible. A replay on an already-archived project changes no row, but is not idempotent end to end. This is preferable to `delete_project` unless the project must be gone. Owner-scoped (an MCP key is owner-only); a project not in the workspace 404s.

Soft-delete a project (the harder option) — frees a slot and hides it. Stops any in-flight machine, then flips the project to `deleted`: it disappears from `list_projects`, drops out of the project cap, and the loop stops dispatching it. Deleting ALSO permanently purges the project's stored review artifacts. The row is retained for audit and re-importing the repo restores that deleted row in place (unlike `archive_project` there is no in-tool restore), but the purged artifacts are gone for good and the stopped workers' process state cannot be recreated. A replay on a deleted project changes no row; the call is not idempotent end to end. Owner-scoped; a project not in the workspace 404s.

Find security problems in a repository: a deep, whole-codebase review. Spawns a one-shot audit that scans the repo across a kind-aware taxonomy (secrets + git history, vulnerable/abandoned deps, injection, SSRF, path traversal, deserialization, crypto, info-leak, plus web authz/session/CORS, library API-misuse, game client-trust, or infra/CI as applicable) and posts findings to the project's Security review for human triage. The findings are reviewed by a human and the ones worth fixing go into the loop as Requests; no fix is applied automatically. Billable; one audit in-flight per project. (Triggering is disabled while the feature is hardened for production: a project not on the operator allowlist — empty by default — returns a message instead of spawning; earlier results stay visible.) Requires a paid plan; a free or trial workspace gets a message telling the user to upgrade.

Find where a codebase creates legal exposure (privacy, consent, data handling). Spawns a one-shot review machine that reads the checkout offline and maps what the code DOES onto commonly cited legal obligations, filtered by the project's saved compliance profile (jurisdictions plus eleven product facts). Findings land on the project's Legal page for a human to triage, readable with get_legal_exposure_findings. No change is ever applied automatically. THIS IS NOT LEGAL ADVICE AND IT IS NOT A LEGAL CLEARANCE. The result carries a `disclaimer_md` field that must reach the user before any summary. The review is not exhaustive, so an empty result is never proof that anything is in order. Requires a saved compliance profile (409-shaped refusal without one), a plan that carries the feature, and the project on the operator allowlist. Billable; one review in flight per project. Every refusal comes back as `ok: false` with an actionable `next_step`, and starts nothing. Rate-limited per workspace.

Read a project's legal exposure findings, worst exposure first. Returns each finding as an OBSERVATION plus the obligation commonly cited over that pattern, its citation, the date the citation was last checked, and whether counsel has reviewed the registry entry (`counsel_reviewed`, false today for every entry). `exposure_order` is an ORDER, never a score: there is no grade, no percentage, and no overall state in this output. `not_determinable` lists the checks that could not reach a verdict; omitting them would turn a partial review into a clean answer. The `disclaimer_md` field must reach the user. `limit` defaults to 25 (max 100). `include_all` adds resolved, dismissed, and out-of-scope rows to the default actionable set. Read-only, no compute, no rate limit; it works even while the trigger is closed for the project.

Start a source-bound security control gap review for one project. The review records bounded engineering observations under the user's selected Cyber Essentials or CMMC Level 1 or Level 2 context. It does not determine framework standing, and it does not make changes. The `disclaimer_md` field must reach the user before any observation is summarised. The project needs a saved framework profile, an eligible plan, and a place on the operator allowlist. Billable; one review is allowed in flight per project. Refusals return `ok: false` with a next step and do not start work. Rate-limited per workspace.

Read a project's security-control observations and review boundaries. The result groups records by evidence class without a total or an overall framework outcome. `not_determinable` and `outside_review_scope` qualify every observation. An empty group does not establish that a control is in place, and `disclaimer_md` must reach the user. `limit` defaults to 25 (max 100). `include_all` includes resolved, dismissed, and out-of-scope records. This read-only tool has no compute quota and remains available after the trigger closes for a project.

Answer a thread's clarifying questions (status must be awaiting_answers). `answers` is a list of {"idx": <int from get_request_status>, "answer_md": <str, 1..2000 chars>}. Every question needs exactly one answer. The call flips the thread back to intake_pending; get_request_status reports the subsequent state.

Say what is wrong with what a request produced, and have it reworked. Status must be "done". `feedback_md` is 1..1979 chars. Moves the thread to refine_pending; get_request_status reports the revised items. Refinement re-plans the thread's roadmap items and can EDIT OR HARD-DELETE the task rows it generated earlier (the machine patch-tasks endpoint deletes them outright), so it is destructive: up to five refinements per thread each carry that power.

Create a Keelen account (or start agent login) — emails a 6-digit code. UNAUTHENTICATED — the only tool besides verify_email that works before a bearer key is configured. `email` is where the code is sent. Flow: signup(email) -> the user reads the 6-digit code from their inbox -> verify_email(email, code) returns a reveal-once API key, stored as this server's `Authorization: Bearer <api_key>` header in the MCP client config; reconnecting the client and calling get_onboarding_status() then continues setup. The code expires in 15 minutes; a repeat signup resends it. Response is uniform whether or not the email already has an account (enumeration-safe), so signup doubles as agent LOGIN. Rate-limited per IP and per email. The `email` must be explicitly provided and confirmed by the user in chat before this call. It is not inferred from a client profile, the logged-in account, git config, or any other ambient source; a candidate address the caller already holds is echoed back for an explicit yes first. Because this call doubles as LOGIN, a guessed address signs the user in to whatever workspace owns it, and the rest of setup then mints an API key on, and creates a project in, an account they did not choose.

Redeem the emailed 6-digit code for a reveal-once workspace API key. UNAUTHENTICATED. `email` + `code` must match a code issued by signup(email) within the last 15 minutes (5 attempts max). The returned `api_key` is shown exactly ONCE — store it ONLY in the MCP client config ("Authorization: Bearer <api_key>"), NEVER in a repo or a file you might commit. Reconnecting this server with the header set and calling get_onboarding_status() continues setup. An invalid/expired/consumed code returns a uniform error; a fresh code comes from signup(email).

Check what is set up so far and what to do next to get building. Reports engine_connected / github_connected / project_count / payment_status and a `next_action` string whose value is authoritative, with this tool polled between steps. `next_action` is "call_tool" (the tool named in `next_tool`, with `next_step` describing the call) until onboarding is complete, then "done". (`next_action_detail` echoes the pre-2026-07-29 dict shape and is DEPRECATED — it is removed 2026-10-29; next_action/next_tool are the current fields.) - engine step: the dashboard /login link goes to the user. Engine subscriptions (Claude / Codex / GLM) are connected in the DASHBOARD for security — engine credentials are never asked for or pasted in this chat. - github step: connect_github() returns an install link. - project step: create_project(...) for a new repo, or import_project(repo_full_name) for an existing one. - launch step: get_provisioning_status(project_id) reports readiness. Re-checking is the caller's job — the server does not push. Also returns a `usage` block (pool / daily / machine-hours counters + tier caps) for capacity-aware automation clients.

Takes no parameters.

Get a one-click, pre-authenticated dashboard sign-in link for the owner. The engine-connect step — and any dashboard task (billing card update, a project page) — needs a signed-in browser. Because this server has already authenticated the workspace owner, this mints a single-use magic-link login token and returns a `/login?token=…` deep link: opening it signs the user straight into the dashboard (no email round-trip, no password) and lands them where onboarding left off. The returned `login_url` works once and expires in 15 minutes; a repeat call mints a fresh one.

Takes no parameters.

Get the link that connects a GitHub account, so work can reach real repos. Returns an `install_url` that the user opens in a browser to pick the GitHub account/org, approve the install, and land on a "connected" page; get_onboarding_status() then reports github_connected true. The link expires in 10 minutes; a repeat call mints a fresh one.

Takes no parameters.

List repos the workspace's GitHub connection can see (for import_project). Each entry has full_name, default_branch, private, language, pushed_at. A `full_name` is what import_project(repo_full_name) connects. Reading the list can MINT a short-lived GitHub installation token, so this is not a pure read. Returns 409 if GitHub isn't connected yet — connect_github() is required first. A provider failure is translated into a typed, actionable error instead of passing GitHub's response through: a missing or suspended App installation, a revoked OAuth token, or a non-rate-limit permission denial is a 409 naming connect_github(); a recognized rate limit is a 429; other provider failures are a 502; a timeout or transport failure is a 503.

Takes no parameters.

Connect an EXISTING GitHub repo as a Keelen project. This is the counterpart of create_project: it is for a repo that already exists, while create_project scaffolds a brand-new one. `repo_full_name` is "owner/repo" — it MUST be visible to the workspace's GitHub connection (list_github_repos() to browse; a non-visible repo 404s). `engine` is OPTIONAL — one of claude_code | codex | glm | kimi | grok (defaults to claude_code); codex/glm/kimi/grok require a matching connected credential. `build_description` is OPTIONAL but STRONGLY recommended — a plain-language "what should Keelen build first?" submitted as the project's first Request so the loop has work; an imported project with no Request sits idle until submit_request(project_id, ...) adds one. `project_kind` is OPTIONAL — one of library | node_library | python_library | service | cli | web_app | godot_game | roblox_game | unknown. Omit it and the kind is auto-detected. It is required for a MONOREPO (apps in subdirectories), a stack with no standard root manifest (Java, Ruby, PHP, .NET, Elixir), or a classification detection cannot infer — detection yields "unknown" there, which BLOCKS the dev lane until someone overrides it. A supplied value is authoritative and is never overwritten by later auto-detection. `stack` is the OPTIONAL language axis (python | node | rust | go | cpp) for a language-agnostic kind. `preview_command` is REQUIRED when project_kind is "web_app" (the command that serves the app locally, e.g. "npm run dev") and optional otherwise, where it overrides the detected one. Re-importing the same live repo is replay-guarded (returns the existing project with already_exists=True), and re-importing a SOFT-DELETED repo RESTORES that deleted row in place — it does not create a fresh project. Restored queued work can include refinement that deletes tasks, and the call is not idempotent end to

Check whether a new project has finished setting up and is ready to build. Returns overall (provisioning | ready | errored), a 7-stage checklist, and a user-facing error_kind when a stage failed. next_action is "wait" with poll_after_seconds (~10s) while provisioning, "wait" with NO poll_after_seconds when errored (fix the reported cause, then re-check — polling again without fixing it will not change the result), and "done" when overall is 'ready' — submit_request(project_id, text) then steers the loop. Reaching 'ready' also PERSISTS the owner's onboarding-completion state, so this is not a pure read. Tenant-scoped: a project not in the caller's workspace 404s.

Billing status + a Stripe checkout link when a NEW subscription is needed. `plan` is one of starter | pro | agency (default starter). When the workspace has NO live subscription and needs one (open-signup unpaid, churned, or converting from a free/trial tier), returns a `checkout_url` with next_action "browser" — the user opens it in a browser (the one setup step that can't happen in chat). Compute unlocks automatically once payment completes (a Stripe webhook flips the workspace to active); blocking on it is unnecessary. A past_due workspace gets NO checkout — the fix is a card update in the dashboard billing page (a new checkout would create a second subscription); next_step carries that fix. Subscribed or suspended-with-subscription states return checkout_url=None with an explanatory next_step.

Read a compact progress digest for one project (delivery, activity, holds, next decision). Returns the closed MCP projection: delivery counts and the five newest delivered items, a recent loop-activity count, current holds, the single highest-priority open decision, and `more_decisions`. Two steering fields are ALWAYS present: `next_action` is `"call_tool"` with `next_tool="list_escalations"` when a decision exists, otherwise `"none"` with `next_tool: null`. `since` is an optional ISO-8601 timestamp with a timezone; it defaults to 24 hours ago and is clamped to the last seven days. Tenant-scoped: a project outside the caller's workspace 404s.

Stop one running iteration after confirmed runtime cleanup. Requires a personal active workspace owner. Workspace keys and Portfolio delegation cannot stop compute. The exact project iteration number binds the runtime. Cleanup failure leaves it active; a busy subject is refused. Confirmed cleanup finalizes unfinished runtime iterations, holds its legacy tasks for owner close or replan and records the owner and reason. It grants no delivery, retry or merge authority. A repeat returns the same receipt.