keelen.ai

keelen-saas Roadmap intake. Submit product requests; PM intake classifies each into roadmap items, clarifying questions, or steering rules. No project yet? There are TWO ways to get one - ASK the user which applies, do not assume: 0a. EXISTING repo -> import_project(repo_full_name[, build_description, project_kind, stack, preview_command, engine]) - connect a repo the user already has. list_github_repos() browses what the workspace's GitHub connection can see. `project_kind` is optional (auto-detected) but PASS IT for a monorepo or a stack with no standard root manifest (Java, Ruby, PHP, .NET) - detection yields 'unknown' there, which blocks the dev lane. 0b. NEW repo -> create_project(name, build_description, project_kind[, private, preview_command, org]) - scaffold a NEW GitHub repo + bootstrap project and submit build_description as the first Request. `name` is a concise repo slug; `project_kind` is required (library | node_library | python_library | web_app | godot_game | roblox_game); web_app needs preview_command. Pass `org` (a GitHub org login) to create the repo inside that organization; omit it to use a workspace member's personal account (repo-create OAuth). Then poll get_request_status with the returned thread_id. Workflow: 1. submit_request(project_id, text) - ONE feature/intent per call, text < 16000 chars. Split a multi-feature ask into separate requests. 2. Poll get_request_status. Intake runs async (~5min cadence) - wait between polls. Read next_action: wait | answer_questions | done | cancelled | failed | approve_plan (a planned request's plan awaits the user's approval in the dashboard). 3. If answer_questions -> answer_request (one answer per question). 4. After done -> optionally refine_request (max 5x) to adjust items. Project context (optional, anytime): - set_product_vision(project_id, vision_md) - set the product vision. - set_product_goal(project_id, goal_md) - set the product goal. Both are prepended to PM/dev/QA iter prompts as project context. Operating a running project: - project_status(project_id) - lifecycle status, open tasks, queued_roadmap_items (planned work awaiting expansion, separate from open tasks), iters today, prs_merged_today (the DELIVERY signal: distinct PRs merged today), ui_review (web_app only: scenarios/scenario_cap/captures/capture_cap of the default-branch ui-review.json — both caps are enforced at push time, not in your CI), pass_rate (the local verification pass rate over the last 14 days of dev/QA iterations - NOT a delivery measure; read prs_merged_today for that), verify_decided_14d / verify_errored_14d (the ratio's denominator and its sandbox-timeout share: when errored dominates, pass_rate measures the verify budget, not the code), open escalation COUNT, plus pause state (scheduler_enabled, scheduler_paused_until, pause_reason), freshness (last_iter_at, last_pm_iter_at, last_successful_deploy_at — a LEGACY pointer; read deployment {merged, deployed, verified, last_deploy_attempt} for the three facts kept separately, and treat only `verified` as a verified deployment), and glm_peak_paused (+ glm_peak_resumes_at) for the EPHEMERAL GLM peak-hours skip the pause columns can't show — to tell a paused-by-policy project from a genuine stall. pm_lane {last_pm_iter_at, repo_access} is the PLANNING lane's live health: repo_access 'failing' means that lane cannot read the repo from GitHub even while runs still start and github_connected reads true (that flag is presence-only). - list_roadmap(project_id) - the queued roadmap items + their priority_int; reorder_roadmap(project_id, ordered_ids) reprioritises that queue (first id = expanded next; horizon pins still dominate). - list_escalations(project_id) - the open dead-ends to surface + resolve (project_status only counts them). - resolve_escalation(escalation_id, decision_md) - acknowledge one handled ask only when a blocked task keeps another visible path; a project_pause/orphan_pause resolve RESUMES the project. - retry_blocked_task(escalation_id, decision_md) - after fixing the cause of an eligible recovery-budget task block, grant that task one fresh attempt. - requeue_for_review(task_id, expected_head_sha, reason, request_id) - owner only: return a blocked task whose own PR is green and verified at that exact head to normal review. Pass the TASK id, not an escalation id. A refusal returns a stable cause_code. - rearm_roadmap_item(escalation_id) - perform the dashboard's idempotent same-item dependency re-arm without changing its id or declared roadmap dependencies. - resolve_platform_policy_conflict(escalation_id, decision, decision_md[, project_cap][, selector_corrections]) - apply a structured product decision to the plan and atomically requeue the same task lineage; correct_evidence_selector is owner-only. - replan_task(project_id, task_id, title, body_md, acceptance_criteria, decision_md) - replace unretryable stale work under the same roadmap/attempt lineage and transfer its graph edges. - control_scheduler(project_id, action) - action enable|disable|resume|process_now to wake a dark or paused project. - run_security_review(project_id) - kick off a deep whole-repo security audit; findings post to the project's Security review to triage + send to the loop. - run_legal_exposure_review(project_id) - kick off a legal exposure review; it maps code observations to commonly cited legal obligations under the project's saved compliance profile. Needs that profile first. - get_legal_exposure_findings(project_id) - read those findings, worst exposure first, with the checks that could not decide. BOTH legal tools return a `disclaimer_md` field. Read it to the user before you summarise a finding. This lane is an ENGINEERING review, not legal advice and not a legal clearance, it is not exhaustive, and an empty result is never proof that anything is in order. Never turn its output into a score, a grade, or an overall verdict. - run_control_gap_review(project_id) - kick off a security control gap review after the user saves a framework selection and stack context. - get_control_gap_findings(project_id) - read source-bound observations, review boundaries, and items the review could not determine. BOTH control-review tools return a `disclaimer_md` field. Read it to the user before you summarise an observation. The output is evidence from named sources, not a framework outcome. An empty group never establishes that a control is in place. Most tool responses carry next_action + next_step. next_action is ALWAYS a string, one of: wait | answer_questions | done | cancelled | failed | approve_plan | call_tool | browser | collect_code | save_key_and_reconnect | none. 'call_tool' means call the tool named in the sibling `next_tool` field; 'browser' means send the user the URL named in next_step. When next_action is 'wait' AND poll_after_seconds is present, re-check after that many seconds - re-checking is YOUR job, the server does not push. A 'wait' with NO poll_after_seconds has nothing to poll over MCP (e.g. run_security_review, whose findings land on the project's Security review page, or an errored get_provisioning_status, which will not change until its reported cause is fixed): report it to the user instead of looping. Getting started (no account yet): This server accepts a tokenless connection for signup. If the user has no Keelen account, drive the whole setup from chat: 1. ASK THE USER for the email address, in chat, and WAIT for their answer before calling signup(email). Do NOT take the address from your client profile, the logged-in account, git config, or any other ambient source - the user's Keelen account is often NOT the account you are running under. If you already hold a candidate address, echo it back and get an explicit yes first. This matters because signup also doubles as agent LOGIN for an existing account: a guessed address silently signs you in to whatever workspace owns it, and the next steps then mint an API key on, and create a project in, the wrong account. signup(email) emails the user a 6-digit code. 2. Ask the user to read the code from their inbox, then verify_email(email, code) - it returns a reveal-once API key. 3. Save that key as this server's Authorization header ("Authorization: Bearer <api_key>") in the MCP CLIENT CONFIG, then RECONNECT. The key is shown once - never write it to a repo/file. 4. get_onboarding_status() - loop it and follow next_action/next_tool + next_step verbatim: engine connect happens in the DASHBOARD — call open_dashboard() for a one-click signed-in link (the user is already authenticated through this server, so no email login; NEVER paste Claude/Codex/GLM credentials in chat) -> connect_github() for the install link -> create_project (new repo) or import_project(repo) (existing; list_github_repos() to browse) -> get_provisioning_status(project_id) until ready (if it reports errored, stop polling and fix the cause first). 5. get_billing() when the user is ready to run compute - it returns a Stripe checkout link (the one step that must open a browser).