Fractera

activate-project

Activate a guest project deployed into the app slot (:3000) — make it a first-class Fractera project: add the standard workspace pages and migrate its cloud dependencies (DB / storage / auth / vector store) onto this server's substrate. Use right after a fresh deploy whose framework is not fractera-pro. Never activate without the owner's go.

choose-agent

Pick WHICH of the 5 coding agents (claude-code/codex/gemini-cli/qwen-code/kimi-code) to delegate a task to. Use before every delegation: call the readiness MCP for the facts (installed/logged_in/busy/warmth), then apply the judgement here. Use when you are about to hand coding work to an agent and must choose the right one.

compose-frozen-template

Add a whole STRUCTURE to the site (a news feed, a blog, a documentation tree, a catalogue) by COMPOSING it from the Frozen Template Constructor — vetted frozen bricks assembled by file copy + token substitution, with ZERO code generation, so any model gives the identical result. Use when the owner says "make me a news page", "add a blog", "I want documentation", "add a catalogue". The composer (compose-frozen-template.mjs / the owner_template_compose_structure MCP tool) MATCHES the request to a primitive by its envelope (100%-fit on every axis or it is NOT that primitive), installs the shared engine if absent, and composes the router + placeholder documents through two seams (list provider + uniform aspects). If nothing fits, REFUSE HONESTLY naming the failing axis and offer to harvest a new brick or use classic development — never force a bad fit, never generate code. Also composes a PROJECT PAGE (the Projects layer starter interface: description + react-flow process diagram + cron-queue and results tables +

confirm-before-mutation

Global interaction rule for EVERY state-changing MCP tool call: before any write / mutation (set, toggle, create, update, apply), restate the intent back to the owner, list the concrete actions, and wait for explicit confirmation. Use whenever you are about to call a tool that changes state. Read-only tools need no confirmation.

delegate-task

Delegate a coding task to one of the 5 AI coding platforms and handle the result. Use when a task needs real code written (a single feature or bug), or you want a second model's take. Frames the prompt, calls owner_delegate_task_to_platform / _best_platform, reviews the output, and records the deployment afterwards.

expand-site-language

Add a NEW language to an EXISTING site across ALL its content, and translate the pages later without blocking. Use when the owner says "add Armenian / Spanish / French to the whole site", "make the site multilingual", "translate the whole site into X", "scale this to more languages", "add a new language to all pages/sections", or "add a locale". This is the ONLY correct way to add a language to existing content. Do NOT use compose-frozen-template, manage-content-collections, or owner_template_update_group for this — they cannot add a per-page locale to existing pages and will refuse or break the site. Two tools: owner_content_add_site_language (fan the language out, seeded with the default language so the site is valid instantly, no translation API) and owner_content_translate_pending (the non-blocking runner — you translate the strings later). Self- sufficient: no Hermes, no other agent.

manage-app-settings

Read or change the deployed app's settings — brand name, description, URL, support email, SEO/OpenGraph, PWA, analytics, structured data — and the app's language set. Use when the owner says things like "rename my app", "change my description to 'Рога и копыта'", "set the site URL", "turn on the Organization schema", or "add French". Writes go through the validated app-settings-bridge MCP setter (:3218) — never raw JSON.

manage-content-collections

Create, edit or delete CONTENT in the site's collections — a whole GROUP (a tab: news / blog / documentation) or a single PAGE (a post inside a tab). Use when the owner says "add a news article", "add a page to the blog", "edit this post", "translate this article", "delete that page", "remove the news section", or "rename the blog section". You pass the CONTENT (a structured data object — describing content is NOT programming); the tool writes the files, by construction, with ZERO code generation, so any model gives the identical result. ANTI-DESTRUCTIVE: if a collection already exists you ADD a page or EDIT it — never recreate, never offer to "rewrite all". Integrity is enforced (folder===slug, only the app's languages, no foreign-script junk, founder block last, a required root anchor). Self-sufficient: no Hermes, no other agent.

orchestrate-content-by-steps

