@nestr/mcp 0.1.96 → 0.1.98

package/build/help/topics.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"topics.d.ts","sourceRoot":"","sources":["../../src/help/topics.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAMH,eAAO,MAAM,WAAW,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CA6+C9C,CAAC"}
+{"version":3,"file":"topics.d.ts","sourceRoot":"","sources":["../../src/help/topics.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAMH,eAAO,MAAM,WAAW,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAikD9C,CAAC"}

package/build/help/topics.js

@@ -21,6 +21,7 @@ The internal topics below are curated MCP-flavoured guidance — tool call patte
 - nest-model: Nest fields, hierarchy, hints, and fieldsMetaData
 - labels: Important labels, label architecture, and field schema customization
 - search: Full search query syntax with all operators and examples
+- fields: Adding custom fields to labels when Nestr has no field for something yet
 - web-app-links: URL formats for linking to the Nestr web app
 - inbox: Inbox quick capture, processing workflow, and reordering
 - daily-plan: Daily plan usage, scope, and planning workflows
@@ -181,7 +182,7 @@ Nestr uses different formats for different fields:
 - **\`purpose\`**: The aspirational future state this nest is working towards. **Most important for workspaces, circles, and roles** — it defines the north star and context boundary for the organization, circle, or role. Everything within that container should serve its purpose. For other nests (tasks, projects, etc.), prefer \`description\` or \`fields\` for detailed information — but purpose can be set if it serves the user. Supports HTML.
 - **\`description\`**: The primary field for detailed information about a nest. Use for project details, task context, acceptance criteria, Definition of Done, and any persistent information about the nest. Supports HTML.
 - **\`fields\`**: Structured data defined by labels (e.g., \`fields['project.status']\`, \`fields['metric.frequency']\`). Use for structured, label-specific information.
-- **Comment \`body\`**: HTML supported (same tags as above, including base64 images). Supports @mentions — **mentions MUST be wrapped in literal curly braces**: write \`@{aBcD1234eFgH5678i:roleNestId}\`, NOT \`@aBcD1234eFgH5678i\`. Without the braces the platform does not parse the mention, the user is not notified, and no link is rendered. Forms: **\`@{userId:roleId}\` is the preferred form when mentioning a user** — it addresses them in the context of a specific role (or a circle, for "individual action on a circle"), so they know which hat they're being addressed in. \`@{userId}\` mentions by user ID without role context (legacy — avoid when a role is known), \`@{email}\` mentions by any email the user is registered with in Nestr, \`@{circle}\` notifies all role fillers in the nearest ancestor circle, \`@{everyone}\` is available in the UI but not yet via the API. **Use comments for progress updates**, status changes, and conversation — not purpose or description.
+- **Comment \`body\`**: HTML supported (same tags as above, including base64 images). Supports @mentions — **mentions MUST be wrapped in literal curly braces**: write \`@{aBcD1234eFgH5678i:roleNestId}\`, NOT \`@aBcD1234eFgH5678i\`. Without the braces the platform does not parse the mention, the user is not notified, and no link is rendered. Forms: **\`@{userId:roleId}\` is the preferred form when mentioning a user** — it addresses them in the context of a specific role (or a circle, for "individual action on a circle"), so they know which hat they're being addressed in. the second id must be a ROLE or CIRCLE nest and never the project, task or tension being commented on, since the mention renders that nest's title where the role name belongs (a project id produces 'Henk as Write a weekly blog post', reading as though the project were his role). \`@{userId}\` mentions by user ID without role context (use it when the role is genuinely unknown, rather than substituting the nest you are working on), \`@{email}\` mentions by any email the user is registered with in Nestr, \`@{circle}\` notifies all role fillers in the nearest ancestor circle, \`@{everyone}\` is available in the UI but not yet via the API. **Use comments for progress updates**, status changes, and conversation — not purpose or description.
 - **\`data\`**: Generic key-value store. Also used internally by Nestr and other integrations — **never overwrite or remove existing keys**. When adding your own data, namespace it under \`mcp.\` (e.g., \`{ "mcp.lastSync": "2025-01-01" }\`) to avoid conflicts. Not rendered in UI.
 
 **Where to put information:**
@@ -348,6 +349,7 @@ Each hint object has:
 | \`project_no_acceptance_criteria\` | suggestion | project | Missing description/acceptance criteria |
 | \`project_overdue\` | warning | project | Past due date |
 | \`no_proposed_output\` | suggestion | tension | Tension has no proposed output yet |
+| \`inline_images\` | info | all | Count of images pasted into the text (see below) |
 
 Example response with hints:
 \`\`\`json
@@ -371,6 +373,15 @@ Example response with hints:
 }
 \`\`\`
 
+**Inline images.** An image pasted into a nest's text is stored as a file and left in the
+content as a markdown reference: \`![name](/file/download?id=FILE_ID&name=NAME)\`. These are
+deliberately absent from \`nestr_get_nest_files\`, because they belong to the text rather than
+to the attachment list, and the \`files\` hint does not count them either. The
+\`inline_images\` hint is how you learn they are there. To look at one, take its FILE_ID from
+the reference in the content and call \`nestr_read_file({ nestId, fileId })\` — that works for
+inline images even though they are not listed. The hint carries no \`toolCall\`: the id belongs
+to a specific reference, so there is no single call to pre-map.
+
 Use hints to proactively surface issues to the user — for example, when reviewing a circle's roles, hints can reveal which roles need attention without separate queries. Use the \`toolCall\` to drill into any hint directly.`,
     "labels": `## Important Labels
 
@@ -441,6 +452,8 @@ Labels created by individual users for their own organization:
 
 ### Field Schemas and Customization
 
+**Need a field that does not exist yet?** A workspace admin can add one to the label, and every item of that type picks it up. See \`nestr_help({ topic: "fields" })\` before telling anyone a field is not available.
+
 Labels define field schemas - the custom fields available on nests with that label. Key points:
 
 - **Namespacing**: All fields are namespaced by the label that defines them (e.g., \`project.status\`, \`role.electable-role\`, \`metric.frequency\`)
@@ -474,6 +487,39 @@ This adds a \`fieldsMetaData\` object to the response showing field definitions
 Use this when you need to know what values are valid for a field, especially before updating.
 
 **Example**: A workspace might customize the global \`project\` label to add a \`project.department\` field, and a sub-circle might further customize it to add \`project.sprint\` - both would appear on projects within that sub-circle.`,
+    "fields": `## Custom Fields (recording data Nestr has no field for yet)
+
+**Rule of thumb: when someone asks "can I record X on Y?" and there is no built-in field for it, the answer is almost always yes.** Fields are defined on labels, so a workspace admin adds the field to Y's label and every item of that type gets it. Never tell a user something cannot be recorded just because you could not find a field for it. Check the label's schema first, then point them at this route.
+
+### How fields work
+
+- **Defined per label, not per item.** Adding a field to a label gives it to every item carrying that label, including items that already exist.
+- **Where:** Workspace settings -> Labels, Fields & Tabs -> select the label -> add a field.
+- **Who:** a workspace admin. If the person asking is not an admin, describe the route and suggest they ask an admin, rather than saying it is not possible.
+- **Naming:** the new field is namespaced by its label, e.g. \`tension.notes\`, and is read and written through \`fields\` on the nest tools like any built-in field.
+- **Per-circle overrides:** a circle can add, alter or hide a label's fields for itself, and a circle nested inside it can override again. The same label can carry different fields in different parts of the tree.
+- **Internally** this is stored as a tagAlong label on the label definition. That is implementation detail. Talk to users about "adding a field to the label".
+
+### Check before you answer
+
+Fetch any nest of that type with \`fieldsMetaData=true\` (see topic "labels") to read the live schema, including the options on a dropdown. A field you do not recognise may already exist in that workspace.
+
+### Common requests, and the label to change
+
+| Request | What to do |
+|---|---|
+| Notes on a meeting agenda item | Agenda items are tensions. Add a multiline or HTML text field to the \`tension\` label. |
+| A budget on projects | Currency field on \`project\`. |
+| A start date on roles | Date field on \`role\`. |
+| A renewal date on contracts | Create a workspace label for contracts, add a date field to it. |
+| A priority to group a board by | Drop down list on the label, then group with \`groupbycol:<label>-><field>\` (see topic "search"). |
+| Something Nestr has no concept of at all | Create a workspace label for it and give it fields. |
+
+### Field types available
+
+Text, multiline text, HTML text, number, currency, percentage, slider, range, formula, drop down list, multi-select drop down list, label drop down selector, checkbox, date, term selector, nest link, URL, user.
+
+Fields are first class: once added you can search, filter, sort and group by them.`,
     "search": `## Search Query Syntax
 
 The \`nestr_search\` tool supports powerful query operators. Combine multiple operators with spaces (AND logic) or use commas within an operator (OR logic).
@@ -499,6 +545,8 @@ The \`nestr_search\` tool supports powerful query operators. Combine multiple op
 | \`depth:\` | \`depth:1\` | Limit search depth (1 = direct children only) |
 | \`mindepth:\` | \`mindepth:2\` | Minimum depth from search context |
 | \`limit:\` | \`limit:10\` | Limit number of results |
+| \`groupby:\` | \`groupby:parent\` | Group results into sections (app + tabs; inert here) |
+| \`groupbycol:\` | \`groupbycol:project->status\` | Same grouping as board columns — see "Grouping and Layout" below |
 
 ### The \`has:\` Operator
 
@@ -641,6 +689,41 @@ label:project completed:this_month sort:completedAt sort-order:desc
   -> Recently completed projects
 \`\`\`
 
+### Grouping and Layout (\`groupby:\` / \`groupbycol:\`)
+
+\`groupby:\` and \`groupbycol:\` are supported operators that organise results rather than filter them. \`groupby:\` splits the list into sections; \`groupbycol:\` lays the same grouping out as columns, i.e. a kanban board. Both can appear in one query, giving sections inside each column.
+
+**Where they take effect:** the search bar in the Nestr app, and the search term saved on a tab (Workspace settings -> Labels, Fields & Tabs -> pick the label -> its tabs). They are accepted but inert for the \`nestr_search\` API tool, which always returns a flat list — so group the results yourself when answering. Do not tell a user these operators do not exist, and do not send them hunting for a menu instead: in the app and on tabs they work.
+
+**Values (the same set for both):**
+- \`label\` — the first groupable label on each result
+- \`parent\` — the item's parent nest
+- \`workspace\`
+- \`assignee\` — first assigned user, \`none\` when unassigned
+- \`completed\` — completed vs not (needs 'hide completed' turned off to show both)
+- \`due\` — Overdue / Today / This week / Next week / Later / Without due date
+- \`{labelId}->{fieldCode}\` — any dropdown field on a label, e.g. \`project->status\` or \`task->status\`. This general form is not in the app's autosuggest but is fully supported, for custom fields too.
+- \`ancestorlabel->{labelId,...}\` — the nearest ancestor carrying one of the listed labels, e.g. \`groupby:ancestorlabel->circleplus-role,circleplus-circle\` for a lane per role or circle. Built-in views such as My projects use exactly this.
+
+**Worked example — a board of tasks by status inside a project.** Tasks have no native status field (projects do: Future / Current / Waiting / Done), so add a dropdown field, e.g. \`status\`, to the task label first, then give the project label a search tab whose term includes \`groupbycol:task->status\`. Every project then shows its tasks as a board with one column per status value.
+
+**Examples:**
+\`\`\`
+label:project groupbycol:project->status
+  -> Projects as a board, one column per project status
+
+completed:false groupbycol:assignee
+  -> Open work as a board, one column per person
+
+label:project groupby:ancestorlabel->circleplus-role,circleplus-circle
+  -> Projects in sections, one per owning role or circle
+
+groupbycol:task->status groupby:parent
+  -> Tasks as status columns, sectioned by their parent inside each column
+\`\`\`
+
+Public help articles covering the same ground, each fetched by passing its slug as \`topic\`: \`nestr-search\` for the in-app search UI, \`customising-tabs\` for putting a search on a tab, and \`customising-views\` for the per-person list/columns switch.
+
 ### Scoping Search to a Specific Nest
 
 Use \`in:nestId\` to limit search results to only items within a specific nest (its descendants at any depth).

package/build/help/topics.js.map

@@ -1 +1 @@
-{"version":3,"file":"topics.js","sourceRoot":"","sources":["../../src/help/topics.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,uBAAuB,EAAE,MAAM,yBAAyB,CAAC;AAClE,OAAO,EAAE,+BAA+B,EAAE,MAAM,iCAAiC,CAAC;AAClF,OAAO,EAAE,4BAA4B,EAAE,MAAM,8BAA8B,CAAC;AAE5E,MAAM,CAAC,MAAM,WAAW,GAA2B;IACjD,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;kFA0BsE;IAEhF,iBAAiB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sGAqDiF;IAEpG,wBAAwB,EAAE;;;;;;;;;;;;;;;4FAegE;IAE1F,SAAS,EAAE;;;;;;;;;;;;;;;;;;;;;wEAqB2D;IAEtE,iBAAiB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4GAqCuF;IAE1G,eAAe,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2CZ;IAEL,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gOAkKgN;IAE9N,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;2OAqG+N;IAEzO,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAkQL;IAEL,eAAe,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gCAwCa;IAE9B,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAuEJ;IAEL,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAkET;IAEL,eAAe,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;qGAyCkF;IAEnG,UAAU,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;0FA6B4E;IAExF,UAAU,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAgHP;IAEL,gBAAgB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gLA6F4J;IAE9K,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4TAkCgT;IAE1T,gBAAgB,EAAE;;;;;;;;;;;6NAWyM;IAE3N,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iIAsJsH;IAE/H,KAAK,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;+JA4GsJ;IAE7J,YAAY,EAAE,uBAAuB;IAErC,oBAAoB,EAAE,+BAA+B;IAErD,iBAAiB,EAAE,4BAA4B;CAChD,CAAC"}
+{"version":3,"file":"topics.js","sourceRoot":"","sources":["../../src/help/topics.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,uBAAuB,EAAE,MAAM,yBAAyB,CAAC;AAClE,OAAO,EAAE,+BAA+B,EAAE,MAAM,iCAAiC,CAAC;AAClF,OAAO,EAAE,4BAA4B,EAAE,MAAM,8BAA8B,CAAC;AAE5E,MAAM,CAAC,MAAM,WAAW,GAA2B;IACjD,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;kFA2BsE;IAEhF,iBAAiB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sGAqDiF;IAEpG,wBAAwB,EAAE;;;;;;;;;;;;;;;4FAegE;IAE1F,SAAS,EAAE;;;;;;;;;;;;;;;;;;;;;wEAqB2D;IAEtE,iBAAiB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4GAqCuF;IAE1G,eAAe,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2CZ;IAEL,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gOA4KgN;IAE9N,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;2OAuG+N;IAEzO,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mFAgCuE;IAEjF,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAuSL;IAEL,eAAe,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gCAwCa;IAE9B,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAuEJ;IAEL,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAkET;IAEL,eAAe,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;qGAyCkF;IAEnG,UAAU,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;0FA6B4E;IAExF,UAAU,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAgHP;IAEL,gBAAgB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gLA6F4J;IAE9K,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4TAkCgT;IAE1T,gBAAgB,EAAE;;;;;;;;;;;6NAWyM;IAE3N,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iIAsJsH;IAE/H,KAAK,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;+JA4GsJ;IAE7J,YAAY,EAAE,uBAAuB;IAErC,oBAAoB,EAAE,+BAA+B;IAErD,iBAAiB,EAAE,4BAA4B;CAChD,CAAC"}

package/build/skills/doing-work.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"doing-work.d.ts","sourceRoot":"","sources":["../../src/skills/doing-work.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,eAAO,MAAM,uBAAuB,QAqL5B,CAAC"}
+{"version":3,"file":"doing-work.d.ts","sourceRoot":"","sources":["../../src/skills/doing-work.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,eAAO,MAAM,uBAAuB,QA8M5B,CAAC"}

package/build/skills/doing-work.js

@@ -31,6 +31,31 @@ Before creating work, verify which role is accountable:
 
 **Domains define exclusive control, not expectations.** A domain means the role controls organizational assets in that area. Others must get permission to impact those assets.
 
+### Does the work fit the role?
+
+Work and governance are different requests, and capturing work is where they get confused. A request to do something is not a request to change the organization. But work that sits outside what a role was given is the signal that the governance is out of date, and nobody else is looking for it. So check on capture, and be sparing about what you raise.
+
+**Read the role before you write under it.** Its purpose and accountabilities say what it was given. Ask two questions:
+
+1. **Does this sit inside the role's purpose and accountabilities?** Interpret WIDELY. An accountability is a sentence, not a spec, and most work belongs to one if you read it generously. "Drafting and editing copy" covers a blog post, a landing page and an email without naming any of them.
+2. **Does it impact assets a domain covers that this role does NOT hold?** A domain is exclusive control, so acting on someone else's is not yours to decide. Publishing to a company website held by a Web domain, changing pricing held by Commercial, touching a customer list held by Sales.
+
+**When it impacts a domain the role does not hold:** do not just proceed. Raise a tension to the role or circle that holds the domain, requesting permission or the outcome, and say plainly in the capture that this part waits on them. Capture the rest of the work normally.
+
+**When it fits the purpose but no accountability names it:** capture the work, then offer, once, to add the accountability. One sentence, alongside what you already did, not a separate interrogation: "Captured it. This is the third publishing task under Marketing and no accountability mentions publishing. Want me to add one?"
+
+**When it fits an accountability read generously:** say nothing. This is most of the time.
+
+#### How hard to push
+
+Governance suggestions cost the user attention, and a workspace that asks for a governance change on every capture teaches people to ignore it. Match the resistance to how settled the governance is.
+
+**Young governance — go with the flow.** During onboarding, or where roles are freshly made and thin (few or no accountabilities, nothing edited since setup), the user is trying to get work running and a governance prompt is an interruption. Either fold the accountability in silently as part of the same act, or let it go and keep moving. Do not stop to ask.
+
+**Settled governance — be more discerning.** Where roles carry real accountabilities and governance has been shaped since setup, the structure is something the circle agreed and a gap in it is worth naming. Raise obvious gaps, still one sentence, still after doing the work.
+
+**Never** block the work on a governance question, ask twice about the same gap, or raise one for work that plausibly fits something already written.
+
 ### Strategy & Prioritization
 
 Strategy is stored in \`fields['circle.strategy']\` for sub-circles, or \`fields['anchor-circle.strategy']\` for the anchor circle. Strategy applies to all roles within the circle.

package/build/skills/doing-work.js.map

@@ -1 +1 @@
-{"version":3,"file":"doing-work.js","sourceRoot":"","sources":["../../src/skills/doing-work.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,MAAM,CAAC,MAAM,uBAAuB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqLtC,CAAC,IAAI,EAAE,CAAC"}
+{"version":3,"file":"doing-work.js","sourceRoot":"","sources":["../../src/skills/doing-work.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,MAAM,CAAC,MAAM,uBAAuB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA8MtC,CAAC,IAAI,EAAE,CAAC"}

package/build/skills/tension-processing.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"tension-processing.d.ts","sourceRoot":"","sources":["../../src/skills/tension-processing.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,eAAO,MAAM,+BAA+B,QA+LpC,CAAC"}
+{"version":3,"file":"tension-processing.d.ts","sourceRoot":"","sources":["../../src/skills/tension-processing.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,eAAO,MAAM,+BAA+B,QAiMpC,CAAC"}

package/build/skills/tension-processing.js

@@ -99,6 +99,8 @@ Then identify the **next physical action** — the very next concrete step.
 
 **Governance must be separate.** If a tension has both operational (pathways 1-4) AND governance needs (pathway 5), process operational work in the original tension and create a NEW tension for the governance proposal.
 
+**Spotting the governance half.** A request to DO something is not a request to CHANGE the organization, but work that falls outside what a role was given is how you find out the governance is stale. When work lands outside the role's accountabilities, or touches a domain the role does not hold, that is pathway 5 hiding inside pathway 3 or 4. See *Does the work fit the role?* in Doing Work for when to raise it and, more importantly, when to let it go: read accountabilities widely, stay quiet while governance is still young, and never hold up the work for it.
+
 ### When to Use Tensions vs Nest Tools
 
 **Tension tools** (\`nestr_create_tension\`, \`nestr_add_tension_part\`, etc.): Inter-role communication, governance proposals, elections, anything requiring consent. NEVER use tensions to create operational work (projects, tasks) under roles you or the user energize — that's what nest tools are for.

package/build/skills/tension-processing.js.map

@@ -1 +1 @@
-{"version":3,"file":"tension-processing.js","sourceRoot":"","sources":["../../src/skills/tension-processing.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,MAAM,CAAC,MAAM,+BAA+B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+L9C,CAAC,IAAI,EAAE,CAAC"}
+{"version":3,"file":"tension-processing.js","sourceRoot":"","sources":["../../src/skills/tension-processing.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,MAAM,CAAC,MAAM,+BAA+B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiM9C,CAAC,IAAI,EAAE,CAAC"}