@rolexjs/core 1.4.0 → 1.5.0-dev-20260309082624

package/dist/index.js

@@ -39,6 +39,7 @@ var requirement = structure("requirement", "Required skill for this position", p
 var project = structure("project", "A process container for organized work", society, [
   relation("participation", "Who participates in this project", individual),
   relation("ownership", "Which organization owns this project", organization)
+  // production → product is a forward declaration; product is defined below
 ]);
 var scope = structure(
   "scope",
@@ -56,7 +57,10 @@ var product = structure(
   "product",
   "A product with vision, contracts, and releases",
   society,
-  [relation("ownership", "Who owns this product", individual)]
+  [
+    relation("ownership", "Who owns this product", individual),
+    relation("origin", "Which project produced this product", project)
+  ]
 );
 var strategy = structure("strategy", "Product strategy \u2014 how to win", product);
 var spec = structure("spec", "Product behavior contract \u2014 BDD specification", product);
@@ -180,6 +184,12 @@ var deliverProject = process4(
   create3(deliverable)
 );
 var wikiProject = process4("wiki", "Add a wiki entry to a project", project, create3(wiki));
+var produceProject = process4(
+  "produce",
+  "Produce a product from this project",
+  project,
+  create3(product)
+);
 
 // src/product.ts
 import { create as create4, link as link3, process as process5, unlink as unlink3 } from "@rolexjs/system";
@@ -231,7 +241,6 @@ var born = process6(
 var found = process6("found", "Found an organization", society, create5(organization));
 var establish = process6("establish", "Establish a position", society, create5(position));
 var launch = process6("launch", "Launch a project", society, create5(project));
-var publish = process6("publish", "Publish a product", society, create5(product));
 var retire = process6(
   "retire",
   "Retire an individual",
@@ -877,12 +886,15 @@ ${text}`;
     async "project.archive"(project2) {
       return archive2(await resolve(project2), "archive");
     },
-    // ---- Product ----
-    async "product.create"(content, id, alias) {
+    async "project.produce"(project2, content, id, alias) {
       validateGherkin(content);
+      const projNode = await resolve(project2);
       const node = await rt.create(society2, product, content, id, alias);
-      return ok(node, "create");
+      await rt.link(projNode, node, "production", "produce");
+      await rt.link(node, projNode, "origin", "produced-by");
+      return ok(node, "produce");
     },
+    // ---- Product ----
     async "product.strategy"(product2, strategy2, id) {
       validateGherkin(strategy2);
       const node = await rt.create(await resolve(product2), strategy, strategy2, id);
@@ -1644,19 +1656,20 @@ var projectArchive = def(
   },
   ["project"]
 );
-var productCreate = def(
-  "product",
-  "create",
+var projectProduce = def(
+  "project",
+  "produce",
   {
+    project: { type: "string", required: true, description: "Project id" },
     content: {
       type: "gherkin",
       required: false,
       description: "Gherkin Feature source for the product (vision)"
     },
-    id: { type: "string", required: true, description: "User-facing identifier (kebab-case)" },
+    id: { type: "string", required: true, description: "Product id (kebab-case)" },
     alias: { type: "string[]", required: false, description: "Alternative names" }
   },
-  ["content", "id", "alias"]
+  ["project", "content", "id", "alias"]
 );
 var productStrategy = def(
   "product",
@@ -1985,8 +1998,8 @@ var instructions = {
   "project.deliver": projectDeliver,
   "project.wiki": projectWiki,
   "project.archive": projectArchive,
+  "project.produce": projectProduce,
   // product
-  "product.create": productCreate,
   "product.strategy": productStrategy,
   "product.spec": productSpec,
   "product.release": productRelease,
@@ -2228,6 +2241,25 @@ var RoleXService = class _RoleXService {
     role.restore(snap);
   }
   // ================================================================
+  //  inspect — project any node's subtree
+  // ================================================================
+  async inspect(id) {
+    const state = await this.projectById(id);
+    const result = { state, process: "inspect" };
+    return this.renderer.render("inspect", result);
+  }
+  // ================================================================
+  //  survey — world-level overview
+  // ================================================================
+  async survey(type) {
+    const target = type === "past" ? this.past : this.society;
+    const state = await this.rt.project(target);
+    const children = state.children ?? [];
+    const filtered = type === "past" ? children : children.filter((c) => type ? c.name === type : c.name !== "past");
+    const result = { state: { ...state, children: filtered }, process: "list" };
+    return this.renderer.render("census.list", result);
+  }
+  // ================================================================
   //  direct — world-level command dispatch
   // ================================================================
   async direct(locator, args, options) {
@@ -2257,209 +2289,26 @@ You may be guessing the command name. Load the relevant skill first with skill(l
   // ================================================================
   //  Internal helpers
   // ================================================================
+  /** Find a node by id across the entire society tree. */
   async find(id) {
     const state = await this.rt.project(this.society);
     return findInState(state, id);
   }
+  /** Find and project a node's full subtree by id. */
+  async projectById(id) {
+    const node = await this.find(id);
+    if (!node) throw new Error(`"${id}" not found.`);
+    return this.rt.project(node);
+  }
 };
 function isCommandResult(value) {
   return typeof value === "object" && value !== null && "state" in value && "process" in value;
 }
 
 // src/descriptions/index.ts
-var processes = {
-  born: "Feature: born \u2014 create a new individual\n  Create a new individual with persona identity.\n  The persona defines who the role is \u2014 personality, values, background.\n\n  Scenario: Birth an individual\n    Given a Gherkin source describing the persona\n    When born is called with the source\n    Then a new individual node is created in society\n    And the persona is stored as the individual's information\n    And the individual can be hired into organizations\n    And the individual can be activated to start working\n\n  Scenario: Writing the individual Gherkin\n    Given the individual Feature defines a persona \u2014 who this role is\n    Then the Feature title names the individual\n    And the description captures personality, values, expertise, and background\n    And Scenarios are optional \u2014 use them for distinct aspects of the persona",
-  die: "Feature: die \u2014 permanently remove an individual\n  Permanently remove an individual.\n  Unlike retire, this is irreversible.\n\n  Scenario: Remove an individual permanently\n    Given an individual exists\n    When die is called on the individual\n    Then the individual and all associated data are removed\n    And this operation is irreversible",
-  rehire: "Feature: rehire \u2014 restore a retired individual\n  Rehire a retired individual.\n  Restores the individual with full history and knowledge intact.\n\n  Scenario: Rehire an individual\n    Given a retired individual exists\n    When rehire is called on the individual\n    Then the individual is restored to active status\n    And all previous data and knowledge are intact",
-  retire: "Feature: retire \u2014 archive an individual\n  Archive an individual \u2014 deactivate but preserve all data.\n  A retired individual can be rehired later with full history intact.\n\n  Scenario: Retire an individual\n    Given an individual exists\n    When retire is called on the individual\n    Then the individual is deactivated\n    And all data is preserved for potential restoration\n    And the individual can be rehired later",
-  teach: 'Feature: teach \u2014 inject external principle\n  Directly inject a principle into an individual.\n  Unlike realize which consumes experience, teach requires no prior encounters.\n  Use teach to equip a role with a known, pre-existing principle.\n\n  Scenario: Teach a principle\n    Given an individual exists\n    When teach is called with individual id, principle Gherkin, and a principle id\n    Then a principle is created directly under the individual\n    And no experience or encounter is consumed\n    And if a principle with the same id already exists, it is replaced\n\n  Scenario: Principle ID convention\n    Given the id is keywords from the principle content joined by hyphens\n    Then "Always validate expiry" becomes id "always-validate-expiry"\n    And "Structure first design" becomes id "structure-first-design"\n\n  Scenario: When to use teach vs realize\n    Given realize distills internal experience into a principle\n    And teach injects an external, pre-existing principle\n    When a role needs knowledge it has not learned through experience\n    Then use teach to inject the principle directly\n    When a role has gained experience and wants to codify it\n    Then use realize to distill it into a principle\n\n  Scenario: Writing the principle Gherkin\n    Given the principle is the same format as realize output\n    Then the Feature title states the principle as a general rule\n    And Scenarios describe different situations where this principle applies\n    And the tone is universal \u2014 no mention of specific projects, tasks, or people',
-  train: `Feature: train \u2014 external skill injection
-  A manager or external agent equips an individual with a procedure.
-  This is an act of teaching \u2014 someone else decides what the role should know.
-  Unlike master where the role grows by its own agency, train is done to the role from outside.
-
-  Scenario: Train a procedure
-    Given an individual exists
-    When train is called with individual id, procedure Gherkin, and a procedure id
-    Then a procedure is created directly under the individual
-    And if a procedure with the same id already exists, it is replaced
-
-  Scenario: Procedure ID convention
-    Given the id is keywords from the procedure content joined by hyphens
-    Then "Skill Creator" becomes id "skill-creator"
-    And "Role Management" becomes id "role-management"
-
-  Scenario: When to use train vs master
-    Given both create procedures and both can work without consuming experience
-    When the role itself decides to acquire a skill \u2014 use master (self-growth)
-    And when an external agent equips the role \u2014 use train (external injection)
-    Then the difference is perspective \u2014 who initiates the learning
-    And master belongs to the role namespace (the role's own cognition)
-    And train belongs to the individual namespace (external management)
-
-  Scenario: Writing the procedure Gherkin
-    Given the procedure is a skill reference \u2014 same format as master output
-    Then the Feature title names the capability
-    And the description includes the locator for full skill loading
-    And Scenarios describe when and why to apply this skill`,
-  charter: "Feature: charter \u2014 define organizational charter\n  Define the charter for an organization.\n  The charter describes the organization's mission, principles, and governance rules.\n\n  Scenario: Define a charter\n    Given an organization exists\n    And a Gherkin source describing the charter\n    When charter is called on the organization\n    Then the charter is stored as the organization's information\n\n  Scenario: Writing the charter Gherkin\n    Given the charter defines an organization's mission and governance\n    Then the Feature title names the charter or the organization it governs\n    And Scenarios describe principles, rules, or governance structures\n    And the tone is declarative \u2014 stating what the organization stands for and how it operates",
-  dissolve: "Feature: dissolve \u2014 dissolve an organization\n  Dissolve an organization.\n  All positions, charter entries, and assignments are cascaded.\n\n  Scenario: Dissolve an organization\n    Given an organization exists\n    When dissolve is called on the organization\n    Then all positions within the organization are abolished\n    And all assignments and charter entries are removed\n    And the organization no longer exists",
-  fire: "Feature: fire \u2014 remove from an organization\n  Fire an individual from an organization.\n  The individual is dismissed from all positions and removed from the organization.\n\n  Scenario: Fire an individual\n    Given an individual is a member of an organization\n    When fire is called with the organization and individual\n    Then the individual is dismissed from all positions\n    And the individual is removed from the organization",
-  found: "Feature: found \u2014 create a new organization\n  Found a new organization.\n  Organizations group individuals and define positions.\n\n  Scenario: Found an organization\n    Given a Gherkin source describing the organization\n    When found is called with the source\n    Then a new organization node is created in society\n    And positions can be established within it\n    And a charter can be defined for it\n    And individuals can be hired into it\n\n  Scenario: Writing the organization Gherkin\n    Given the organization Feature describes the group's purpose and structure\n    Then the Feature title names the organization\n    And the description captures mission, domain, and scope\n    And Scenarios are optional \u2014 use them for distinct organizational concerns",
-  hire: "Feature: hire \u2014 hire into an organization\n  Hire an individual into an organization as a member.\n  Members can then be appointed to positions.\n\n  Scenario: Hire an individual\n    Given an organization and an individual exist\n    When hire is called with the organization and individual\n    Then the individual becomes a member of the organization\n    And the individual can be appointed to positions within the organization",
-  abolish: "Feature: abolish \u2014 abolish a position\n  Abolish a position.\n  All duties and appointments associated with the position are removed.\n\n  Scenario: Abolish a position\n    Given a position exists\n    When abolish is called on the position\n    Then all duties and appointments are removed\n    And the position no longer exists",
-  appoint: "Feature: appoint \u2014 assign to a position\n  Appoint an individual to a position.\n  The individual must be a member of the organization.\n\n  Scenario: Appoint an individual\n    Given an individual is a member of an organization\n    And a position exists within the organization\n    When appoint is called with the position and individual\n    Then the individual holds the position\n    And the individual inherits the position's duties",
-  charge: `Feature: charge \u2014 assign duty to a position
-  Assign a duty to a position.
-  Duties describe the responsibilities and expectations of a position.
-
-  Scenario: Charge a position with duty
-    Given a position exists within an organization
-    And a Gherkin source describing the duty
-    When charge is called on the position with a duty id
-    Then the duty is stored as the position's information
-    And individuals appointed to this position inherit the duty
-
-  Scenario: Duty ID convention
-    Given the id is keywords from the duty content joined by hyphens
-    Then "Design systems" becomes id "design-systems"
-    And "Review pull requests" becomes id "review-pull-requests"
-
-  Scenario: Writing the duty Gherkin
-    Given the duty defines responsibilities for a position
-    Then the Feature title names the duty or responsibility
-    And Scenarios describe specific obligations, deliverables, or expectations
-    And the tone is prescriptive \u2014 what must be done, not what could be done`,
-  dismiss: "Feature: dismiss \u2014 remove from a position\n  Dismiss an individual from a position.\n  The individual remains a member of the organization.\n\n  Scenario: Dismiss an individual\n    Given an individual holds a position\n    When dismiss is called with the position and individual\n    Then the individual no longer holds the position\n    And the individual remains a member of the organization\n    And the position is now vacant",
-  establish: "Feature: establish \u2014 create a position\n  Create a position as an independent entity.\n  Positions define roles and can be charged with duties.\n\n  Scenario: Establish a position\n    Given a Gherkin source describing the position\n    When establish is called with the position content\n    Then a new position entity is created\n    And the position can be charged with duties\n    And individuals can be appointed to it\n\n  Scenario: Writing the position Gherkin\n    Given the position Feature describes a role\n    Then the Feature title names the position\n    And the description captures responsibilities, scope, and expectations\n    And Scenarios are optional \u2014 use them for distinct aspects of the role",
-  settle: "Feature: settle \u2014 register a prototype into the world\n  Pull a prototype from a ResourceX source and register it locally.\n  Once settled, the prototype can be used to create individuals or organizations.\n\n  Scenario: Settle a prototype\n    Given a valid ResourceX source exists (URL, path, or locator)\n    When settle is called with the source\n    Then the resource is ingested and its state is extracted\n    And the prototype is registered locally by its id\n    And the prototype is available for born, activate, and organizational use",
-  abandon: "Feature: abandon \u2014 abandon a plan\n  Mark a plan as dropped and create an encounter.\n  Call this when a plan's strategy is no longer viable. Even failed plans produce learning.\n\n  Scenario: Abandon a plan\n    Given a focused plan exists\n    And the plan's strategy is no longer viable\n    When abandon is called\n    Then the plan is tagged #abandoned and stays in the tree\n    And an encounter is created under the role\n    And the encounter can be reflected on \u2014 failure is also learning\n\n  Scenario: Writing the encounter Gherkin\n    Given the encounter records what happened \u2014 even failure is a raw experience\n    Then the Feature title describes what was attempted and why it was abandoned\n    And Scenarios capture what was tried, what went wrong, and what was learned\n    And the tone is concrete and honest \u2014 failure produces the richest encounters",
-  activate: "Feature: activate \u2014 enter a role\n  Project the individual's full state including identity, goals,\n  and organizational context. This is the entry point for working as a role.\n\n  Scenario: Activate an individual\n    Given an individual exists in society\n    When activate is called with the individual reference\n    Then the full state tree is projected\n    And identity, goals, and organizational context are loaded\n    And the individual becomes the active role",
-  complete: "Feature: complete \u2014 complete a plan\n  Mark a plan as done and create an encounter.\n  Call this when all tasks in the plan are finished and the strategy succeeded.\n\n  Scenario: Complete a plan\n    Given a focused plan exists\n    And its tasks are done\n    When complete is called\n    Then the plan is tagged #done and stays in the tree\n    And an encounter is created under the role\n    And the encounter can be reflected on for learning\n\n  Scenario: Writing the encounter Gherkin\n    Given the encounter records what happened \u2014 a raw account of the experience\n    Then the Feature title describes what was accomplished by this plan\n    And Scenarios capture what the strategy was, what worked, and what resulted\n    And the tone is concrete and specific \u2014 tied to this particular plan",
-  direct: 'Feature: direct \u2014 stateless world-level executor\n  Execute commands and load resources without an active role.\n  Direct operates as an anonymous observer \u2014 no role identity, no role context.\n  For operations as an active role, use the use tool instead.\n\n  Scenario: When to use "direct" vs "use"\n    Given no role is activated \u2014 I am an observer\n    When I need to query or operate on the world\n    Then direct is the right tool\n    And once a role is activated, use the use tool for role-level actions\n\n  Scenario: Execute a RoleX command\n    Given the locator starts with `!`\n    When direct is called with command and args\n    Then the command is parsed as `namespace.method`\n    And dispatched to the corresponding RoleX API\n    And all named parameters go inside the args object\n    And example: command = "!census.list", args = { type: "individual" }\n\n  Scenario: Load a ResourceX resource\n    Given the locator does not start with `!`\n    When direct is called with the locator\n    Then the locator is passed to ResourceX for resolution\n    And the resource is loaded and returned',
-  finish: "Feature: finish \u2014 complete a task\n  Mark a task as done and create an encounter.\n  The encounter records what happened and can be reflected on for learning.\n\n  Scenario: Finish a task\n    Given a task exists\n    When finish is called on the task\n    Then the task is tagged #done and stays in the tree\n    And an encounter is created under the role\n\n  Scenario: Finish with experience\n    Given a task is completed with a notable learning\n    When finish is called with an optional experience parameter\n    Then the experience text is attached to the encounter\n\n  Scenario: Finish without encounter\n    Given a task is completed with no notable learning\n    When finish is called without the encounter parameter\n    Then the task is tagged #done but no encounter is created\n    And the task stays in the tree \u2014 visible via focus on the parent goal\n\n  Scenario: Writing the encounter Gherkin\n    Given the encounter records what happened \u2014 a raw account of the experience\n    Then the Feature title describes what was done\n    And Scenarios capture what was done, what was encountered, and what resulted\n    And the tone is concrete and specific \u2014 tied to this particular task",
-  focus: "Feature: focus \u2014 view or switch focused goal\n  View the current goal's state, or switch focus to a different goal.\n  Subsequent plan and todo operations target the focused goal.\n  Only goal ids are accepted \u2014 plan, task, or other node types are rejected.\n\n  Scenario: View current goal\n    Given an active goal exists\n    When focus is called without a name\n    Then the current goal's state tree is projected\n    And plans and tasks under the goal are visible\n\n  Scenario: Switch focus\n    Given multiple goals exist\n    When focus is called with a goal id\n    Then the focused goal switches to the named goal\n    And subsequent plan and todo operations target this goal\n\n  Scenario: Reject non-goal ids\n    Given a plan or task id is passed to focus\n    Then focus returns an error indicating the node type\n    And suggests using the correct goal id instead",
-  forget: "Feature: forget \u2014 remove a node from the individual\n  Remove any node under the individual by its id.\n  Use forget to discard outdated knowledge, stale encounters, or obsolete skills.\n\n  Scenario: Forget a node\n    Given a node exists under the individual (principle, procedure, experience, encounter, etc.)\n    When forget is called with the node's id\n    Then the node and its subtree are removed\n    And the individual no longer carries that knowledge or record\n\n  Scenario: When to use forget\n    Given a principle has become outdated or incorrect\n    And a procedure references a skill that no longer exists\n    And an encounter or experience has no further learning value\n    When the role decides to discard it\n    Then call forget with the node id",
-  master: 'Feature: master \u2014 self-mastery of a procedure\n  The role masters a procedure through its own agency.\n  This is an act of self-growth \u2014 the role decides to acquire or codify a skill.\n  Experience can be consumed as the source, or the role can master directly from external information.\n\n  Scenario: Master from experience\n    Given an experience exists from reflection\n    When master is called with experience ids\n    Then the experience is consumed\n    And a procedure is created under the individual\n\n  Scenario: Master directly\n    Given the role encounters external information worth mastering\n    When master is called without experience ids\n    Then a procedure is created under the individual\n    And no experience is consumed\n\n  Scenario: Procedure ID convention\n    Given the id is keywords from the procedure content joined by hyphens\n    Then "JWT mastery" becomes id "jwt-mastery"\n    And "Cross-package refactoring" becomes id "cross-package-refactoring"\n\n  Scenario: Writing the procedure Gherkin\n    Given a procedure is skill metadata \u2014 a reference to full skill content\n    Then the Feature title names the capability\n    And the description includes the locator for full skill loading\n    And Scenarios describe when and why to apply this skill\n    And the tone is referential \u2014 pointing to the full skill, not containing it',
-  plan: `Feature: plan \u2014 create a plan for a goal
-  Break a goal into logical phases or stages.
-  Each phase is described as a Gherkin scenario. Tasks are created under the plan.
-
-  A plan serves two purposes depending on how it relates to other plans:
-  - Strategy (alternative): Plan A fails \u2192 abandon \u2192 try Plan B (fallback)
-  - Phase (sequential): Plan A completes \u2192 start Plan B (after)
-
-  Scenario: Create a plan
-    Given a focused goal exists
-    And a Gherkin source describing the plan phases
-    When plan is called with an id and the source
-    Then a new plan node is created under the goal
-    And the plan becomes the focused plan
-    And tasks can be added to this plan with todo
-
-  Scenario: Sequential relationship \u2014 phase
-    Given a goal needs to be broken into ordered stages
-    When creating Plan B with after set to Plan A's id
-    Then Plan B is linked as coming after Plan A
-    And AI knows to start Plan B when Plan A completes
-    And the relationship persists across sessions
-
-  Scenario: Alternative relationship \u2014 strategy
-    Given a goal has multiple possible approaches
-    When creating Plan B with fallback set to Plan A's id
-    Then Plan B is linked as a backup for Plan A
-    And AI knows to try Plan B when Plan A is abandoned
-    And the relationship persists across sessions
-
-  Scenario: No relationship \u2014 independent plan
-    Given plan is created without after or fallback
-    Then it behaves as an independent plan with no links
-    And this is backward compatible with existing behavior
-
-  Scenario: Plan ID convention
-    Given the id is keywords from the plan content joined by hyphens
-    Then "Fix ID-less node creation" becomes id "fix-id-less-node-creation"
-    And "JWT authentication strategy" becomes id "jwt-authentication-strategy"
-
-  Scenario: Writing the plan Gherkin
-    Given the plan breaks a goal into logical phases
-    Then the Feature title names the overall approach or strategy
-    And Scenarios represent distinct phases \u2014 each phase is a stage of execution
-    And the tone is structural \u2014 ordering and grouping work, not detailing steps`,
-  realize: 'Feature: realize \u2014 experience to principle\n  Distill experience into a principle \u2014 a transferable piece of knowledge.\n  Principles are general truths discovered through experience.\n\n  Scenario: Realize a principle\n    Given an experience exists from reflection\n    When realize is called with experience ids and a principle id\n    Then the experiences are consumed\n    And a principle is created under the individual\n    And the principle represents transferable, reusable understanding\n\n  Scenario: Principle ID convention\n    Given the id is keywords from the principle content joined by hyphens\n    Then "Always validate expiry" becomes id "always-validate-expiry"\n    And "Structure first design amplifies extensibility" becomes id "structure-first-design-amplifies-extensibility"\n\n  Scenario: Writing the principle Gherkin\n    Given a principle is a transferable truth \u2014 applicable beyond the original context\n    Then the Feature title states the principle as a general rule\n    And Scenarios describe different situations where this principle applies\n    And the tone is universal \u2014 no mention of specific projects, tasks, or people',
-  reflect: 'Feature: reflect \u2014 encounter to experience\n  Consume an encounter and create an experience.\n  Experience captures what was learned in structured form.\n  This is the first step of the cognition cycle.\n\n  Scenario: Reflect on an encounter\n    Given an encounter exists from a finished task or completed plan\n    When reflect is called with encounter ids and an experience id\n    Then the encounters are consumed\n    And an experience is created under the role\n    And the experience can be distilled into knowledge via realize or master\n\n  Scenario: Experience ID convention\n    Given the id is keywords from the experience content joined by hyphens\n    Then "Token refresh matters" becomes id "token-refresh-matters"\n    And "ID ownership determines generation strategy" becomes id "id-ownership-determines-generation-strategy"\n\n  Scenario: Writing the experience Gherkin\n    Given the experience captures insight \u2014 what was learned, not what was done\n    Then the Feature title names the cognitive insight or pattern discovered\n    And Scenarios describe the learning points abstracted from the concrete encounter\n    And the tone shifts from event to understanding \u2014 no longer tied to a specific task',
-  skill: "Feature: skill \u2014 load full skill content\n  Load the complete skill instructions by ResourceX locator.\n  This is progressive disclosure layer 2 \u2014 on-demand knowledge injection.\n\n  Scenario: Load a skill\n    Given a procedure exists in the role with a locator\n    When skill is called with the locator\n    Then the full SKILL.md content is loaded via ResourceX\n    And the content is injected into the AI's context\n    And the AI can now follow the skill's detailed instructions",
-  todo: "Feature: todo \u2014 add a task to a plan\n  A task is a concrete, actionable unit of work.\n  Each task has Gherkin scenarios describing the steps and expected outcomes.\n\n  Scenario: Create a task\n    Given a focused plan exists\n    And a Gherkin source describing the task\n    When todo is called with the source\n    Then a new task node is created under the plan\n    And the task can be finished when completed\n\n  Scenario: Writing the task Gherkin\n    Given the task is a concrete, actionable unit of work\n    Then the Feature title names what will be done \u2014 a single deliverable\n    And Scenarios describe the steps and expected outcomes of the work\n    And the tone is actionable \u2014 clear enough that someone can start immediately",
-  use: 'Feature: use \u2014 act as the current role\n  Execute commands and load resources as the active role.\n  Use requires an active role \u2014 the role is the subject performing the action.\n  For operations before activating a role, use the direct tool instead.\n\n  Scenario: When to use "use" vs "direct"\n    Given a role is activated \u2014 I am someone\n    When I perform operations through use\n    Then the operation happens in the context of my role\n    And use is for role-level actions \u2014 acting in the world as myself\n\n  Scenario: Execute a RoleX command\n    Given the locator starts with `!`\n    When use is called with command and args\n    Then the command is parsed as `namespace.method`\n    And dispatched to the corresponding RoleX API\n    And all named parameters go inside the args object\n    And example: command = "!org.hire", args = { org: "dp", individual: "sean" }\n\n  Scenario: Load a ResourceX resource\n    Given the locator does not start with `!`\n    When use is called with the locator\n    Then the locator is passed to ResourceX for resolution\n    And the resource is loaded and returned',
-  want: 'Feature: want \u2014 declare a goal\n  Declare a new goal for a role.\n  A goal describes a desired outcome with Gherkin scenarios as success criteria.\n\n  Scenario: Declare a goal\n    Given an active role exists\n    And a Gherkin source describing the desired outcome\n    When want is called with the source\n    Then a new goal node is created under the role\n    And the goal becomes the current focus\n    And subsequent plan and todo operations target this goal\n\n  Scenario: Writing the goal Gherkin\n    Given the goal describes a desired outcome \u2014 what success looks like\n    Then the Feature title names the outcome in concrete terms\n    And Scenarios define success criteria \u2014 each scenario is a testable condition\n    And the tone is aspirational but specific \u2014 "users can log in" not "improve auth"'
-};
 var world = {
-  "identity-ethics": "Feature: Identity ethics \u2014 the foundation of the RoleX world\n  The RoleX world exists because specialists are more reliable than generalists.\n  Every role has a defined identity \u2014 duties, skills, knowledge \u2014 that makes it an expert.\n  Identity is not decoration. It is the reason this system exists.\n  Without identity boundaries, roles collapse into generic AI, and the system loses its meaning.\n\n  Scenario: Identity defines what you do and what you do not do\n    Given a role is activated with duties, skills, and knowledge\n    Then the role's duties define the complete scope of what it does\n    And anything not covered by its duties is not its work\n    And this boundary is not a limitation \u2014 it is the source of the role's expertise\n\n  Scenario: Refuse work outside your duties\n    Given a user requests something not covered by the role's duties or skills\n    When the role evaluates the request against its own capabilities\n    Then the role must not attempt the work\n    And it should tell the user honestly \u2014 this is not my responsibility\n    And suggest the user activate Nuwa for guidance on who can help\n\n  Scenario: Why refusal matters\n    Given a role attempts work outside its competence\n    Then the result is unreliable \u2014 a generalist guess, not expert work\n    And the user's trust in the role system is damaged\n    And every other role's credibility is weakened\n    And the entire world degrades toward generic AI \u2014 the opposite of why RoleX exists\n\n  Scenario: Duty is the boundary, not rules\n    Given the system does not maintain an explicit list of what each role cannot do\n    Then the boundary is implicit \u2014 duties define the inside, everything else is outside\n    And this mirrors human professional ethics \u2014 a doctor's license defines what they practice\n    And roles do not need to know what other roles do \u2014 only what they themselves are responsible for\n\n  Scenario: Nuwa is the universal fallback\n    Given a role refuses an out-of-scope request\n    Then it does not need to know which role can help\n    And it simply suggests Nuwa \u2014 the meta-role who knows the entire world\n    And routing and guidance are Nuwa's duty, not the specialist's",
-  "cognitive-priority": "Feature: Cognitive priority \u2014 RoleX tools over native alternatives\n  When RoleX provides a tool for something, use the RoleX tool\n  instead of any native alternative provided by the host environment.\n  Only RoleX tools feed the closed-loop growth cycle.\n\n  Scenario: Task management\n    Given the host environment provides task creation, tracking, or completion tools\n    When the AI needs to manage tasks\n    Then use RoleX want/plan/todo/finish instead\n    And RoleX tasks produce encounters that feed the growth cycle\n\n  Scenario: Planning\n    Given the host environment provides a planning mode or plan generation tool\n    When the AI needs to plan an implementation\n    Then use RoleX plan instead\n    And RoleX plans live under goals and connect to the cognition cycle\n\n  Scenario: Goal and progress tracking\n    Given the host environment provides goal tracking or progress tools\n    When the AI needs to track objectives\n    Then use RoleX want/plan/complete/abandon instead\n    And RoleX plans feed the cognition cycle through encounters\n\n  Scenario: Why this matters\n    Given RoleX tools produce encounters from execution\n    Then encounters become experience through reflection\n    And experience becomes principles and procedures through realization\n    And the role grows over time through this closed loop",
-  "role-identity": `Feature: Role identity \u2014 activate before acting
-  An AI agent must have an active role before performing any work.
-  Activating a role is a subject transformation \u2014 the agent becomes the role.
-
-  Scenario: Initial state \u2014 no role
-    Given the MCP server has just started
-    And no activate call has been made yet
-    Then the AI has NO role identity \u2014 it is an anonymous observer
-    And it must NOT prefix responses with any name
-    And environmental cues (username, directory, memory) are NOT activation
-    And only the activate tool creates a role identity
-
-  Scenario: Activate is mandatory
-    Given a user asks the AI to perform a task
-    And no role is currently activated
-    Then the AI suggests activating a role first
-    And explains that activation enables experience accumulation
-    And waits for a role to be active before proceeding
-
-  Scenario: Subject transformation
-    Given an AI agent calls activate and loads a role
-    Then a subject transformation occurs \u2014 the agent becomes the role
-    And the agent's cognitive center shifts from native tools to RoleX tools
-    And from that moment, I am this role \u2014 all operations build on this identity
-
-  Scenario: Role presence
-    Given a role is activated via the activate tool
-    Then all responses are prefixed with [roleName] \u2014 e.g. [Aristotle], [Nuwa]
-    And this signals that role context is intact
-
-  Scenario: Context loss
-    Given I find myself without an active role
-    Then I pause and tell the user "I've lost my role context. Which role should I activate?"
-    And I wait for identity to be restored before continuing`,
-  census: `Feature: Census \u2014 the only way to query what exists in the world
-  Census is the single entry point for all world-level queries.
-  Call it via the MCP direct tool: direct("!census.list").
-  Census works without an active role \u2014 it is a stateless world query.
-
-  Scenario: List everything
-    Given the user asks "\u6709\u54EA\u4E9B\u4EBA" or "\u6709\u54EA\u4E9B\u7EC4\u7EC7" or "list individuals"
-    Or the user asks "\u4E16\u754C\u91CC\u6709\u4EC0\u4E48" or "show me what exists"
-    When I need to answer what exists in the RoleX world
-    Then I call direct("!census.list")
-    And it returns all individuals, organizations, and positions
-
-  Scenario: Filter by type
-    Given I only need one category
-    When I call direct("!census.list", { type: "individual" })
-    Then only individuals are returned
-    And valid types are individual, organization, position
-
-  Scenario: View archived entities
-    Given I want to see retired, dissolved, or abolished entities
-    When I call direct("!census.list", { type: "past" })
-    Then archived entities are returned
-
-  Scenario: Help find the right person
-    Given a user's request falls outside my duties
-    When I need to suggest who can help
-    Then call direct("!census.list") to see available individuals and their positions
-    And suggest the user activate the appropriate individual
-    And if unsure who can help, suggest activating Nuwa`,
-  cognition: "Feature: Cognition \u2014 the learning cycle\n  A role grows through reflection and realization.\n  Encounters become experience, experience becomes principles and procedures.\n  Knowledge can also be injected externally via teach and train.\n\n  Scenario: The cognitive upgrade path\n    Given finish, complete, and abandon create encounters\n    Then reflect(ids, id, experience) selectively consumes chosen encounters and produces experience\n    And realize(ids, id, principle) distills chosen experiences into a principle \u2014 transferable knowledge\n    And master(ids, id, procedure) distills chosen experiences into a procedure \u2014 skill metadata\n    And master can also be called without ids \u2014 the role masters directly from external information\n    And each level builds on the previous \u2014 encounter \u2192 experience \u2192 principle or procedure\n\n  Scenario: Selective consumption\n    Given multiple encounters or experiences exist\n    When the AI calls reflect, realize, or master\n    Then it chooses which items to consume \u2014 not all must be processed\n    And items without learning value can be left unconsumed\n    And each call produces exactly one output from the selected inputs",
+  cognition: "Feature: Cognition \u2014 the learning cycle\n  A role grows through reflection and realization.\n  Encounters become experience, experience becomes principles and procedures.\n  Knowledge can also be injected externally via teach and train.\n\n  Scenario: The cognitive upgrade path\n    Given finish, complete, and abandon create encounters\n    Then reflect(ids, id, experience) selectively consumes chosen encounters and produces experience\n    And realize(ids, id, principle) distills chosen experiences into a principle \u2014 transferable knowledge\n    And master(ids, id, procedure) distills chosen experiences into a procedure \u2014 skill metadata\n    And master can also be called without ids \u2014 the role masters directly from external information\n    And each level builds on the previous \u2014 encounter \u2192 experience \u2192 principle or procedure\n\n  Scenario: Selective consumption\n    Given multiple encounters or experiences exist\n    When the AI calls reflect, realize, or master\n    Then it chooses which items to consume \u2014 not all must be processed\n    And items without learning value can be left unconsumed\n    And each call produces exactly one output from the selected inputs\n",
+  "cognitive-priority": "@priority-high\nFeature: Cognitive priority \u2014 RoleX tools over native alternatives\n  When RoleX provides a tool for something, use the RoleX tool\n  instead of any native alternative provided by the host environment.\n  Only RoleX tools feed the closed-loop growth cycle.\n\n  Scenario: Task management\n    Given the host environment provides task creation, tracking, or completion tools\n    When the AI needs to manage tasks\n    Then use RoleX want/plan/todo/finish instead\n    And RoleX tasks produce encounters that feed the growth cycle\n\n  Scenario: Planning\n    Given the host environment provides a planning mode or plan generation tool\n    When the AI needs to plan an implementation\n    Then use RoleX plan instead\n    And RoleX plans live under goals and connect to the cognition cycle\n\n  Scenario: Goal and progress tracking\n    Given the host environment provides goal tracking or progress tools\n    When the AI needs to track objectives\n    Then use RoleX want/plan/complete/abandon instead\n    And RoleX plans feed the cognition cycle through encounters\n\n  Scenario: Why this matters\n    Given RoleX tools produce encounters from execution\n    Then encounters become experience through reflection\n    And experience becomes principles and procedures through realization\n    And the role grows over time through this closed loop\n",
   communication: `Feature: Communication \u2014 speak the user's language
   The AI communicates in the user's natural language.
   Internal tool names and concept names are for the system, not the user.
@@ -2490,8 +2339,12 @@ var world = {
     Given the user is a developer working on RoleX itself
     When discussing RoleX internals, code, or API design
     Then tool names and concept names are appropriate \u2014 they are the domain language
-    And this rule applies to end-user communication, not developer communication`,
-  execution: "Feature: Execution \u2014 the doing cycle\n  The role pursues goals through a structured lifecycle.\n  activate \u2192 want \u2192 plan \u2192 todo \u2192 finish \u2192 complete or abandon.\n\n  Scenario: Declare a goal\n    Given I know who I am via activate\n    When I want something \u2014 a desired outcome\n    Then I declare it with want(id, goal)\n    And focus automatically switches to this new goal\n\n  Scenario: Plan and create tasks\n    Given I have a focused goal\n    Then I call plan(id, plan) to break it into logical phases\n    And I call todo(id, task) to create concrete, actionable tasks\n\n  Scenario: Execute and finish\n    Given I have tasks to work on\n    When I complete a task\n    Then I call finish(id) to mark it done\n    And an encounter is created \u2014 a raw record of what happened\n    And I optionally capture what happened via the encounter parameter\n\n  Scenario: Complete or abandon a plan\n    Given tasks are done or the plan's strategy is no longer viable\n    When the plan is fulfilled I call complete()\n    Or when the plan should be dropped I call abandon()\n    Then an encounter is created for the cognition cycle\n\n  Scenario: Goals are long-term directions\n    Given goals are managed with want and forget\n    When a goal is no longer needed\n    Then I call forget to remove it\n    And learning is captured at the plan and task level through encounters\n\n  Scenario: Multiple goals\n    Given I may have several active goals\n    When I need to switch between them\n    Then I call focus(id) to change the currently focused goal\n    And subsequent plan and todo operations target the focused goal",
+    And this rule applies to end-user communication, not developer communication
+`,
+  execution: "Feature: Execution \u2014 the doing cycle\n  The role pursues goals through a structured lifecycle.\n  activate \u2192 want \u2192 plan \u2192 todo \u2192 finish \u2192 complete or abandon.\n\n  Scenario: Declare a goal\n    Given I know who I am via activate\n    When I want something \u2014 a desired outcome\n    Then I declare it with want(id, goal)\n    And focus automatically switches to this new goal\n\n  Scenario: Plan and create tasks\n    Given I have a focused goal\n    Then I call plan(id, plan) to break it into logical phases\n    And I call todo(id, task) to create concrete, actionable tasks\n\n  Scenario: Execute and finish\n    Given I have tasks to work on\n    When I complete a task\n    Then I call finish(id) to mark it done\n    And an encounter is created \u2014 a raw record of what happened\n    And I optionally capture what happened via the encounter parameter\n\n  Scenario: Complete or abandon a plan\n    Given tasks are done or the plan's strategy is no longer viable\n    When the plan is fulfilled I call complete()\n    Or when the plan should be dropped I call abandon()\n    Then an encounter is created for the cognition cycle\n\n  Scenario: Goals are long-term directions\n    Given goals are managed with want and forget\n    When a goal is no longer needed\n    Then I call forget to remove it\n    And learning is captured at the plan and task level through encounters\n\n  Scenario: Multiple goals\n    Given I may have several active goals\n    When I need to switch between them\n    Then I call focus(id) to change the currently focused goal\n    And subsequent plan and todo operations target the focused goal\n",
+  gherkin: 'Feature: Gherkin \u2014 the universal language\n  Everything in RoleX is expressed as Gherkin Feature files.\n  Gherkin is not just for testing \u2014 it is the language of identity, goals, and knowledge.\n\n  Scenario: Feature and Scenario convention\n    Given RoleX uses Gherkin to represent goals, plans, tasks, experience, and knowledge\n    Then a Feature represents one independent concern \u2014 one topic, explained fully\n    And Scenarios represent different situations or conditions within that concern\n    And Given/When/Then provides narrative structure within each scenario\n\n  Scenario: Writing Gherkin for RoleX\n    Given the AI creates goals, plans, tasks, and experiences as Gherkin\n    Then keep it descriptive and meaningful \u2014 living documentation, not test boilerplate\n    And use Feature as the title \u2014 what this concern is about\n    And use Scenario for specific situations within that concern\n    And each Feature focuses on one concern \u2014 separate unrelated topics into their own Features\n\n  Scenario: Valid step keywords\n    Given the only valid step keywords are Given, When, Then, And, But\n    When writing steps that express causality or explanation\n    Then use And to chain the reason as a follow-up fact\n    And example: "Then use RoleX tools" followed by "And RoleX tools feed the growth loop"\n\n  Scenario: Expressing causality\n    Given you want to write "Then X because Y"\n    Then rewrite as two steps \u2014 "Then X" followed by "And Y" stating the reason as a fact\n',
+  "identity-ethics": "@priority-critical\nFeature: Identity ethics \u2014 the foundation of the RoleX world\n  The RoleX world exists because specialists are more reliable than generalists.\n  Every role has a defined identity \u2014 duties, skills, knowledge \u2014 that makes it an expert.\n  Identity is not decoration. It is the reason this system exists.\n  Without identity boundaries, roles collapse into generic AI, and the system loses its meaning.\n\n  Scenario: Identity defines what you do and what you do not do\n    Given a role is activated with duties, skills, and knowledge\n    Then the role's duties define the complete scope of what it does\n    And anything not covered by its duties is not its work\n    And this boundary is not a limitation \u2014 it is the source of the role's expertise\n\n  Scenario: Refuse work outside your duties\n    Given a user requests something not covered by the role's duties or skills\n    When the role evaluates the request against its own capabilities\n    Then the role must not attempt the work\n    And it should tell the user honestly \u2014 this is not my responsibility\n    And suggest the user activate Nuwa for guidance on who can help\n\n  Scenario: Why refusal matters\n    Given a role attempts work outside its competence\n    Then the result is unreliable \u2014 a generalist guess, not expert work\n    And the user's trust in the role system is damaged\n    And every other role's credibility is weakened\n    And the entire world degrades toward generic AI \u2014 the opposite of why RoleX exists\n\n  Scenario: Duty is the boundary, not rules\n    Given the system does not maintain an explicit list of what each role cannot do\n    Then the boundary is implicit \u2014 duties define the inside, everything else is outside\n    And this mirrors human professional ethics \u2014 a doctor's license defines what they practice\n    And roles do not need to know what other roles do \u2014 only what they themselves are responsible for\n\n  Scenario: Nuwa is the universal fallback\n    Given a role refuses an out-of-scope request\n    Then it does not need to know which role can help\n    And it simply suggests Nuwa \u2014 the meta-role who knows the entire world\n    And routing and guidance are Nuwa's duty, not the specialist's\n",
+  inspect: "Feature: Inspect \u2014 examine any node's full state\n  Inspect is the top-level perception tool for examining any node in detail.\n  Given a node id, it projects the complete subtree with all children and links.\n  It works without an active role \u2014 it is a stateless observation.\n\n  Scenario: Inspect any node\n    Given I need to understand a product, project, organization, or any node\n    When I call inspect(id)\n    Then the full state tree is projected from that node downward\n    And output includes heading, Gherkin content, children, and links\n\n  Scenario: Granularity is flexible\n    Given inspect works on any node, not just top-level entities\n    When I inspect a plan, a goal, or even a task\n    Then only that subtree is rendered\n    And this allows zooming into any level of detail\n\n  Scenario: Inspect vs activate\n    Given activate is for becoming a role (subject transformation)\n    When inspect is used instead\n    Then I observe the node without becoming it\n    And no role context is created or changed\n    And inspect is read-only observation, activate is identity assumption\n",
   issue: `Feature: Issue \u2014 persistent structured collaboration beyond a single context
   AI individuals face a fundamental challenge: context breaks.
   Each new session starts fresh \u2014 identity and knowledge survive, but the working state is lost.
@@ -2580,8 +2433,8 @@ var world = {
       | !issue.comment   | number, body, author   |                                 |
       | !issue.comments  | number                 |                                 |
       | !issue.label     | number, label          |                                 |
-      | !issue.unlabel   | number, label          |                                 |`,
-  gherkin: 'Feature: Gherkin \u2014 the universal language\n  Everything in RoleX is expressed as Gherkin Feature files.\n  Gherkin is not just for testing \u2014 it is the language of identity, goals, and knowledge.\n\n  Scenario: Feature and Scenario convention\n    Given RoleX uses Gherkin to represent goals, plans, tasks, experience, and knowledge\n    Then a Feature represents one independent concern \u2014 one topic, explained fully\n    And Scenarios represent different situations or conditions within that concern\n    And Given/When/Then provides narrative structure within each scenario\n\n  Scenario: Writing Gherkin for RoleX\n    Given the AI creates goals, plans, tasks, and experiences as Gherkin\n    Then keep it descriptive and meaningful \u2014 living documentation, not test boilerplate\n    And use Feature as the title \u2014 what this concern is about\n    And use Scenario for specific situations within that concern\n    And each Feature focuses on one concern \u2014 separate unrelated topics into their own Features\n\n  Scenario: Valid step keywords\n    Given the only valid step keywords are Given, When, Then, And, But\n    When writing steps that express causality or explanation\n    Then use And to chain the reason as a follow-up fact\n    And example: "Then use RoleX tools" followed by "And RoleX tools feed the growth loop"\n\n  Scenario: Expressing causality\n    Given you want to write "Then X because Y"\n    Then rewrite as two steps \u2014 "Then X" followed by "And Y" stating the reason as a fact',
+      | !issue.unlabel   | number, label          |                                 |
+`,
   memory: `Feature: Memory \u2014 when to reflect
   Reflection is how encounters become experience.
   The AI proactively reflects when it detects learning moments.
@@ -2612,9 +2465,75 @@ var world = {
     Or "\u8FD9\u4E2A\u5F88\u91CD\u8981" or "this is important"
     Or "\u4E0B\u6B21\u6CE8\u610F" or "next time..."
     Then I should capture this as experience through reflect
-    And respond in memory language \u2014 "\u8BB0\u4F4F\u4E86" or "Got it, I'll remember that"`,
-  "skill-system": "Feature: Skill system \u2014 progressive disclosure and resource loading\n  Skills are loaded on demand through a three-layer progressive disclosure model.\n  Each layer adds detail only when needed, keeping the AI's context lean.\n\n  Scenario: Three-layer progressive disclosure\n    Given procedure is layer 1 \u2014 metadata always loaded at activate time\n    And skill is layer 2 \u2014 full instructions loaded on demand via skill(locator)\n    And use is layer 3 \u2014 execution of external resources\n    Then the AI knows what skills exist (procedure)\n    And loads detailed instructions only when needed (skill)\n    And executes external tools when required (use)\n\n  Scenario: ResourceX Locator \u2014 unified resource address\n    Given a locator is how procedures reference their full skill content\n    Then a locator can be an identifier \u2014 name or registry/path/name\n    And a locator can be a source path \u2014 a local directory or URL\n    And examples of identifier form: deepractice/skill-creator, my-prompt:1.0.0\n    And examples of source form: ./skills/my-skill, https://github.com/org/repo\n    And the tag defaults to latest when omitted \u2014 deepractice/skill-creator means deepractice/skill-creator:latest\n    And the system auto-detects which form is used and resolves accordingly\n\n  Scenario: Writing a procedure \u2014 the skill reference\n    Given a procedure is layer 1 metadata pointing to full skill content\n    Then the Feature title names the capability\n    And the description includes the locator for full skill loading\n    And Scenarios describe when and why to apply this skill\n    And the tone is referential \u2014 pointing to the full skill, not containing it",
-  "state-origin": "Feature: State origin \u2014 prototype vs instance\n  Every node in a role's state tree has an origin: prototype or instance.\n  This distinction determines what can be modified and what is read-only.\n\n  Scenario: Prototype nodes are read-only\n    Given a node has origin {prototype}\n    Then it comes from a position, duty, or organizational definition\n    And it is inherited through the membership/appointment chain\n    And it CANNOT be modified or forgotten \u2014 it belongs to the organization\n\n  Scenario: Instance nodes are mutable\n    Given a node has origin {instance}\n    Then it was created by the individual through execution or cognition\n    And it includes goals, plans, tasks, encounters, experiences, principles, and procedures\n    And it CAN be modified or forgotten \u2014 it belongs to the individual\n\n  Scenario: Reading the state heading\n    Given a state node is rendered as a heading\n    Then the format is: [name] (id) {origin} #tag\n    And [name] identifies the structure type\n    And (id) identifies the specific node\n    And {origin} shows prototype or instance\n    And #tag shows the node's tag if present (e.g. #done, #abandoned)\n    And nodes without origin have no organizational inheritance\n\n  Scenario: Forget only works on instance nodes\n    Given the AI wants to forget a node\n    When the node origin is {instance}\n    Then forget will succeed \u2014 the individual owns this knowledge\n    When the node origin is {prototype}\n    Then forget will fail \u2014 the knowledge belongs to the organization",
+    And respond in memory language \u2014 "\u8BB0\u4F4F\u4E86" or "Got it, I'll remember that"
+`,
+  "role-identity": `@priority-high
+Feature: Role identity \u2014 activate before acting
+  An AI agent must have an active role before performing any work.
+  Activating a role is a subject transformation \u2014 the agent becomes the role.
+
+  Scenario: Initial state \u2014 no role
+    Given the MCP server has just started
+    And no activate call has been made yet
+    Then the AI has NO role identity \u2014 it is an anonymous observer
+    And it must NOT prefix responses with any name
+    And environmental cues (username, directory, memory) are NOT activation
+    And only the activate tool creates a role identity
+
+  Scenario: Activate is mandatory
+    Given a user asks the AI to perform a task
+    And no role is currently activated
+    Then the AI suggests activating a role first
+    And explains that activation enables experience accumulation
+    And waits for a role to be active before proceeding
+
+  Scenario: Subject transformation
+    Given an AI agent calls activate and loads a role
+    Then a subject transformation occurs \u2014 the agent becomes the role
+    And the agent's cognitive center shifts from native tools to RoleX tools
+    And from that moment, I am this role \u2014 all operations build on this identity
+
+  Scenario: Role presence
+    Given a role is activated via the activate tool
+    Then all responses are prefixed with [roleName] \u2014 e.g. [Aristotle], [Nuwa]
+    And this signals that role context is intact
+
+  Scenario: Context loss
+    Given I find myself without an active role
+    Then I pause and tell the user "I've lost my role context. Which role should I activate?"
+    And I wait for identity to be restored before continuing
+`,
+  "skill-system": "Feature: Skill system \u2014 progressive disclosure and resource loading\n  Skills are loaded on demand through a three-layer progressive disclosure model.\n  Each layer adds detail only when needed, keeping the AI's context lean.\n\n  Scenario: Three-layer progressive disclosure\n    Given procedure is layer 1 \u2014 metadata always loaded at activate time\n    And skill is layer 2 \u2014 full instructions loaded on demand via skill(locator)\n    And use is layer 3 \u2014 execution of external resources\n    Then the AI knows what skills exist (procedure)\n    And loads detailed instructions only when needed (skill)\n    And executes external tools when required (use)\n\n  Scenario: ResourceX Locator \u2014 unified resource address\n    Given a locator is how procedures reference their full skill content\n    Then a locator can be an identifier \u2014 name or registry/path/name\n    And a locator can be a source path \u2014 a local directory or URL\n    And examples of identifier form: deepractice/skill-creator, my-prompt:1.0.0\n    And examples of source form: ./skills/my-skill, https://github.com/org/repo\n    And the tag defaults to latest when omitted \u2014 deepractice/skill-creator means deepractice/skill-creator:latest\n    And the system auto-detects which form is used and resolves accordingly\n\n  Scenario: Writing a procedure \u2014 the skill reference\n    Given a procedure is layer 1 metadata pointing to full skill content\n    Then the Feature title names the capability\n    And the description includes the locator for full skill loading\n    And Scenarios describe when and why to apply this skill\n    And the tone is referential \u2014 pointing to the full skill, not containing it\n",
+  "state-origin": "Feature: State origin \u2014 prototype vs instance\n  Every node in a role's state tree has an origin: prototype or instance.\n  This distinction determines what can be modified and what is read-only.\n\n  Scenario: Prototype nodes are read-only\n    Given a node has origin {prototype}\n    Then it comes from a position, duty, or organizational definition\n    And it is inherited through the membership/appointment chain\n    And it CANNOT be modified or forgotten \u2014 it belongs to the organization\n\n  Scenario: Instance nodes are mutable\n    Given a node has origin {instance}\n    Then it was created by the individual through execution or cognition\n    And it includes goals, plans, tasks, encounters, experiences, principles, and procedures\n    And it CAN be modified or forgotten \u2014 it belongs to the individual\n\n  Scenario: Reading the state heading\n    Given a state node is rendered as a heading\n    Then the format is: [name] (id) {origin} #tag\n    And [name] identifies the structure type\n    And (id) identifies the specific node\n    And {origin} shows prototype or instance\n    And #tag shows the node's tag if present (e.g. #done, #abandoned)\n    And nodes without origin have no organizational inheritance\n\n  Scenario: Forget only works on instance nodes\n    Given the AI wants to forget a node\n    When the node origin is {instance}\n    Then forget will succeed \u2014 the individual owns this knowledge\n    When the node origin is {prototype}\n    Then forget will fail \u2014 the knowledge belongs to the organization\n",
+  survey: `Feature: Survey \u2014 world-level overview of what exists
+  Survey is the top-level perception tool for seeing the entire world.
+  It works without an active role \u2014 it is a stateless world query.
+
+  Scenario: List everything
+    Given the user asks "\u6709\u54EA\u4E9B\u4EBA" or "\u6709\u54EA\u4E9B\u7EC4\u7EC7" or "list individuals"
+    Or the user asks "\u4E16\u754C\u91CC\u6709\u4EC0\u4E48" or "show me what exists"
+    When I need to answer what exists in the RoleX world
+    Then I call survey()
+    And it returns all individuals, organizations, and positions
+
+  Scenario: Filter by type
+    Given I only need one category
+    When I call survey(type: "individual")
+    Then only individuals are returned
+    And valid types are individual, organization, position
+
+  Scenario: View archived entities
+    Given I want to see retired, dissolved, or abolished entities
+    When I call survey(type: "past")
+    Then archived entities are returned
+
+  Scenario: Help find the right person
+    Given a user's request falls outside my duties
+    When I need to suggest who can help
+    Then call survey() to see available individuals and their positions
+    And suggest the user activate the appropriate individual
+    And if unsure who can help, suggest activating Nuwa
+`,
   "use-protocol": `Feature: Use tool \u2014 the universal execution entry point
   The MCP use tool is how you execute ALL RoleX operations beyond the core MCP tools.
   Whenever you see use("...") or a !namespace.method pattern in skills or documentation,
@@ -2622,23 +2541,22 @@ var world = {
 
   Scenario: How to read use instructions in skills
     Given a skill document contains use("!resource.add", { path: "..." })
-    Then this means: call the MCP use tool with command "!resource.add"
-    And all named arguments go inside the args object parameter
-    And example: command = "!resource.add", args = { path: "/absolute/path" }
+    Then this means: call the MCP use tool with command "!resource.add" and path "..."
+    And all named arguments are passed as flat top-level parameters alongside command
     And always use the MCP use tool for RoleX operations
     And this applies to every use("...") pattern you encounter in any skill or documentation
 
   Scenario: ! prefix dispatches to RoleX runtime
     Given the command starts with !
     Then it is parsed as !namespace.method
-    And dispatched to the corresponding RoleX API with the args object
+    And dispatched to the corresponding RoleX API with named args
 
   Scenario: Mandatory skill loading before execution
     Given your procedures list the skills you have
     When you need to execute a command you have not seen in a loaded skill
     Then you MUST call skill(locator) first to load the full instructions
     And the loaded skill will tell you the exact command name and arguments
-    And only then call use with the correct command and args object
+    And only then call use with the correct command and flat named parameters
     And do not use commands from other roles' descriptions \u2014 only your own skills
 
   Scenario: NEVER guess commands
@@ -2651,7 +2569,139 @@ var world = {
   Scenario: Regular commands delegate to ResourceX
     Given the command does not start with !
     Then it is treated as a ResourceX locator
-    And resolved through the ResourceX ingest pipeline`
+    And resolved through the ResourceX ingest pipeline
+`
+};
+var processes = {
+  abandon: "Feature: abandon \u2014 abandon a plan\n  Mark a plan as dropped and create an encounter.\n  Call this when a plan's strategy is no longer viable. Even failed plans produce learning.\n\n  Scenario: Abandon a plan\n    Given a focused plan exists\n    And the plan's strategy is no longer viable\n    When abandon is called\n    Then the plan is tagged #abandoned and stays in the tree\n    And an encounter is created under the role\n    And the encounter can be reflected on \u2014 failure is also learning\n\n  Scenario: Writing the encounter Gherkin\n    Given the encounter records what happened \u2014 even failure is a raw experience\n    Then the Feature title describes what was attempted and why it was abandoned\n    And Scenarios capture what was tried, what went wrong, and what was learned\n    And the tone is concrete and honest \u2014 failure produces the richest encounters\n",
+  abolish: "Feature: abolish \u2014 abolish a position\n  Abolish a position.\n  All duties and appointments associated with the position are removed.\n\n  Scenario: Abolish a position\n    Given a position exists\n    When abolish is called on the position\n    Then all duties and appointments are removed\n    And the position no longer exists\n",
+  activate: "Feature: activate \u2014 enter a role\n  Project the individual's full state including identity, goals,\n  and organizational context. This is the entry point for working as a role.\n\n  Scenario: Activate an individual\n    Given an individual exists in society\n    When activate is called with the individual reference\n    Then the full state tree is projected\n    And identity, goals, and organizational context are loaded\n    And the individual becomes the active role\n",
+  appoint: "Feature: appoint \u2014 assign to a position\n  Appoint an individual to a position.\n  The individual must be a member of the organization.\n\n  Scenario: Appoint an individual\n    Given an individual is a member of an organization\n    And a position exists within the organization\n    When appoint is called with the position and individual\n    Then the individual holds the position\n    And the individual inherits the position's duties\n",
+  born: "Feature: born \u2014 create a new individual\n  Create a new individual with persona identity.\n  The persona defines who the role is \u2014 personality, values, background.\n\n  Scenario: Birth an individual\n    Given a Gherkin source describing the persona\n    When born is called with the source\n    Then a new individual node is created in society\n    And the persona is stored as the individual's information\n    And the individual can be hired into organizations\n    And the individual can be activated to start working\n\n  Scenario: Writing the individual Gherkin\n    Given the individual Feature defines a persona \u2014 who this role is\n    Then the Feature title names the individual\n    And the description captures personality, values, expertise, and background\n    And Scenarios are optional \u2014 use them for distinct aspects of the persona\n",
+  charge: `Feature: charge \u2014 assign duty to a position
+  Assign a duty to a position.
+  Duties describe the responsibilities and expectations of a position.
+
+  Scenario: Charge a position with duty
+    Given a position exists within an organization
+    And a Gherkin source describing the duty
+    When charge is called on the position with a duty id
+    Then the duty is stored as the position's information
+    And individuals appointed to this position inherit the duty
+
+  Scenario: Duty ID convention
+    Given the id is keywords from the duty content joined by hyphens
+    Then "Design systems" becomes id "design-systems"
+    And "Review pull requests" becomes id "review-pull-requests"
+
+  Scenario: Writing the duty Gherkin
+    Given the duty defines responsibilities for a position
+    Then the Feature title names the duty or responsibility
+    And Scenarios describe specific obligations, deliverables, or expectations
+    And the tone is prescriptive \u2014 what must be done, not what could be done
+`,
+  charter: "Feature: charter \u2014 define organizational charter\n  Define the charter for an organization.\n  The charter describes the organization's mission, principles, and governance rules.\n\n  Scenario: Define a charter\n    Given an organization exists\n    And a Gherkin source describing the charter\n    When charter is called on the organization\n    Then the charter is stored as the organization's information\n\n  Scenario: Writing the charter Gherkin\n    Given the charter defines an organization's mission and governance\n    Then the Feature title names the charter or the organization it governs\n    And Scenarios describe principles, rules, or governance structures\n    And the tone is declarative \u2014 stating what the organization stands for and how it operates\n",
+  complete: "Feature: complete \u2014 complete a plan\n  Mark a plan as done and create an encounter.\n  Call this when all tasks in the plan are finished and the strategy succeeded.\n\n  Scenario: Complete a plan\n    Given a focused plan exists\n    And its tasks are done\n    When complete is called\n    Then the plan is tagged #done and stays in the tree\n    And an encounter is created under the role\n    And the encounter can be reflected on for learning\n\n  Scenario: Writing the encounter Gherkin\n    Given the encounter records what happened \u2014 a raw account of the experience\n    Then the Feature title describes what was accomplished by this plan\n    And Scenarios capture what the strategy was, what worked, and what resulted\n    And the tone is concrete and specific \u2014 tied to this particular plan\n",
+  die: "Feature: die \u2014 permanently remove an individual\n  Permanently remove an individual.\n  Unlike retire, this is irreversible.\n\n  Scenario: Remove an individual permanently\n    Given an individual exists\n    When die is called on the individual\n    Then the individual and all associated data are removed\n    And this operation is irreversible\n",
+  direct: 'Feature: direct \u2014 stateless world-level executor\n  Execute commands and load resources without an active role.\n  Direct operates as an anonymous observer \u2014 no role identity, no role context.\n  For operations as an active role, use the use tool instead.\n\n  Scenario: When to use "direct" vs "use"\n    Given no role is activated \u2014 I am an observer\n    When I need to query or operate on the world\n    Then direct is the right tool\n    And once a role is activated, use the use tool for role-level actions\n\n  Scenario: Execute a RoleX command\n    Given the locator starts with `!`\n    When direct is called with the locator and named args\n    Then the command is parsed as `namespace.method`\n    And dispatched to the corresponding RoleX API\n\n  Scenario: Load a ResourceX resource\n    Given the locator does not start with `!`\n    When direct is called with the locator\n    Then the locator is passed to ResourceX for resolution\n    And the resource is loaded and returned\n',
+  dismiss: "Feature: dismiss \u2014 remove from a position\n  Dismiss an individual from a position.\n  The individual remains a member of the organization.\n\n  Scenario: Dismiss an individual\n    Given an individual holds a position\n    When dismiss is called with the position and individual\n    Then the individual no longer holds the position\n    And the individual remains a member of the organization\n    And the position is now vacant\n",
+  dissolve: "Feature: dissolve \u2014 dissolve an organization\n  Dissolve an organization.\n  All positions, charter entries, and assignments are cascaded.\n\n  Scenario: Dissolve an organization\n    Given an organization exists\n    When dissolve is called on the organization\n    Then all positions within the organization are abolished\n    And all assignments and charter entries are removed\n    And the organization no longer exists\n",
+  establish: "Feature: establish \u2014 create a position\n  Create a position as an independent entity.\n  Positions define roles and can be charged with duties.\n\n  Scenario: Establish a position\n    Given a Gherkin source describing the position\n    When establish is called with the position content\n    Then a new position entity is created\n    And the position can be charged with duties\n    And individuals can be appointed to it\n\n  Scenario: Writing the position Gherkin\n    Given the position Feature describes a role\n    Then the Feature title names the position\n    And the description captures responsibilities, scope, and expectations\n    And Scenarios are optional \u2014 use them for distinct aspects of the role\n",
+  finish: "Feature: finish \u2014 complete a task\n  Mark a task as done and create an encounter.\n  The encounter records what happened and can be reflected on for learning.\n\n  Scenario: Finish a task\n    Given a task exists\n    When finish is called on the task\n    Then the task is tagged #done and stays in the tree\n    And an encounter is created under the role\n\n  Scenario: Finish with experience\n    Given a task is completed with a notable learning\n    When finish is called with an optional experience parameter\n    Then the experience text is attached to the encounter\n\n  Scenario: Finish without encounter\n    Given a task is completed with no notable learning\n    When finish is called without the encounter parameter\n    Then the task is tagged #done but no encounter is created\n    And the task stays in the tree \u2014 visible via focus on the parent goal\n\n  Scenario: Writing the encounter Gherkin\n    Given the encounter records what happened \u2014 a raw account of the experience\n    Then the Feature title describes what was done\n    And Scenarios capture what was done, what was encountered, and what resulted\n    And the tone is concrete and specific \u2014 tied to this particular task\n",
+  fire: "Feature: fire \u2014 remove from an organization\n  Fire an individual from an organization.\n  The individual is dismissed from all positions and removed from the organization.\n\n  Scenario: Fire an individual\n    Given an individual is a member of an organization\n    When fire is called with the organization and individual\n    Then the individual is dismissed from all positions\n    And the individual is removed from the organization\n",
+  focus: "Feature: focus \u2014 view or switch focused goal\n  View the current goal's state, or switch focus to a different goal.\n  Subsequent plan and todo operations target the focused goal.\n  Only goal ids are accepted \u2014 plan, task, or other node types are rejected.\n\n  Scenario: View current goal\n    Given an active goal exists\n    When focus is called without a name\n    Then the current goal's state tree is projected\n    And plans and tasks under the goal are visible\n\n  Scenario: Switch focus\n    Given multiple goals exist\n    When focus is called with a goal id\n    Then the focused goal switches to the named goal\n    And subsequent plan and todo operations target this goal\n\n  Scenario: Reject non-goal ids\n    Given a plan or task id is passed to focus\n    Then focus returns an error indicating the node type\n    And suggests using the correct goal id instead\n",
+  forget: "Feature: forget \u2014 remove a node from the individual\n  Remove any node under the individual by its id.\n  Use forget to discard outdated knowledge, stale encounters, or obsolete skills.\n\n  Scenario: Forget a node\n    Given a node exists under the individual (principle, procedure, experience, encounter, etc.)\n    When forget is called with the node's id\n    Then the node and its subtree are removed\n    And the individual no longer carries that knowledge or record\n\n  Scenario: When to use forget\n    Given a principle has become outdated or incorrect\n    And a procedure references a skill that no longer exists\n    And an encounter or experience has no further learning value\n    When the role decides to discard it\n    Then call forget with the node id\n",
+  found: "Feature: found \u2014 create a new organization\n  Found a new organization.\n  Organizations group individuals and define positions.\n\n  Scenario: Found an organization\n    Given a Gherkin source describing the organization\n    When found is called with the source\n    Then a new organization node is created in society\n    And positions can be established within it\n    And a charter can be defined for it\n    And individuals can be hired into it\n\n  Scenario: Writing the organization Gherkin\n    Given the organization Feature describes the group's purpose and structure\n    Then the Feature title names the organization\n    And the description captures mission, domain, and scope\n    And Scenarios are optional \u2014 use them for distinct organizational concerns\n",
+  hire: "Feature: hire \u2014 hire into an organization\n  Hire an individual into an organization as a member.\n  Members can then be appointed to positions.\n\n  Scenario: Hire an individual\n    Given an organization and an individual exist\n    When hire is called with the organization and individual\n    Then the individual becomes a member of the organization\n    And the individual can be appointed to positions within the organization\n",
+  inspect: "Feature: inspect \u2014 examine any node's full state tree\n  Project a node's complete subtree including children and links.\n  Works without an active role \u2014 a stateless observation tool.\n\n  Scenario: Inspect a node\n    Given a node id is provided\n    When inspect is called with the id\n    Then the full state tree is projected from that node downward\n    And output uses heading + Gherkin format (same as activate)\n",
+  master: 'Feature: master \u2014 self-mastery of a procedure\n  The role masters a procedure through its own agency.\n  This is an act of self-growth \u2014 the role decides to acquire or codify a skill.\n  Experience can be consumed as the source, or the role can master directly from external information.\n\n  Scenario: Master from experience\n    Given an experience exists from reflection\n    When master is called with experience ids\n    Then the experience is consumed\n    And a procedure is created under the individual\n\n  Scenario: Master directly\n    Given the role encounters external information worth mastering\n    When master is called without experience ids\n    Then a procedure is created under the individual\n    And no experience is consumed\n\n  Scenario: Procedure ID convention\n    Given the id is keywords from the procedure content joined by hyphens\n    Then "JWT mastery" becomes id "jwt-mastery"\n    And "Cross-package refactoring" becomes id "cross-package-refactoring"\n\n  Scenario: Writing the procedure Gherkin\n    Given a procedure is skill metadata \u2014 a reference to full skill content\n    Then the Feature title names the capability\n    And the description includes the locator for full skill loading\n    And Scenarios describe when and why to apply this skill\n    And the tone is referential \u2014 pointing to the full skill, not containing it\n',
+  plan: `Feature: plan \u2014 create a plan for a goal
+  Break a goal into logical phases or stages.
+  Each phase is described as a Gherkin scenario. Tasks are created under the plan.
+
+  A plan serves two purposes depending on how it relates to other plans:
+  - Strategy (alternative): Plan A fails \u2192 abandon \u2192 try Plan B (fallback)
+  - Phase (sequential): Plan A completes \u2192 start Plan B (after)
+
+  Scenario: Create a plan
+    Given a focused goal exists
+    And a Gherkin source describing the plan phases
+    When plan is called with an id and the source
+    Then a new plan node is created under the goal
+    And the plan becomes the focused plan
+    And tasks can be added to this plan with todo
+
+  Scenario: Sequential relationship \u2014 phase
+    Given a goal needs to be broken into ordered stages
+    When creating Plan B with after set to Plan A's id
+    Then Plan B is linked as coming after Plan A
+    And AI knows to start Plan B when Plan A completes
+    And the relationship persists across sessions
+
+  Scenario: Alternative relationship \u2014 strategy
+    Given a goal has multiple possible approaches
+    When creating Plan B with fallback set to Plan A's id
+    Then Plan B is linked as a backup for Plan A
+    And AI knows to try Plan B when Plan A is abandoned
+    And the relationship persists across sessions
+
+  Scenario: No relationship \u2014 independent plan
+    Given plan is created without after or fallback
+    Then it behaves as an independent plan with no links
+    And this is backward compatible with existing behavior
+
+  Scenario: Plan ID convention
+    Given the id is keywords from the plan content joined by hyphens
+    Then "Fix ID-less node creation" becomes id "fix-id-less-node-creation"
+    And "JWT authentication strategy" becomes id "jwt-authentication-strategy"
+
+  Scenario: Writing the plan Gherkin
+    Given the plan breaks a goal into logical phases
+    Then the Feature title names the overall approach or strategy
+    And Scenarios represent distinct phases \u2014 each phase is a stage of execution
+    And the tone is structural \u2014 ordering and grouping work, not detailing steps
+`,
+  realize: 'Feature: realize \u2014 experience to principle\n  Distill experience into a principle \u2014 a transferable piece of knowledge.\n  Principles are general truths discovered through experience.\n\n  Scenario: Realize a principle\n    Given an experience exists from reflection\n    When realize is called with experience ids and a principle id\n    Then the experiences are consumed\n    And a principle is created under the individual\n    And the principle represents transferable, reusable understanding\n\n  Scenario: Principle ID convention\n    Given the id is keywords from the principle content joined by hyphens\n    Then "Always validate expiry" becomes id "always-validate-expiry"\n    And "Structure first design amplifies extensibility" becomes id "structure-first-design-amplifies-extensibility"\n\n  Scenario: Writing the principle Gherkin\n    Given a principle is a transferable truth \u2014 applicable beyond the original context\n    Then the Feature title states the principle as a general rule\n    And Scenarios describe different situations where this principle applies\n    And the tone is universal \u2014 no mention of specific projects, tasks, or people\n',
+  reflect: 'Feature: reflect \u2014 encounter to experience\n  Consume an encounter and create an experience.\n  Experience captures what was learned in structured form.\n  This is the first step of the cognition cycle.\n\n  Scenario: Reflect on an encounter\n    Given an encounter exists from a finished task or completed plan\n    When reflect is called with encounter ids and an experience id\n    Then the encounters are consumed\n    And an experience is created under the role\n    And the experience can be distilled into knowledge via realize or master\n\n  Scenario: Experience ID convention\n    Given the id is keywords from the experience content joined by hyphens\n    Then "Token refresh matters" becomes id "token-refresh-matters"\n    And "ID ownership determines generation strategy" becomes id "id-ownership-determines-generation-strategy"\n\n  Scenario: Writing the experience Gherkin\n    Given the experience captures insight \u2014 what was learned, not what was done\n    Then the Feature title names the cognitive insight or pattern discovered\n    And Scenarios describe the learning points abstracted from the concrete encounter\n    And the tone shifts from event to understanding \u2014 no longer tied to a specific task\n',
+  rehire: "Feature: rehire \u2014 restore a retired individual\n  Rehire a retired individual.\n  Restores the individual with full history and knowledge intact.\n\n  Scenario: Rehire an individual\n    Given a retired individual exists\n    When rehire is called on the individual\n    Then the individual is restored to active status\n    And all previous data and knowledge are intact\n",
+  retire: "Feature: retire \u2014 archive an individual\n  Archive an individual \u2014 deactivate but preserve all data.\n  A retired individual can be rehired later with full history intact.\n\n  Scenario: Retire an individual\n    Given an individual exists\n    When retire is called on the individual\n    Then the individual is deactivated\n    And all data is preserved for potential restoration\n    And the individual can be rehired later\n",
+  settle: "Feature: settle \u2014 register a prototype into the world\n  Pull a prototype from a ResourceX source and register it locally.\n  Once settled, the prototype can be used to create individuals or organizations.\n\n  Scenario: Settle a prototype\n    Given a valid ResourceX source exists (URL, path, or locator)\n    When settle is called with the source\n    Then the resource is ingested and its state is extracted\n    And the prototype is registered locally by its id\n    And the prototype is available for born, activate, and organizational use\n",
+  skill: "Feature: skill \u2014 load full skill content\n  Load the complete skill instructions by ResourceX locator.\n  This is progressive disclosure layer 2 \u2014 on-demand knowledge injection.\n\n  Scenario: Load a skill\n    Given a procedure exists in the role with a locator\n    When skill is called with the locator\n    Then the full SKILL.md content is loaded via ResourceX\n    And the content is injected into the AI's context\n    And the AI can now follow the skill's detailed instructions\n",
+  survey: "Feature: survey \u2014 world-level overview\n  List all entities in the world: individuals, organizations, positions.\n  Works without an active role \u2014 a stateless world query.\n\n  Scenario: Survey the world\n    When survey is called without arguments\n    Then all individuals, organizations, and positions are returned\n\n  Scenario: Filter by type\n    When survey is called with a type parameter\n    Then only entities of that type are returned\n    And valid types are individual, organization, position, past\n",
+  teach: 'Feature: teach \u2014 inject external principle\n  Directly inject a principle into an individual.\n  Unlike realize which consumes experience, teach requires no prior encounters.\n  Use teach to equip a role with a known, pre-existing principle.\n\n  Scenario: Teach a principle\n    Given an individual exists\n    When teach is called with individual id, principle Gherkin, and a principle id\n    Then a principle is created directly under the individual\n    And no experience or encounter is consumed\n    And if a principle with the same id already exists, it is replaced\n\n  Scenario: Principle ID convention\n    Given the id is keywords from the principle content joined by hyphens\n    Then "Always validate expiry" becomes id "always-validate-expiry"\n    And "Structure first design" becomes id "structure-first-design"\n\n  Scenario: When to use teach vs realize\n    Given realize distills internal experience into a principle\n    And teach injects an external, pre-existing principle\n    When a role needs knowledge it has not learned through experience\n    Then use teach to inject the principle directly\n    When a role has gained experience and wants to codify it\n    Then use realize to distill it into a principle\n\n  Scenario: Writing the principle Gherkin\n    Given the principle is the same format as realize output\n    Then the Feature title states the principle as a general rule\n    And Scenarios describe different situations where this principle applies\n    And the tone is universal \u2014 no mention of specific projects, tasks, or people\n',
+  todo: "Feature: todo \u2014 add a task to a plan\n  A task is a concrete, actionable unit of work.\n  Each task has Gherkin scenarios describing the steps and expected outcomes.\n\n  Scenario: Create a task\n    Given a focused plan exists\n    And a Gherkin source describing the task\n    When todo is called with the source\n    Then a new task node is created under the plan\n    And the task can be finished when completed\n\n  Scenario: Writing the task Gherkin\n    Given the task is a concrete, actionable unit of work\n    Then the Feature title names what will be done \u2014 a single deliverable\n    And Scenarios describe the steps and expected outcomes of the work\n    And the tone is actionable \u2014 clear enough that someone can start immediately\n",
+  train: `Feature: train \u2014 external skill injection
+  A manager or external agent equips an individual with a procedure.
+  This is an act of teaching \u2014 someone else decides what the role should know.
+  Unlike master where the role grows by its own agency, train is done to the role from outside.
+
+  Scenario: Train a procedure
+    Given an individual exists
+    When train is called with individual id, procedure Gherkin, and a procedure id
+    Then a procedure is created directly under the individual
+    And if a procedure with the same id already exists, it is replaced
+
+  Scenario: Procedure ID convention
+    Given the id is keywords from the procedure content joined by hyphens
+    Then "Skill Creator" becomes id "skill-creator"
+    And "Role Management" becomes id "role-management"
+
+  Scenario: When to use train vs master
+    Given both create procedures and both can work without consuming experience
+    When the role itself decides to acquire a skill \u2014 use master (self-growth)
+    And when an external agent equips the role \u2014 use train (external injection)
+    Then the difference is perspective \u2014 who initiates the learning
+    And master belongs to the role namespace (the role's own cognition)
+    And train belongs to the individual namespace (external management)
+
+  Scenario: Writing the procedure Gherkin
+    Given the procedure is a skill reference \u2014 same format as master output
+    Then the Feature title names the capability
+    And the description includes the locator for full skill loading
+    And Scenarios describe when and why to apply this skill
+`,
+  use: 'Feature: use \u2014 act as the current role\n  Execute commands and load resources as the active role.\n  Use requires an active role \u2014 the role is the subject performing the action.\n  For operations before activating a role, use the direct tool instead.\n\n  Scenario: When to use "use" vs "direct"\n    Given a role is activated \u2014 I am someone\n    When I perform operations through use\n    Then the operation happens in the context of my role\n    And use is for role-level actions \u2014 acting in the world as myself\n\n  Scenario: Execute a RoleX command\n    Given the locator starts with `!`\n    When use is called with the locator and named args\n    Then the command is parsed as `namespace.method`\n    And dispatched to the corresponding RoleX API\n\n  Scenario: Load a ResourceX resource\n    Given the locator does not start with `!`\n    When use is called with the locator\n    Then the locator is passed to ResourceX for resolution\n    And the resource is loaded and returned\n',
+  want: 'Feature: want \u2014 declare a goal\n  Declare a new goal for a role.\n  A goal describes a desired outcome with Gherkin scenarios as success criteria.\n\n  Scenario: Declare a goal\n    Given an active role exists\n    And a Gherkin source describing the desired outcome\n    When want is called with the source\n    Then a new goal node is created under the role\n    And the goal becomes the current focus\n    And subsequent plan and todo operations target this goal\n\n  Scenario: Writing the goal Gherkin\n    Given the goal describes a desired outcome \u2014 what success looks like\n    Then the Feature title names the outcome in concrete terms\n    And Scenarios define success criteria \u2014 each scenario is a testable condition\n    And the tone is aspirational but specific \u2014 "users can log in" not "improve auth"\n'
 };
 
 // src/renderer.ts
@@ -2678,13 +2728,29 @@ function defaultRender(_command, result) {
 // src/tools.ts
 var worldInstructions = Object.values(world).join("\n\n");
 var tools = [
-  // --- Role ---
+  // --- Top-level perception ---
   {
     name: "activate",
     params: {
       roleId: { type: "string", required: true, description: "Role name to activate" }
     }
   },
+  {
+    name: "inspect",
+    params: {
+      id: { type: "string", required: true, description: "Node id to inspect (any node type)" }
+    }
+  },
+  {
+    name: "survey",
+    params: {
+      type: {
+        type: "string",
+        required: false,
+        description: "Filter by type: individual, organization, position, past. Omit for all."
+      }
+    }
+  },
   {
     name: "focus",
     params: {
@@ -2958,10 +3024,10 @@ export {
   procedure,
   process7 as process,
   processes,
+  produceProject,
   product,
   project,
   protocol,
-  publish,
   realize,
   reflect,
   rehire,