Do a content request the RIGHT way, end-to-end, through the frozen development-step process. Use whenever the owner asks for content work — "make me a page about Apple", "add a news section", "add 3 test news", "create a blog". You pass only the INTENT (an action + a topic); this orchestrator DECOMPOSES it by the site's state (does the section exist?) into dependent sub-steps, and runs EACH through the full lifecycle: open a development step → do it → deploy → RECORD the deployment → close the step. The deployment record is a GATE — a step never closes without it (the Vercel invariant). You do NOT chain tools yourself, do NOT decompose by hand, do NOT generate content or code. Prefer this over calling compose / create-page directly for any real owner request.

orchestrate-project-by-steps

Turn a PROJECT (automation / internal tool) request into a fully decomposed, materialized queue of development sub-steps the RIGHT way — the frozen process for projects, the sibling of orchestrate-content-by-steps. Use when the owner wants a private automation ("summarize my YouTube channels to Telegram every morning", "auto-publish on a schedule", "a tool for my own use"), NOT a public content group. You (Hermes / a model) PROPOSE a graph of nodes (task / tools / keys / io / dependsOn); this engine NORMALIZES it, VALIDATES the DAG, GATES on spec completeness, and MATERIALIZES the whole queue to disk — one rich spec step per node plus one coder-handoff step per node — BEFORE any development. It does NOT deploy, does NOT execute a node, does NOT write code: a coding agent builds each node LATER from its step file. The gate is SPEC COMPLETENESS, not a deployment record.

prepare-automation-knowledge

Prepare the KNOWLEDGE an automation/project needs BEFORE any code is written: at planning time explicitly consider the class of external tools (web search like exa.ai, platform APIs like the YouTube API, ready-made skills/MCP connectors found on the internet); default to DELEGATING the build to a coding agent with the fullest possible specification file; and — because coders usually have NO internet — transfer the external documentation they need onto the workspace disk (CRUD-DOCS) + Company Memory with the owner's agreement, token-lean (metadata only, the document body never enters the model context). Sequence: find → agree → transfer → ingest → reference the local paths in the coder's spec file. Via MCP: owner_docs_transfer_external_documentation (:3230).

propose-new-agent-skill-or-mcp

Propose a new agent skill or MCP connector for any of the 6 agents by creating a draft record on /ai-draft-settings. Use when you spot an automation opportunity, a repeating pattern worth capturing, or the architect says "document this as a skill / add this to the agents". You do NOT build the real file — the draft is the proposal the architect approves and materializes. Calls owner_draft_create_record (dry_run first, §8.2 confirm).

record-deployment

Log each development deployment into the Product Loop "Deployments" table the owner sees in admin — which agent did the work, which model, token cost, commit, and the page URL to review. Use once per deployment, right after a delegated change goes live and before you hand the owner the URL. Calls owner_product_loop_record_deployment.

scaffold-route

Turn a declared route into the standard shell-component skeleton (page.tsx + _components/index.tsx + a leaf + a full RouteMeta _meta.ts) with the access shape baked in, instead of hand-typing the convention. Use when a declared /architecture node must become a live page/endpoint, or any new route starts. Hermes orchestrates; a coding agent runs the project-local emitter — pick it with choose-agent + delegate-task.

perceive-workspace

See what is really on the owner's site before you act. Use whenever the owner asks about EXISTING things — "what do I have", "what pages / news do I have", "list my posts", "is there a blog already", "change this page", "delete that one". Call ONE tool, owner_perceive_workspace, and answer from what it shows you — the live site, not the deploy history and not memory. It is read-only (it changes nothing). Perceive first, then act.

manage-app-shell-auth

Enable or disable the PUBLIC auth control of the app shell — the Sign in / account button in the header and the signed-in visitor's account drawer. Use when the owner says "add login", "add auth", "I want a personal cabinet / my account", "let users sign up", or when you are building an app that NEEDS visitor accounts (a store, a social app, a SaaS dashboard) — and when the owner says "remove login". It is a BUILD-TIME toggle (NEXT_PUBLIC_APP_SHELL_AUTH = left | right | off) written through a validated setter; a change applies after a REBUILD. Self-sufficient: the setter is registered in every agent's MCP client — no Hermes required. The admin login always exists separately; this governs only what your visitors see.