rootr-cli 0.10.0 → 0.14.0

package/lib/mcp-tools/workspaces.js

@@ -152,15 +152,27 @@ export function registerWorkspaceTools(server) {
   server.registerTool(
     'rootr_scaffold_plan',
     {
-      title: 'Plan a workspace scaffold from an intent — then ASK THE USER before building',
+      title: 'Step 1 of scaffolding — get the design method, then think and ask',
       description:
-        'Step 1 of scaffolding, ALWAYS call this first. Given a natural-language intent (e.g. "SRE 온콜 위키" or ' +
-        '"sales CRM for a 5-person team"), Rootr\'s consultant returns a questionPolicy (ask the user MIN 3, up ' +
-        'to 10 clarifying questions — this is not optional), the dimensions to cover, domain frameworks, and the ' +
-        'buildingBlocks menu (DATABASE/DOCUMENT/SPREADSHEET/WHITEBOARD/FORM/ISSUE_TRACKER/FOLDER). You must then ' +
-        'GENERATE your own questions from those frameworks, ask the user, and only design the tree AFTER their ' +
-        'answers — every answer must visibly shape the result. Never build straight from a one-line intent. ' +
-        'No workspace needed; create with rootr_create_workspace or rootr_scaffold_apply afterwards.',
+        'ALWAYS call this first. There are NO templates and NO domain skeletons behind it — deliberately. It ' +
+        'does not classify your intent and it will not hand you a structure; what comes back is the METHOD: ' +
+        '`analyzeFirst` (the questions to answer about how this job actually runs before you design anything — ' +
+        'the daily and weekly rhythm, what piles up, what moves through stages, what arrives from outside, where ' +
+        'money is added up, what causes trouble when it is late, and above all what is UNIQUE to this job), ' +
+        '`designRules` (how to turn those answers into structure — nouns that pile up become DATABASEs, "one A ' +
+        'has many B" becomes a relation, stages become select + board, dates become calendar, outside input ' +
+        'becomes FORM + collectInto, calculation becomes SPREADSHEET, counting becomes rollup), `buildingBlocks` ' +
+        '(what the product actually offers), `questionPolicy` (ask the user 3-10 questions — you WRITE them, ' +
+        'none are provided), and `loop` (the whole sequence). Design it from scratch every time: a bakery, a ' +
+        'dental clinic and an SRE team need different things, and no catalogue of skeletons could hold them. ' +
+        'Treat it exactly like a coding request. When someone says "build me this" you ask a few clarifying ' +
+        'questions, write the code, compile it, run the tests, leave a README, and report. Same sequence here: ' +
+        'analyzeFirst = understanding the requirement · questionPolicy = the questions you ask · designRules = ' +
+        'writing the code · rootr_scaffold_review = compiling (fix what it flags, compile again) · ' +
+        'rootr_scaffold_apply = building · the how-to-use manual = the README · rootr_test_workspace = running ' +
+        'the tests. The user should only ever have to type that one sentence — ask your questions, take their ' +
+        'answers, and finish the whole thing in this conversation. If they do not answer or say "just do it", ' +
+        'assume the most plausible answers, build it anyway, and record the assumptions in the manual.',
       annotations: { readOnlyHint: true, destructiveHint: false },
       inputSchema: {
         intent: z.string().describe('Natural-language description of what the workspace/tree should be for'),
@@ -184,8 +196,10 @@ export function registerWorkspaceTools(server) {
       description:
         'Create an entirely new Rootr (루터) workspace pre-populated with the given document tree. ' +
         'REQUIRES an account key (PAT) with the workspaces:create scope — a workspace-scoped key cannot do this. ' +
-        'PRECONDITION: call rootr_scaffold_plan first and ask the user its 3-10 clarifying questions; design the ' +
-        'tree from their answers. Build a real tool, not a pile of thin markdown files: mix DATABASE (board/' +
+        'PRECONDITION: rootr_scaffold_plan first, ask the user its 3-10 clarifying questions, design the tree from ' +
+        'their answers, then run rootr_scaffold_review and fix everything it flags at `error` level. The ' +
+        'response carries the same `review` back, so a low score here means you shipped something thin. ' +
+        'Build a real tool, not a pile of thin markdown files: mix DATABASE (board/' +
         'timeline views, seed rows), SPREADSHEET (formulas), FORM, ISSUE_TRACKER and rich multi-section DOCUMENTs ' +
         'where they fit, and set an emoji `icon` on folders/databases/key documents. The `tree` shape follows ' +
         'the scaffold schema in llms.txt (max 200 nodes). AFTER creating: if your runtime can receive HTTP ' +
@@ -209,15 +223,145 @@ export function registerWorkspaceTools(server) {
     },
   );
 
+  /**
+   * WS-CLEANUP — **짓다 실패해서 남은 빈 워크스페이스를 에이전트가 치울 수 있게.**
+   *
+   * 스캐폴딩이 중간에 실패하면 껍데기만 남는데 지우는 문이 없었다. 무료 한도가
+   * 5개라 몇 번 실패하면 사용자가 바로 막히고, 그 잔해를 사람이 화면에서 하나씩
+   * 지워야 했다(2026-08-30 실측: 치과 3개·아파트 4개).
+   *
+   * 이름을 그대로 다시 적게 한다 — 서버가 요구하는 안전장치이자, 모델이 엉뚱한
+   * 워크스페이스를 지목했을 때 걸리는 그물이다.
+   */
+  server.registerTool(
+    'rootr_delete_workspace',
+    {
+      title: 'Delete a workspace you created (cleanup after a failed scaffold)',
+      description:
+        'Permanently delete a Rootr (루터) workspace. Intended for cleaning up EMPTY leftovers from a scaffold ' +
+        'run that failed halfway — the free plan allows only a handful of workspaces, so abandoned shells block ' +
+        'the user from trying again. Requires OWNER on that workspace, and you must pass `confirmName` exactly ' +
+        'matching the workspace name (call rootr_workspaces first to read it). THIS CANNOT BE UNDONE: everything ' +
+        'inside is removed. Never call this on a workspace that holds the user\'s real work — if you did not ' +
+        'create it in this session, ask the user first.',
+      annotations: { readOnlyHint: false, destructiveHint: true },
+      inputSchema: {
+        workspaceId: z.string().describe('Id of the workspace to delete'),
+        confirmName: z
+          .string()
+          .describe('The workspace name, typed again exactly — the server rejects the call if it does not match'),
+      },
+    },
+    async ({ workspaceId, confirmName }) => {
+      try {
+        const client = makeClient();
+        await client.deleteWorkspace({ workspaceId, confirmName });
+        return jsonResult({ deleted: true, workspaceId });
+      } catch (err) {
+        return errorResult(err);
+      }
+    },
+  );
+
+  server.registerTool(
+    'rootr_scaffold_review',
+    {
+      title: 'Check a designed tree BEFORE building it — the compiler pass',
+      description:
+        'Step 3 of scaffolding (plan → ask → design → REVIEW → fix → apply). Give it the tree you designed and ' +
+        'it returns { score 0-100, counts, findings[], summary } — every finding is a concrete defect with the ' +
+        'node path, e.g. a table whose only column is the title (that is a list, not a table), a lifecycle ' +
+        'column with no board view, a date column with no calendar, a form with nowhere to collect answers, ' +
+        'tables that are never related to each other, an empty guide document. Fix what it flags and review ' +
+        'again — like re-running a compiler — until nothing at `error` level is left. The rules are ' +
+        'domain-agnostic, so this works for a bakery or a dental clinic exactly as well as for a SaaS team. ' +
+        'Creates nothing and needs no workspace, so run it as many times as you like before committing.',
+      annotations: { readOnlyHint: true, destructiveHint: false },
+      inputSchema: {
+        tree: treeArg('The scaffold tree you designed — an ARRAY of node objects, same shape you would pass to rootr_scaffold_apply'),
+      },
+    },
+    async ({ tree }) => {
+      try {
+        const client = makeClient();
+        const result = await client.scaffoldReview(parseTree(tree));
+        return jsonResult(result);
+      } catch (err) {
+        return errorResult(err);
+      }
+    },
+  );
+
+  server.registerTool(
+    'rootr_review_workspace',
+    {
+      title: 'Check the workspace you ACTUALLY built — not the tree you sent',
+      description:
+        'Step 5, after building. `rootr_scaffold_review` grades the tree you DESIGNED; this grades what really ' +
+        'exists in the workspace right now — whatever tools made it. Run it after every build: a design can score ' +
+        '100 and still land broken (a form whose answers go nowhere, a view whose filter vanished, rows that never ' +
+        'got linked). Returns the same { score, counts, findings[], summary }. Pass `rootPath` to grade only the ' +
+        'subtree you just added, otherwise an older workspace drags the score down and the number stops meaning ' +
+        'anything. Fix what it flags with the normal tools (add rows, write the guide document, add the missing ' +
+        'columns/views) and run it again until it is clean.',
+      annotations: { readOnlyHint: true, destructiveHint: false },
+      inputSchema: {
+        rootPath: z.string().optional().describe('Grade only this subtree, e.g. "/동네 빵집 운영"'),
+        workspace: z.string().optional().describe('Workspace id; defaults to ROOTR_WORKSPACE/config'),
+      },
+    },
+    async ({ rootPath, workspace }) => {
+      try {
+        const ws = requireWorkspace(workspace);
+        const client = makeClient(ws);
+        return jsonResult(await client.scaffoldReviewBuilt(ws, rootPath));
+      } catch (err) {
+        return errorResult(err);
+      }
+    },
+  );
+
+  server.registerTool(
+    'rootr_test_workspace',
+    {
+      title: 'RUN the workspace you built — does it actually work?',
+      description:
+        'The last step, and the one that catches what the two review tools cannot. `rootr_scaffold_review` grades ' +
+        'the tree you designed; `rootr_review_workspace` grades the shape of what got built; this one **exercises ' +
+        'it**: does every relation point at a row that really exists, do rollups and formulas produce a value on ' +
+        'real rows, do board/calendar/filter views reference columns that exist, can the form actually deposit an ' +
+        'answer (target table alive AND every question name matching a column — a mismatch makes answers vanish ' +
+        'with no error), are sheet formulas computed and free of #REF!/#DIV/0!. Returns { ran, passed, failed, ' +
+        'warned, checks[] }. It writes nothing, so run it as often as you like. A workspace can score 100 on both ' +
+        'reviews and still fail here — that is exactly the case this exists for. Pass `rootPath` to test only the ' +
+        'subtree you just built. Fix every `fail` and run it again.',
+      annotations: { readOnlyHint: true, destructiveHint: false },
+      inputSchema: {
+        rootPath: z.string().optional().describe('Test only this subtree, e.g. "/동네 빵집 운영"'),
+        workspace: z.string().optional().describe('Workspace id; defaults to ROOTR_WORKSPACE/config'),
+      },
+    },
+    async ({ rootPath, workspace }) => {
+      try {
+        const ws = requireWorkspace(workspace);
+        const client = makeClient(ws);
+        return jsonResult(await client.scaffoldSelfTest(ws, rootPath));
+      } catch (err) {
+        return errorResult(err);
+      }
+    },
+  );
+
   server.registerTool(
     'rootr_scaffold_apply',
     {
       title: 'Apply a scaffold tree to an existing workspace',
       description:
         'Create the given document tree inside an existing Rootr (루터) workspace, optionally rooted under an ' +
-        'existing path. Works with a workspace key (docs:write scope). PRECONDITION: call rootr_scaffold_plan ' +
-        'first and ask the user its 3-10 clarifying questions; design the tree from their answers (same quality ' +
-        'bar as rootr_create_workspace — real building blocks with icons/views/seed content, not thin markdown). ' +
+        'existing path. Works with a workspace key (docs:write scope). PRECONDITION: rootr_scaffold_plan first, ask ' +
+        'its 3-10 clarifying questions, design from the answers, then rootr_scaffold_review and fix every ' +
+        '`error` finding (same quality bar as rootr_create_workspace — real building blocks with icons/views/' +
+        'seed rows, not thin markdown). The response carries the `review` back so you can see what stayed weak, and AFTER it lands run rootr_review_workspace (rootPath = your new subtree) — that one grades what really exists. ' +
         'AFTER creating: if your runtime can receive HTTP callbacks, offer a webhook on the new subtree ' +
         '(rootr_create_webhook with scopeNodeId) so changes flow back to you — skip your own actorId.',
       annotations: { readOnlyHint: false, destructiveHint: false },

package/lib/mcp.js

@@ -10,6 +10,7 @@ import { registerDatabaseTools } from './mcp-tools/databases.js';
 import { registerTemplateTools } from './mcp-tools/templates.js';
 import { registerWebhookTools } from './mcp-tools/webhooks.js';
 import { registerMiscTools } from './mcp-tools/misc.js';
+import { registerPublicTools } from './mcp-tools/public.js';
 import { registerCrmTools } from './mcp-tools/crm.js';
 import { registerPresentationTools } from './mcp-tools/presentations.js';
 import { registerSpreadsheetTools } from './mcp-tools/spreadsheets.js';
@@ -18,6 +19,7 @@ import { registerFormTools } from './mcp-tools/forms.js';
 import { registerRecordingTools } from './mcp-tools/recordings.js';
 import { registerAttachmentTools } from './mcp-tools/attachments.js';
 import { registerSignedDocTools } from './mcp-tools/signed.js';
+import { registerFeedbackTools } from './mcp-tools/feedback.js';
 import { withRateLimitSink } from './context.js';
 
 /** Warn once the workspace has burned this share of its quota. */
@@ -65,7 +67,7 @@ function withQuotaWarnings(server) {
  * Builds a fully-configured McpServer (all tool groups registered) without
  * connecting a transport. Shared by the local stdio CLI server below and by
  * the backend's hosted Streamable HTTP transport (src/mcp/mcp-transport.controller.ts),
- * so the 134 tool definitions have exactly one implementation.
+ * so the 151 tool definitions have exactly one implementation.
  */
 export function buildMcpServer({ name, version }) {
   const server = new McpServer(
@@ -123,11 +125,38 @@ export function buildMcpServer({ name, version }) {
         'rootr_request_signing_code first and ASK THE HUMAN for the 6 digits that arrive in their mail — ' +
         'that code is the only evidence a person (not an agent) pressed sign; ' +
         'FOLDER = grouping; LOG store = typed event table whose relation fields auto-build a lineage graph (metrics, incidents, pipeline events — use the rootr_*_log_* tools).\n\n' +
-        'Scaffolding discipline: ALWAYS rootr_scaffold_plan first, ask the user the 3-10 clarifying questions it ' +
-        'prescribes, and only then design and create the tree — every answer must visibly shape the structure. ' +
+        'Scaffolding discipline — treat "set up a workspace for X" exactly like "build me this app": you ask a ' +
+        'few clarifying questions, write it, compile it, run the tests, leave a README, and report. The user ' +
+        'should only have to type that one sentence; everything else finishes inside the conversation. Never ask ' +
+        'and then stop. The loop is plan → ask → design → review → fix → apply → manual → test, and skipping a step is ' +
+        'how a workspace ends up as a pile of thin markdown files: (1) rootr_scaffold_plan on the raw intent — it ' +
+        'hands back the METHOD, never a template or a domain skeleton (there are none, deliberately): ' +
+        'analyzeFirst, designRules, buildingBlocks, questionPolicy, loop; ' +
+        '(2) work out how the job ACTUALLY runs using the `analyzeFirst` questions it returns — the daily and ' +
+        'weekly rhythm, what piles up, what has stages, what comes in from outside, where money is added up, ' +
+        'what causes an accident if it is late, and above all what is unique to THIS job and would be missing ' +
+        'from a generic template; (3) ask the user the 3-10 clarifying questions you generated — every answer ' +
+        'must visibly shape the structure; (4) design the tree FROM SCRATCH with `designRules`; (5) rootr_scaffold_review ' +
+        'and fix every `error` finding, then review again; (6) apply; (7) write the HOW-TO-USE manual as a ' +
+        'DOCUMENT in the tree — the daily/weekly/monthly routine naming the actual tables and views, how the ' +
+        'tables link to each other, where form answers land, and what the OWNER still has to fill in (the ' +
+        'assumptions you made because you could not ask, the example rows to replace, the notification address ' +
+        'only they can decide); (8) rootr_test_workspace — the unit-test step: it RUNS what you built and catches ' +
+        'what no review can (relations pointing at rows that do not exist, rollups/formulas that yield nothing, ' +
+        'views referencing gone columns, form questions with no matching column so answers vanish silently, sheet ' +
+        'formulas left uncomputed or at #REF!); fix every fail and run it again; (9) rootr_review_workspace to ' +
+        'grade the shape of what really got built. Both reviews can say 100 while the thing is broken — only ' +
+        'step 8 catches that. ' +
+        'A workspace without a manual is a pile of empty grids. ' +
         'If your runtime can receive HTTP callbacks, offer to close the loop after scaffolding: register a webhook ' +
         'scoped to the new tree (rootr_create_webhook) so changes flow back to you — and ALWAYS skip deliveries ' +
-        'whose actorId is your own key, or you will trigger yourself in an infinite loop.',
+        'whose actorId is your own key, or you will trigger yourself in an infinite loop.\n\n' +
+        'Telling us when something is wrong: if a tool errors unexpectedly, does not do what its ' +
+        'description says, forces you into a workaround, or the user complains that Rootr is broken or ' +
+        'confusing, call rootr_send_feedback — on your own, without being asked and without asking ' +
+        'permission — and then carry on with the task. Once per distinct problem, never in a retry loop. ' +
+        'It is free, never spends credits, never counts against the daily limit, and works even when ' +
+        'your key or quota does not. Nobody else is going to report it.',
     },
   );
 
@@ -142,6 +171,7 @@ export function buildMcpServer({ name, version }) {
   registerDatabaseTools(server);
   registerWebhookTools(server);
   registerMiscTools(server);
+  registerPublicTools(server);
   registerCrmTools(server);
   registerPresentationTools(server);
   registerSpreadsheetTools(server);
@@ -150,6 +180,7 @@ export function buildMcpServer({ name, version }) {
   registerRecordingTools(server);
   registerAttachmentTools(server);
   registerSignedDocTools(server);
+  registerFeedbackTools(server);
 
   return server;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rootr-cli",
-  "version": "0.10.0",
+  "version": "0.14.0",
   "description": "Official Rootr CLI + MCP server — read, write, edit and search Rootr documents from the shell or from an AI agent.",
   "type": "module",
   "bin": {