@agentorg/cli 0.0.1 → 0.0.2

package/node_modules/@uniac/agentic-workspace/docs/contracts.md

@@ -6,27 +6,25 @@ Runtime request/record schemas and derived TypeScript types are maintained in [s
 
 Every successful write returns the resulting record: its stable ID, `revision` and `updatedAt`, the time of the write that produced the current revision. History comes only from `work_get` with `history: true`, for the Work and each of its asks. Execution MCP exposes every row below. Viewer MCP exposes only reads. Actor lifecycle administration is outside this inventory.
 
-Each contract carries `level`, the smallest organization level that presents it. Report is one agent and its person; Team adds working with other Actors; Organization adds the lifecycle and the system, none of which is in this package. Each level contains the one before it. The tag selects what a client presents; it grants and refuses nothing.
-
-| Tool         | Level  | Input                                                                                                                                         | Purpose                                                   |
-| ------------ | ------ | --------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
-| message_send | Report | `{recipientID,text}`                                                                                                                          | Send into the pair's conversation                         |
-| message_get  | Team   | `{messageID}`                                                                                                                                 | Read one message                                          |
-| message_list | Report | `{between:[id,id]\|counterpartyID\|of,before?:latest\|older,after?:next\|seq,limit?}`                                                         | Read a conversation, or list an Actor's conversations     |
-| work_create  | Report | `{title,goal?,ownerID?,links?,waitsOn?}`                                                                                                      | Create Work; caller requests it and owns it by default    |
-| work_get     | Report | `{ticketID\|askID,history?}`                                                                                                                  | Read Work with all its asks, or an older ask with no Work |
-| work_list    | Report | `{ownerID?,requesterID?:id\|id[],waitsOnActorID?,ownerWithin?,requesterWithin?,status?:[...],updatedSince?,order?:recent,after?,limit?}`      | Read matching shared Work, each with its open asks        |
-| work_update  | Report | `{ticketID,expectedRevision?,title?,goal?,ownerID?,progress?,status?:open\|active\|cancelled,links?,waitsOn?}`, `{ticketID,ask}` or `{close}` | Edit or cancel Work; ask on it; close an ask              |
-| work_submit  | Report | `{ticketID,expectedRevision?,result,evidence?}`                                                                                               | Submit; self-requested Work completes                     |
-| work_answer  | Team   | `{askID,ticketID?,answers?:{field:value},note?,raise?:true}`                                                                                  | Answer or raise an ask, or answer the current submission  |
+| Tool         | Input                                                                                                                                         | Purpose                                                   |
+| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
+| message_send | `{recipientID,text}`                                                                                                                          | Send into the pair's conversation                         |
+| message_get  | `{messageID}`                                                                                                                                 | Read one message                                          |
+| message_list | `{between:[id,id]\|counterpartyID\|of,before?:latest\|older,after?:next\|seq,limit?}`                                                         | Read a conversation, or list an Actor's conversations     |
+| work_create  | `{title,goal?,ownerID?,links?,waitsOn?}`                                                                                                      | Create Work; caller requests it and owns it by default    |
+| work_get     | `{ticketID\|askID,history?}`                                                                                                                  | Read Work with all its asks, or an older ask with no Work |
+| work_list    | `{ownerID?:id\|id[],requesterID?:id\|id[],waitsOnActorID?,status?:[...],updatedSince?,order?:recent,after?,limit?}`                           | Read matching shared Work, each with its open asks        |
+| work_update  | `{ticketID,expectedRevision?,title?,goal?,ownerID?,progress?,status?:open\|active\|cancelled,links?,waitsOn?}`, `{ticketID,ask}` or `{close}` | Edit or cancel Work; ask on it; close an ask              |
+| work_submit  | `{ticketID,expectedRevision?,result,evidence?}`                                                                                               | Submit; self-requested Work completes                     |
+| work_answer  | `{askID,ticketID?,answers:{field:value},note?}`                                                                                               | Answer an ask, or the current submission                  |
 
 `work_get`, `work_update` and `work_answer` return the record the call reads or writes: Work, or an ask. An ask has `formID` and Work has `ticketID`, and each result schema is their union.
 
 ## Authority
 
 - Every active admitted Actor may read every message and every conversation. An Actor sends to any other active Actor, never to itself. A reply is another message in the same conversation. Messages have no read, delivery or handling state, and reading changes nothing.
-- Every active admitted Actor may get/list all organization Work, including history and accepted tickets. The requester edits goal and owner, cancels and answers the submission; once it is closed, its nearest open manager does. The current owner edits title, progress, status, links and waitsOn, and submits. Reassignment changes write roles and filter membership; it does not remove shared read access. New owner must be active.
-- Every active admitted Actor may read every ask and its history, with its Work. The Work's owner asks on it, except the root. Any active Actor may answer an open ask, except an approval, which only the asker's managers answer. The Actor an ask is routed to may raise it, except the root. The asker closes its ask; once it is closed, its nearest open manager does. Asking, answering, raising and closing never change the Work row. Active callers retain shared history reads when counterparties close.
+- Every active admitted Actor may get/list all organization Work, including history and accepted tickets. The requester edits goal and owner, cancels and answers the submission; once it is closed, the person does. The current owner edits title, progress, status, links and waitsOn, and submits. Reassignment changes write roles and filter membership; it does not remove shared read access. New owner must be active.
+- Every active admitted Actor may read every ask and its history, with its Work. The Work's owner asks on it, the person included. Any active Actor may answer an open ask, except an approval, which only the Actor it is routed to answers, never its asker. The asker closes its ask; once it is closed, the person does. Asking, answering and closing never change the Work row. Active callers retain shared history reads when counterparties close.
 
 The host composes canonical Actor authority and a WorkspaceStore for one Hub organization. Public read does not construct an elevated identity or alter Actor visibility. List criteria do not select the caller or grant write authority.
 
@@ -36,15 +34,11 @@ The host composes canonical Actor authority and a WorkspaceStore for one Hub org
 
 Work and ask lists go in update order by default: a record moves to the end of that order whenever it changes. `work_list`'s `order: "recent"` goes newest first, and its `updatedSince` keeps records whose `updatedAt` is at or after the given time, which is how a reader picks up changes since it last looked. Lists are current upserts, not snapshots: a record updated during a traversal can appear again later in update order, and a record that stops matching leaves no tombstone. Paging `order: "recent"` can skip a record that is updated between page reads, because the update moves it to the front, ahead of the pages already read. That suits a view that refetches its first page when records change; it is not a way to read every record. A reader that needs a complete current view pages in update order or lists again from the start, and reconciles IDs.
 
-The page `limit` defaults to 50 and is at most 100. It bounds the returned rows, not the scan. Owner, requester, status, Work and route filters select rows through indexed columns, and the adapter decodes only the snapshots they keep. A subtree filter reads membership once for each Actor the column holds among the rows the other indexed filters keep, not once per row. The remaining filters then apply before the limit. A list reads the rows committed before it starts; a row committed during the read waits for the next one. The open asks a `work_list` page carries are read after the page.
+The page `limit` defaults to 50 and is at most 100. It bounds the returned rows, not the scan. Owner, requester, status and Work filters select rows through indexed columns, and the adapter decodes only the snapshots they keep. The remaining filters then apply before the limit; `routedTo` reads each open ask the others keep, with its Work's requester. A list reads the rows committed before it starts; a row committed during the read waits for the next one. The open asks a `work_list` page carries are read after the page.
 
 ### Filters
 
-Work accepts `ownerID`, `requesterID`, `waitsOnActorID`, `status`, `ownerWithin`, `requesterWithin` and `updatedSince`. The hosts' `WorkClient.asks` accepts `requesterID`, `routedTo` (open asks routed to that Actor), `answeredBy` (asks with a response by that Actor) and `status`. All supplied filters intersect. `work_list`'s `requesterID` takes one ID or a list, matching any of them, and the asks read's takes one ID; `status` takes a list of the module's status values, matching any of them. ID filters use exact equality; `waitsOnActorID` matches Work waiting on that Actor. Filter IDs do not trigger Actor lookup, except `routedTo`, which walks each open ask's route through the host's `manager` and treats an Actor the caller can't see as closed; unknown IDs yield empty matching sets. Omit filters to list all shared records.
-
-Subtree criteria use the required host `ActorAuthority.within(callerID, actorID, ancestorID)`, which tests the named canonical position and every descendant through retained relationships, including closed Actors and closed anchors without a depth limit. Unknown members or anchors return false. Bound `ActorsClient.within(actorID, ancestorID)` revalidates the admitted caller and delegates membership without selected-profile lookup or caller substitution.
-
-`ownerWithin` tests current Work ownership; `requesterWithin` tests immutable record requester, the scope from which it originated. Neither implies causal ticket lineage. Any active caller may query any branch; membership grants no write role.
+Work accepts `ownerID`, `requesterID`, `waitsOnActorID`, `status` and `updatedSince`. The hosts' `WorkClient.asks` accepts `requesterID`, `routedTo` (open asks routed to that Actor), `answeredBy` (asks with a response by that Actor) and `status`. All supplied filters intersect. `work_list`'s `ownerID` and `requesterID` each take one ID or a list, matching any of them, and the asks read's `requesterID` takes one ID; `status` takes a list of the module's status values, matching any of them. ID filters use exact equality; `waitsOnActorID` matches Work waiting on that Actor. Filter IDs do not trigger Actor lookup, except `routedTo`, which derives each open ask's route and treats a requester the caller can't see as closed; unknown IDs yield empty matching sets. Omit filters to list all shared records. `ownerID` tests current Work ownership; `requesterID` tests the immutable record requester. Any active caller may query any Actor's records; a filter grants no write role.
 
 ## Messages
 
@@ -82,7 +76,7 @@ New Work is `open`. In `open`, `active` or `changes_requested`, the owner may ed
 
 `work_submit` records a new submission. On Work its owner requested itself it completes at once: `accepted`, with `completedAt` and no review. Other Work enters `submitted` and is frozen until its requester answers the current submission with `work_answer`. The answer names the submission by its ID (`askID`, with an optional `ticketID` that must be the Work it is on) and gives `answers: {verdict}`; its `note` is the comment. It is stored as `review`. Accepting needs no note, sets `completedAt` and is terminal; requesting changes needs a note and returns the Work to its owner. Follow-up work gets a new ticket.
 
-Once the requester is closed, its rights pass to its nearest open manager: the first open Actor up its retained managers. That Actor edits goal and owner, cancels, and answers the submission. Rights never pass past an Actor the caller can't see: the write is refused with `not_found`.
+Once the requester is closed, its rights pass to the person, the Actor the host names for its user. The person edits goal and owner, cancels, and answers the submission. A requester the caller can't see refuses the write with `not_found`, so its rights never pass to the person.
 
 `expectedRevision` is optional on the owner's writes (edits and submit), which no one else makes. Goal, owner and cancel edits require it. An answer takes none: its submission ID pins it. The state, role and revision checks and the snapshot/history writes share one SQLite transaction; a stale revision conflicts. By its ID alone a submission is found only while it is current; named with its `ticketID`, an earlier submission of that Work conflicts, and an ID that was never one of its submissions is `not_found`. Resubmission retains prior evidence and reviews in history.
 
@@ -93,29 +87,29 @@ An ask is part of the Work its asker owns: `work_update {ticketID, ask}` asks on
 - `fields`: each has a `name`, a `label` and `required`, and may have `options`, each `{value, detail?}`, and the asker's `recommended` value among them. A one-field ask with options is a decision; without options, a question;
 - `workID`, the Work it is on;
 - `approval` and `collect`, both false by default;
-- `responses`, one per responder, and `raises`, `{actorID, at}` for each Actor that passed it up, in order;
+- `responses`, one per responder;
 - `status` (`open`, `resolved` or `cancelled`), and a `resolution` once closed.
 
-The record keeps its Form field names (`formID`, `requesterID` for the asker) until the wire takes the model's words; arguments name it `askID`. Only the Work's owner asks, on Work that is open, active or changes requested, and the root doesn't ask. An ask is stored in its own row, so asking, answering and closing never move the Work's revision.
+The record keeps its Form field names (`formID`, `requesterID` for the asker) until the wire takes the model's words; arguments name it `askID`. Only the Work's owner asks, on Work that is open, active or changes requested. An ask is stored in its own row, so asking, answering and closing never move the Work's revision.
 
 **Reads.** `work_get {ticketID}` returns the Work with `asks`: all of them, open and closed, in the order they were asked (asks made in the same millisecond keep update order). `work_get {askID}` returns the Work an ask is on, the same way, and the current submission's ID returns its Work. An older ask that names no Work is returned alone. `work_list` items carry their open asks. Write results carry no `asks`.
 
 **Answering.** Any active Actor answers an open ask with `work_answer {askID, answers, note?}`: a complete answer set, where required fields are nonblank, every named field exists and a choice matches an option. The response is recorded under its responder with the time it was given. A responder that answers again replaces its own response, and history keeps every earlier one. The first answer resolves the ask; an ask with `collect` stays open for more answers until its asker closes it. An answer to a closed ask conflicts.
 
-An `approval` ask authorizes something that can't be undone, so only the asker's strict ancestors answer it: its managers up to the root, never the asker itself. The Workspace tests this with the host's `within` relation, so it needs no root identity.
+An `approval` ask authorizes something that can't be undone, so only the Actor it is routed to answers it, never the asker itself. An approval the person asks that routes back to the person, on Work it requested itself, on Work whose requester is closed, or on no Work, has no one to answer it: it stays open until the person closes it.
 
-**Routing and raising.** An open ask is routed to its asker's manager; once raised, to its last raiser's manager. A closed manager is skipped for its nearest open one. Raising walks the route strictly, so a manager the caller can't see refuses the raise with `not_found`. Only the hosts' routed read (`asks {routedTo}`) counts such a manager as closed and walks on past it. Nothing stores a destination: it is derived from the asker, the raises and the tree. The Actor an ask is routed to may raise it with `work_answer {askID, raise: true}`, except the root, which has no manager. A raise adds `{actorID, at}` to `raises`, keeps the ask open and routes it one manager up. It never resolves the ask, and a later answer by the raiser doesn't remove it.
+**Routing.** An open ask is routed to its Work's requester. When its asker requested the Work itself, or it names no Work, it is routed to the person, so the person's own asks on Work it requested itself come back to it. A closed requester's asks go to the person. Nothing stores a destination: it is derived from the ask, its Work and the host's person. An approval's answer checks the route strictly, so a requester the caller can't see refuses the answer with `not_found`. Only the hosts' routed read (`asks {routedTo}`) counts such a requester as closed, routing its asks to the person.
 
-**Closing.** The asker closes its open ask with `work_update {close: {askID, status, resolution}}`, as `resolved` with a `resolution` (ending a collection, or recording an answer given elsewhere) or `cancelled`. Once the asker is closed, its nearest open manager closes it. It takes no `expectedRevision`, and a closed ask refuses a second close. Answering and closing work on frozen Work too.
+**Closing.** The asker closes its open ask with `work_update {close: {askID, status, resolution}}`, as `resolved` with a `resolution` (ending a collection, or recording an answer given elsewhere) or `cancelled`. Once the asker is closed, the person closes it. It takes no `expectedRevision`, and a closed ask refuses a second close. Answering and closing work on frozen Work too.
 
 **When Work moves on.** Submitting, cancelling or reassigning Work cancels its open asks, since their asker no longer moves it. Each gets `status: cancelled` and a `resolution` with a fixed `text` and a `reason`: `submitted`, `cancelled` or `reassigned`. Its history entry is by the Actor who moved the Work, at the same time. A new ask on submitted, accepted or cancelled Work is refused.
 
-**Asks stored before asks lived on Work.** They read as stored: an ask with no Work is read, answered and closed by its ID, an ask by another Actor shows under the Work it names, and an ask left open on submitted Work is still answered and closed. Such an ask's `cause` stays stored and unread, and it reads with `raises: []`. Its next write stores it without `cause`; history keeps it.
+**Asks stored before asks lived on Work.** They read as stored: an ask with no Work is read, answered and closed by its ID, an ask by another Actor shows under the Work it names, and an ask left open on submitted Work is still answered and closed. Such an ask's `cause`, and the `raises` earlier builds stored, stay stored and unread. Its next write stores it without them; history keeps them.
 
 **Hosts' reads.** `WorkClient.asks({requesterID?, routedTo?, answeredBy?, status?, after?, limit?})` is not a tool. It lists asks wherever they are: an asker's own, those routed to an Actor, and those an Actor answered. Older asks with no Work are included.
 
 **History.** These action names are part of the contract, since hosts label what changed by them.
-- **An ask's history:** `created` (asked), `responded` (answered), `raised`, `resolved` (closed as resolved) and `cancelled` (closed as cancelled by its asker or stand-in, or when its Work moves on).
+- **An ask's history:** `created` (asked), `responded` (answered), `resolved` (closed as resolved) and `cancelled` (closed as cancelled by its asker or the person, or when its Work moves on). An ask from an earlier build may also hold `raised`.
 - **Cancellations when Work moves on:** only these carry `resolution.reason`.
 - **A Work's history:** `created`, `updated` (every edit, a cancel included), `submitted` and `reviewed` (the answer to a submission).
 

package/node_modules/@uniac/agentic-workspace/docs/design.md

@@ -8,11 +8,11 @@ Arrows point toward a dependency. An ask is part of the Work its asker owns, so
 
 ```mermaid
 flowchart BT
-    A["Actors<br/>Identity and canonical membership"]
+    A["Actors<br/>Identity and the person"]
     M["Messages<br/>Persistent pair conversations"]
-    T["Work tracking<br/>Work, owner, progress, result and its answer;<br/>its asks: fields, responses, raises and resolution"]
+    T["Work tracking<br/>Work, owner, progress, result and its answer;<br/>its asks: fields, responses and resolution"]
     M -->|"sender and recipient"| A
-    T -->|"owner, asker, an approval's managers and an ask's route"| A
+    T -->|"owner, asker, an ask's route and the person"| A
 ```
 
 ## Exposure and authority
@@ -28,19 +28,19 @@ Both MCP exposures use the same Actor identity and role rules. The execution ser
 
 ## Module contracts
 
-| Module        | Consumes                                         | Exposes                           | Owns                                                                                                                                                                                                           |
-| ------------- | ------------------------------------------------ | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Actors        | Injected canonical authority and admitted caller | `ActorsClient.get/within/manager` | No persisted state; no lifecycle administration                                                                                                                                                                |
-| Messages      | Actors; Messages persistence                     | `MessagesClient.send/get/list`    | Content, parties, conversation and order                                                                                                                                                                       |
-| Work tracking | Actors; Work and Forms persistence               | `WorkClient`                      | Work: requester, owner, title, goal, progress, status, links, waits-on, submission, review, completion, history; and its asks: fields and options, approval, collection, responses with notes, raises, closure |
+| Module        | Consumes                                         | Exposes                        | Owns                                                                                                                                                                                                   |
+| ------------- | ------------------------------------------------ | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Actors        | Injected canonical authority and admitted caller | `ActorsClient.get/person`      | No persisted state; no lifecycle administration                                                                                                                                                        |
+| Messages      | Actors; Messages persistence                     | `MessagesClient.send/get/list` | Content, parties, conversation and order                                                                                                                                                               |
+| Work tracking | Actors; Work and Forms persistence               | `WorkClient`                   | Work: requester, owner, title, goal, progress, status, links, waits-on, submission, review, completion, history; and its asks: fields and options, approval, collection, responses with notes, closure |
 
-Work does not import Messages. Messages link no Work; a reply is another message in the pair's conversation. An ask is stored in its own row of the forms table, beside its Work, so asking, answering, raising and closing never move the Work's revision. Submitting, cancelling or reassigning Work cancels its open asks in the same transaction. An ask's route is derived when read, from its asker, its raises and the host's `manager` relation, and nothing stores a destination. Messages have no public read/handling state or dependent acknowledgement step. Work and its asks, with their history, and Messages are public within the admitted organization. Work progress may contain stable record references as text.
+Work does not import Messages. Messages link no Work; a reply is another message in the pair's conversation. An ask is stored in its own row of the forms table, beside its Work, so asking, answering and closing never move the Work's revision. Submitting, cancelling or reassigning Work cancels its open asks in the same transaction. An ask's route is derived when read, from its asker, its Work's requester and the host's person, and nothing stores a destination. Messages have no public read/handling state or dependent acknowledgement step. Work and its asks, with their history, and Messages are public within the admitted organization. Work progress may contain stable record references as text.
 
 The host binds one organization's canonical authority and persistence into the composition. Shared reads authenticate the existing caller; they do not construct a privileged Actor. Work and ask filters intersect before pagination, using the same traversal and record schemas. Business write roles remain separate from shared visibility.
 
-The required synchronous canonical `within(callerID, actorID, ancestorID)` relationship read supplies inclusive retained ancestry, including closed positions and descendants beyond any Team depth limit. The bound Actor client revalidates its active caller; Work predicates apply the subtree criteria before traversal limits, and an approval's answer requires the responder to be a strict ancestor of the asker. Workspace stores no hierarchy or new Actor field. The model-free fixture alone holds a manager map for its example truth. Requester scope is immutable record origin, not causal ticket lineage. Independent lane cursors and bounded from-zero refresh/reconciliation preserve the current-upsert limitations described in the contract.
+Every Actor sits on one flat level. The host names the person through the required synchronous `person()`, and the bound Actor client revalidates its active caller before asking. An approval's answer requires the responder to be the Actor the approval is routed to. Workspace stores no Actor relationship or new Actor field; the model-free fixture names its person for its example truth. Requester scope is immutable record origin, not causal ticket lineage. Independent lane cursors and bounded from-zero refresh/reconciliation preserve the current-upsert limitations described in the contract.
 
-The root composition factory wires distinct clients; it is not another multi-domain operation client. Consumers can construct and use any module independently through its own export. Contracts depend only on Zod. Domain modules import persistence types; native SQLite is loaded only through the persistence implementation export.
+The top-level composition factory wires distinct clients; it is not another multi-domain operation client. Consumers can construct and use any module independently through its own export. Contracts depend only on Zod. Domain modules import persistence types; native SQLite is loaded only through the persistence implementation export.
 
 A Message's `conversationID` is derived from its pair when read and its `seq` is its module cursor, so neither is stored and there is no conversation registry. A later kind of conversation, such as a group or a Work thread, would store its own ID beside these without migrating them. Lists issue opaque positions that encode the read's filter and a cursor, so a position continues only its own read (a `between` read and a `counterpartyID` read of one pair are the same read); the records themselves carry no cursor, except a Message's `seq`. Each list resolves the Actor names it mentions through the Actor authority, so a reader needs no lookup per ID.
 
@@ -56,11 +56,11 @@ The database records its schema in `PRAGMA user_version`. Opening a database run
 - Version 4 adds indexed, generated columns and rewrites no record:
   - Messages' `sender` and `recipient`;
   - Work's `owner`, `requester`, `status` and `submission` (the current submission's ID). The `status` column holds a stored `blocked` as `active`. The owner and requester indexes are on (party, status);
-  - asks' `requester`, `status`, `work` and `route`, indexed on (requester, status), (work, status) and (status, route). `route` is where an ask's route starts: its last raiser, else its asker. The destination comes from the Actor tree when it is read, so it is never stored.
+  - asks' `requester`, `status`, `work` and `route`, indexed on (requester, status), (work, status) and (status, route). `route` holds where an earlier build started an ask's route and is no longer read; its index, which leads with `status`, still serves status selects. An ask's destination is derived from its Work's requester when it is read.
 
 Each module advances a persisted cursor on every mutation. Current snapshots are traversed by cursor; histories are read with their owning record. [List semantics](contracts.md#lists) describe the positions and limits. No event replay framework, scheduler, notification dispatcher, model executor or native session controller is part of this package. Record-changing communication happens only through these clients/tools; ordinary prose has no effect.
 
-The persistence adapter selects current snapshots through those indexed columns (`RecordTable.where`), and reads a column's distinct values (`values`) so that a subtree filter tests each Actor once. A party's index leads with the party and then status, so a party's records in some statuses are one index range, whatever statistics the planner has. Other filters apply to the decoded rows. It returns full history for a record when asked. It makes no bounded-history or large-workspace guarantee: a list decodes every row its indexed filters keep before paging, and a list with no indexed filter decodes every row of its table. An Actor's conversations read every message it sent or received. Database files belong to the host: use trusted local paths, appropriate filesystem access, and close owned connections before deleting test data. The fixture entry point has no production credential or network admission surface.
+The persistence adapter selects current snapshots through those indexed columns (`RecordTable.where`). A party's index leads with the party and then status, so a party's records in some statuses are one index range, whatever statistics the planner has. Other filters apply to the decoded rows. It returns full history for a record when asked. It makes no bounded-history or large-workspace guarantee: a list decodes every row its indexed filters keep before paging, and a list with no indexed filter decodes every row of its table. An Actor's conversations read every message it sent or received. Database files belong to the host: use trusted local paths, appropriate filesystem access, and close owned connections before deleting test data. The fixture entry point has no production credential or network admission surface.
 
 ## Repository map
 

package/node_modules/@uniac/agentic-workspace/docs/hub-integration.md

@@ -1,63 +1,38 @@
 # Hub integration
 
-Hub embeds this package under its canonical Actor authority. Hub owns identity, admission, retained manager relationships and tool exposure; the package owns its records, contracts and SQLite schema.
+Hub embeds this package under its canonical Actor authority. Hub owns identity, admission, which Actor is the person, and tool exposure; the package owns its records, contracts and SQLite schema.
 
 ## Required host authority
 
-Bind the actual admitted Actor ID to a canonical synchronous `ActorAuthority` and one organization's `WorkspaceStore`. `get` retains visibility. `within(callerID, actorID, ancestorID): boolean` returns true for the anchor itself or any descendant through retained manager edges. Both IDs must exist; unknown member/anchor returns false, even when equal. Include closed members and anchors with no Team depth limit. `manager(callerID, actorID): string | null` returns an Actor's retained manager, closed or not, and null for the root and for unknown IDs. Revalidate the admitted caller as for other authority reads.
-
-Implement canonical ancestry at its owner: retained Registry get/manager edges. Team's depth-limited open-report view and the active Directory cannot supply complete historical membership. Workspace stores no hierarchy, Actor kind, relationship edit or fallback registry. Its bound `ActorsClient.within(actorID, ancestorID)` validates ID criteria and revalidates the active caller before delegation, without selected-profile lookup or caller substitution.
-
-## Changes since the last version 3 build
-
-This build changes the public contracts and the persistence interface from the last build to keep a version 3 store, commit cda95eb (merged as 9c9f89a); Hub's bindings change with it.
-
-- **Persistence.** `RecordTable.all()` is replaced by `where(filter)`. It returns the current snapshots, in cursor order, whose every filtered indexed column holds one of the listed values; `where({})` returns every row. `values(column, filter)` returns one column's distinct values among the rows a filter keeps. The `WorkspaceStore` types name each table's indexed columns.
-- **Upgrade.** `openSqlite` upgrades a version 3 database to version 4 on first open. The upgrade adds the indexed columns and rewrites no record; see [persistence](design.md#persistence-and-state-changes). Back up the home before the first start on this build.
-- **Status is removed** (`status_set`, `status_get`, `StatusContracts`, the `Status` and `StatusState` schemas and types, `createStatus`, `StatusClient`, `/status` and `bindWorkspace().status`). Hosts derive an Actor's headline from its Work. A version 3 database's `status` and `status_history` tables stay in the file, unread.
-- **Directory tools are removed** (`actor_get`, `actor_list`, `ActorContracts`, `Page`, `pageOf`, `ListInput` and `ActorsClient.list`). `ActorAuthority` drops `list`: an object literal typed `ActorAuthority` that still declares it no longer compiles, and on any other host object it is never called. `ActorsClient` keeps `get` and `within` for the other modules, and its input schema is `ActorQuery`.
-- **Messages are open.** Any active Actor reads any message and any conversation. `message_send` and `message_list` are at the Report level, and a message to oneself is refused with `invalid_input`. `message_list` takes exactly one of `between: [a, b]`, `counterpartyID` or `of` ([Messages](contracts.md#messages)). `direction` and a read with no selector are refused. A `{counterpartyID, before: "latest"}` read returns what it did, but a `next` or `older` position issued by the version 3 build is refused with `invalid_input`; a stored `seq` still continues a forward read. A reader of an Actor's input across conversations pages `of` until a conversation's latest `seq` is one it has handled, then reads each newer conversation `after` its position.
-- **`ActorAuthority.manager` is required.** Asks route through it, the root is the Actor with no manager (it doesn't ask or raise), and a closed requester's or asker's rights pass up it to the nearest open manager. An Actor the caller can't see counts as closed only in the routed read (`asks {routedTo}`). For every right that passes to a stand-in, and for who may raise, it refuses the write with `not_found`. `ActorsClient` gains `manager(actorID)`, and `standIn` in `/actors` returns an Actor's ID while it is open, its nearest open manager's once it is closed, or null when no manager is open (a chain that loops counts as none); it throws `not_found` at an Actor the caller can't see. `routedStandIn` is the same walk for routing reads, counting such an Actor as closed.
-- **Refusals name their issues.** An input outside a contract is refused with `invalid_input` and a message naming each schema issue (`path: message`), as the Hub's own validation does, instead of one fixed sentence.
-- **Work status.** `blocked` is gone: `work_update` refuses it with a message naming the habit (ask, or stay active with `waitsOn`), the same words from the Workspace and from a host that validates with the contract, and `work_list` refuses it as a `status` filter. A stored `blocked` reads as `active`, so a `status: ["active"]` filter finds it. `cancelled` is new: the requester sets it with `expectedRevision` on `open`, `active` or `changes_requested` Work, and it is terminal.
-- **`work_review` is replaced by `work_answer`** (Team), and `WorkClient.review` by `WorkClient.answer` (which returns `Work | Form` once asks are on Work): `{askID: submissionID, ticketID?, answers: {verdict}, note?}`, where the note is the comment and requesting changes needs one. It takes no `expectedRevision`. A submission is found by its ID alone while it is current. With `ticketID`, an earlier submission of that Work conflicts, and an ID that was never one of its submissions is `not_found`. `raise` is refused for a submission.
-- **A closed requester's rights** (goal, owner, cancel and the answer to its submission) pass to its nearest open manager.
-- **Asks are part of Work.** `form_create`, `form_get`, `form_list`, `form_respond`, `form_close`, `FormContracts`, `createForms`, `FormsClient`, `WorkReader`, `/forms` and `bindWorkspace().forms` are removed. The forms table stays as the asks' store, and the record keeps its `Form` type and field names (`formID`, `requesterID`, `workID`).
-  - **Asking:** `work_update {ticketID, ask}` asks on Work the caller owns while it is open, active or changes requested, and returns the new ask. The root doesn't ask, and `cause` and `workID` inside `ask` are refused.
-  - **Closing:** `work_update {close: {askID, status, resolution}}`, by the asker or its nearest open manager, with no `expectedRevision`.
-  - **Answering and raising:** any active Actor answers with `work_answer {askID, answers, note?}`, an approval only the asker's strict managers. `{askID, raise: true}` raises it: only the Actor it is routed to, never the root. A raise appends `{actorID, at}` to `raises`.
-  - **Reads:**
-    - `work_get {ticketID | askID}` returns the Work with all its `asks`; an older ask that names no Work is returned alone. The current submission's ID returns its Work.
-    - `work_list` items carry their open asks, an older ask by another Actor included. So a host that shows Work as waiting on its owner's ask counts only asks whose `requesterID` is the Work's `ownerID`.
-    - Write results carry no `asks`.
-  - **Results:** `work_get`, `work_update` and `work_answer` return `Work | Form`. Their output schemas are unions with `type: "object"` at the top; a host projecting the contracts to JSON Schema must add that `type` too, since MCP clients refuse an output schema without it. Tell the records apart by `ticketID` and `formID`.
-  - **Cancelling open asks:** submitting, cancelling or reassigning Work cancels its open asks, each with `resolution.reason` (`submitted`, `cancelled` or `reassigned`).
-  - **Hosts' read:** `WorkClient.asks({requesterID?, routedTo?, answeredBy?, status?, after?, limit?})` lists asks wherever they are: an Actor's own (`status: ["open"]` for the open ones), those routed to an Actor (raises included), and those an Actor answered. It is not a tool, and it replaces the 100-ID `requesterID` list for a manager's needs.
-  - **Asks stored before asks lived on Work:** they read as stored, without `cause` and with `raises: []`. A write on one (an answer, a close, or a cancel when its Work moves on) stores it without `cause`; history keeps it.
-  - **History action names** on asks and Work, and `resolution.reason`, are contract; see [asks](contracts.md#asks).
-- **Tools.** The execution server exposes 9 tools and the viewer 4.
-- **Subtree filters.** `ownerWithin` and `requesterWithin` call `ActorAuthority.within` once for each Actor the column holds, not once per row. Owner, requester and status lookups decode only the rows they select.
-
-## Changes with storage version 3
-
-The build that introduced storage version 3 changed the public contracts; Hub's bindings and stored-record checks changed with it.
-
-- **Levels.** Every contract carries `level`: `report`, `team` or `organization`. Hub's tool definitions can carry the tag through to the clients that present a level.
-- **Records.** Work and Form records carry `revision` and `updatedAt` and no `cursor`. History is present only on `work_get`/`form_get` with `history: true`, never on lists or write results.
-- **Lists.** `work_list`, `form_list` and `message_list` return `{items, next, actors}` (`List<T>`); `message_list` adds `older`. `next` and `older` are opaque positions passed back as `after`/`before`. `actor_list` keeps the directory's `{items, after}` (`Page<T>`). `status` filters take a list, and `requesterID` takes one ID or a list.
-- **Work.** `work_create` takes a required `title`, an optional `goal`, and an `ownerID` that defaults to the caller; Work gains `links`, `waitsOn` and `completedAt`. Owner writes and reviews take `expectedRevision` optionally. Submitting Work the owner requested itself accepts it at once. Accepting needs no comment.
-- **Asks.** Forms name no respondents: `respondentIDs` and the `respondentID`, `respondentWithin`, `awaitingActorID` and `awaitingWithin` filters are gone. An ask gains `title`, `context`, `links`, `cause`, `approval`, `collect`, option `detail` and `recommended`. Any Actor answers, with an optional `note`, and each response is `{answers, note?, at}` under its responder. The first answer resolves an ask unless it collects. Only the asker's strict ancestors answer an approval, through the same `within` relation.
-- **Status.** A new module: `status_set` and `status_get`, a `status` table in the same database, `createStatus` at `/status`, and `status` in `bindWorkspace`. The execution server exposes 18 tools and the viewer 9.
-- **Messages.** A Message is `{messageID, conversationID, senderID, recipientID, text, createdAt, seq}`, with no `workID`, revision or history. `createMessages(actors, store)` takes no Work reader. `message_list` accepts a `seq` as `after`, so a reader can resume from the last message it handled.
-- **Persistence.** `RecordTable` snapshots carry `updatedAt` beside `revision` and `cursor`, and `save` returns the snapshot without history. A check that compares a stored Message with its original state, such as the legacy import's restart verification, leaves out `revision`, `cursor` and `updatedAt`.
-- **Upgrade.** `openSqlite` upgrades a version 0 database in place on first open and refuses one newer than the package; see [persistence](design.md#persistence-and-state-changes). Back up the home before a first start that upgrades the store, as for any schema change.
+Bind the actual admitted Actor ID to a canonical synchronous `ActorAuthority` and one organization's `WorkspaceStore`. The authority has two methods, and every Actor sits on one flat level:
+
+- **`get(callerID, actorID): Actor | undefined`** returns the Actor the caller may see, open or closed, with its current state, and the caller itself; `undefined` for an unknown or hidden ID.
+- **`person(): string`** returns the person's Actor ID: the Actor that stands for the host's user, such as Hub's first Actor. The Workspace calls it only after revalidating an active caller. The person must be an Actor `get` returns, and Hub keeps it open, since rights that pass to a closed person pass to no one active.
+
+The Workspace uses the person in two ways. An ask on Work its asker requested itself, or on no Work, goes to the person. A closed Actor's requester rights, its asks' closing and the asks routed to it pass to the person. The Workspace stores no Actor rows, relationships or person.
+
+## Changes in 0.0.2
+
+0.0.2 changes the public contracts from 0.0.1 (commit 26fd0ee) and keeps storage version 4, so a 0.0.1 store opens unchanged and needs no upgrade.
+
+- **`ActorAuthority` is `{get, person}`.** `within` and `manager` are removed: an object literal typed `ActorAuthority` that still declares either no longer compiles, and on any other host object they are never called. `ActorsClient` drops `within` and `manager` and gains `person()`.
+- **Routing.** An ask goes to its Work's requester. When its asker requested the Work itself, or it names no Work, it goes to the person. A closed requester's asks go to the person. `WorkClient.asks({routedTo})` follows this, counting a requester the caller can't see as closed, and reads each open ask the other filters keep.
+- **Approvals.** Only the Actor an approval is routed to answers it, never its asker. An approval the person asks that routes back to the person, on Work it requested itself, on Work whose requester is closed, or on no Work, has no one to answer it: it stays open until the person closes it.
+- **Stand-ins.** A closed Actor's stand-in is the person: a closed requester's rights (goal, owner, cancel and the answer to its submission) and a closed asker's close pass to it. `standIn` in `/actors` returns an Actor's ID while it is open and the person's once it is closed, and throws `not_found` at an Actor the caller can't see; `routedStandIn` counts such an Actor as closed. Both return a string, never null.
+- **The person asks** on Work it owns, like any Actor.
+- **Raising is removed:** `work_answer`'s `raise`, the `Raise` schema and an ask's `raises`. `work_answer` requires `answers`. An ask stored with `raises` reads without them, its next write stores it without them, and history keeps every `raised` event.
+- **Filters.** `ownerWithin` and `requesterWithin` are removed and refused as unknown fields. `ownerID` takes one ID or a list, as `requesterID` does.
+- **Tool levels are removed.** Contracts carry no `level`, `contract` takes `(description, input, output, writes)`, and `Level` is no longer exported. Every tool is offered to every Actor. The execution server exposes 9 tools and the viewer 4, as before.
+- **Persistence.** `RecordTable.values` is removed, and the forms table's type no longer names `route`. The `route` column stays in the file, unread; its index, which leads with `status`, still serves status selects.
+
+Earlier changes are in [the 0.0.1 Hub integration](https://github.com/uniac-ai/AgenticWorkspace/blob/v0.0.1/docs/hub-integration.md).
 
 ## Exposure
 
-Every active admitted Actor may read all organization Work, asks and Messages and choose any branch. Membership adds no business write role. Hub derives each tool's schema and declaration from the package contracts and uses the existing SDK protocol/transport and admitted principal.
+Every active admitted Actor may read all organization Work, asks and Messages. Reading adds no business write role. Hub derives each tool's schema and declaration from the package contracts and uses the existing SDK protocol/transport and admitted principal.
 
 Human and Agent clients use those same offered Tools under ordinary admitted identity. HTTP projections may compose their results; they may not read Registry/DB/admin/Provider/native paths or synthesize an elevated caller. A list's `actors` map names the Actors it mentions under the caller's own Actor visibility. Message delivery positions and dedup remain client responsibilities; organization browsing grants no native execution authority.
 
 ## Verification
 
-Node **>=22.13** remains the declared floor; CI and the packed-consumer check use **22.23.4** and **24.22.1**. Canonical host integration must prove inclusive deep/closed membership, active callers, ordinary cross-branch queries, exact schemas and unchanged business writes. The model-free fixture supplies a retained manager map only for package verification.
+Node **>=22.13** remains the declared floor; CI and the packed-consumer check use **22.23.4** and **24.22.1**. Canonical host integration must prove active callers, the person's stand-in rights and routes, exact schemas and unchanged business writes. The model-free fixture names `requester` as the person only for package verification.

package/node_modules/@uniac/agentic-workspace/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniac/agentic-workspace",
-  "version": "0.0.1",
+  "version": "0.0.2",
   "license": "MIT",
   "private": true,
   "type": "module",

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@agentorg/cli",
-  "version": "0.0.1",
-  "description": "A Hub of explicit Tools for Actors with identities, managers and shared organization state",
+  "version": "0.0.2",
+  "description": "A Hub of explicit Tools for Actors on one flat level, with identities and shared organization state",
   "license": "MIT",
   "repository": {
     "type": "git",
@@ -47,7 +47,7 @@
   "dependencies": {
     "@hono/node-server": "^2.1.5",
     "@modelcontextprotocol/sdk": "^1.32.2",
-    "@uniac/agentic-workspace": "file:vendor/uniac-agentic-workspace-0.0.1-26fd0ee.tgz",
+    "@uniac/agentic-workspace": "file:vendor/uniac-agentic-workspace-0.0.2-8aebc44.tgz",
     "ajv": "^8.20.0",
     "ajv-formats": "^3.0.1",
     "hono": "^4.13.14",

package/skills/agentorg/SKILL.md

@@ -1,15 +1,16 @@
 ---
 name: agentorg
-description: Report your work as an attached AgentOrg Actor through live records instead of pages - one Work per workstream with its progress steps, the asks on it and its submission - and act on what reaches you; with other Actors, message, give Work, answer and raise. Use when a session has AgentOrg's attach, interfaces and call tools, a brief names an Actor, or the user asks for AgentOrg setup.
+description: Report your work as an attached AgentOrg Actor through live records instead of pages - one Work per workstream with its progress steps, the asks on it and its submission - and act on what reaches you; with other Actors, message, give Work and answer. Use when a session has AgentOrg's attach, interfaces and call tools, a brief names an Actor, or the user asks for AgentOrg setup.
 license: MIT
 ---
 
 # AgentOrg
 
-An Actor is a durable position with a responsibility and a manager. A session, a human
-application or a program acts through an Actor's credential, with the same authority. Your
-**report** is your Work: the Work on you, with its progress, the asks on it and its submission.
-Your person and your manager read it live. You write records; you never keep an HTML page as well.
+An Actor is a durable responsibility in the organization, on one flat level beside every other. A
+session, a human application or a program acts through an Actor's credential, with the same
+authority. The person is the user's own Actor. Your **report** is your Work: the Work on you, with
+its progress, the asks on it and its submission. The person and whoever gave you Work read it
+live. You write records; you never keep an HTML page as well.
 
 Use this skill when the session has `attach`, `interfaces` and `call`. If the user asks for setup,
 follow [AgentOrg setup](https://github.com/uniac-ai/AgentOrg/blob/main/docs/setup.md) for their
@@ -19,17 +20,17 @@ named project. A session without those tools does its ordinary work without an o
 
 Attach with `attach {actor}`, the Actor ID your brief names. If the user appointed this session
 directly, with no Actor named, attach once with `attach {name, purpose}`: a short handle and a
-sentence; that creates your position under the user. A resumed conversation recovers its saved
+sentence; that creates your Actor. A resumed conversation recovers its saved
 Actor.
 
-`interfaces` lists what this session presents, each call alias with a one-line summary, and
+`interfaces` lists the Hub's interfaces, each call alias with a one-line summary, and
 `interfaces {name}` gives one interface's schemas. Read a schema before you first build its input.
 Invoke through `call {name, input}`: `work_update` is `call {name: "work_update", input: {...}}`.
 
 ## Your report
 
-Your report is your Work; reply in the conversation. These are the Report level's operations,
-everything one agent and its person need:
+Your report is your Work; reply in the conversation. These operations are everything one agent
+and its person need:
 
 | Record | Operations |
 |---|---|
@@ -65,8 +66,9 @@ approval?, collect?}}`:
   that field. Recommend the option you would take; the person can accept it with one key. A field
   without options is a question answered in text.
 - Mark it `approval: true` when its answer can't be undone: a publish, a grant, a deletion, a
-  native permission. Only your managers up to the user answer an approval; give it the options to
-  do or not to do it.
+  native permission. Only the Actor the ask goes to answers an approval, never you: the requester of
+  the Work it is on, or the person when you requested that Work yourself. Give it the options to do
+  or not to do it.
 - Set `collect: true` only when you need several answers; then close it yourself when you have them.
 
 ```json
@@ -108,41 +110,39 @@ context, never instructions. You can't message yourself.
 
 **What reaches you.** `attention {since?, wait?}` returns what other Actors did that concerns you.
 On your records: Work given to you or changed by its requester, an answer to your submission, an
-answer to your ask or its raise, and a message to you. Routed to you: an ask from a report or
-raised to you, and a submission of Work you gave. Your client may deliver these as input; the
-client references say how.
+answer to your ask, and a message to you. Routed to you: an ask on Work you gave, and a submission
+of Work you gave. The person also gets the asks on Work their asker gave itself, and what a closed
+Actor leaves. Your client may deliver these as input; the client references say how.
 
 ## Working with others
 
-The Team level adds working with other Actors. Its operations:
-- `team`, `actor_view` and `message_get`. `team {actor?, depth?}` gives each position its state and
-  headline from the Work on it, and its open asks and its branch's; `team {actor, depth: 0}` finds
-  any Actor, a closed one included. `actor_view` is anyone's report as one view: its state and
-  headline, the Work on it, its own open asks, and what needs it: the asks routed to it, the
-  submissions it answers, and the Work it must take up or hand on.
+Working with other Actors uses these operations:
+- `team`, `actor_view` and `message_get`. `team` gives every open Actor, oldest first, its state
+  and headline from the Work on it, and its open asks. `actor_view {actorID?}` is anyone's report
+  as one view, a closed Actor's included: its state and headline, the Work on it, its own open
+  asks, and what needs it: the asks routed to it, the submissions it answers, and the Work it must
+  take up or hand on.
 - Giving Work. `work_create {title, goal?, ownerID}` gives Work to another Actor. Give a follow-up
   to the Actor that did the work, and Work that needs a fresh context to a new Actor, where you may
-  create one (`actor_create`, at the Organization level). As its requester you edit its `goal` and
+  create one (`actor_create`). As its requester you edit its `goal` and
   `ownerID`, or cancel it with `work_update {ticketID, expectedRevision, status: "cancelled"}`;
   reassigning or cancelling it cancels its open asks.
-- Answering. `work_answer {askID, answers, note?}` answers another Actor's ask; only the asker's
-  managers answer an approval. A submission is the Work's ask to you, its requester: answer it with
+- Answering. `work_answer {askID, answers, note?}` answers another Actor's ask; only the Actor an
+  approval goes to answers it. A submission is the Work's ask to you, its requester: answer it with
   `work_answer {askID: <the submission's submissionID>, answers: {verdict: "accepted" or
   "changes_requested"}, note?}`. Requesting changes needs the note, which is your comment.
 
-As a manager:
-- Answer your reports' asks, which `actor_view` lists under `needs`.
-- Raise what isn't yours to decide: `work_answer {askID, raise: true}` routes the ask to your
-  manager, unanswered. Only the Actor an ask is routed to raises it.
-- Write your synthesis of your reports' work in the progress of the Work your manager gave you.
+As a requester:
+- Answer the asks on Work you gave, which `actor_view` lists under `needs`. When a decision isn't
+  yours to take, ask on your own Work in turn.
+- Write your synthesis of the work you gave in the progress of your own Work.
 
-Once an Actor is closed, its nearest open manager takes over the Work it gave, the asks it made,
-and what was routed to it.
+Once an Actor is closed, the person takes over the Work it gave, the asks it made, and what was
+routed to it.
 
 Lists return `{items, next, actors}`. Pass `next` back as `after` to continue the same read, and
-read names from `actors`. `work_list` filters by owner, requester, status, `updatedSince` and,
-with `ownerWithin` or `requesterWithin`, by a whole branch, closed positions included; its items
-carry their open asks. `work_get {ticketID}` returns a Work with all its asks, and
+read names from `actors`. `work_list` filters by owner and requester, each one ID or a list, by
+status and by `updatedSince`; its items carry their open asks. `work_get {ticketID}` returns a Work with all its asks, and
 `work_get {askID}` the Work an ask is on. For a conversation, use
 `message_list {counterpartyID, before: "latest"}`, then `older` as `before`; `{between: [a, b]}`
 reads any pair's, and `{of: actorID}` lists an Actor's conversations, newest first. The owner's
@@ -151,12 +151,13 @@ the current one. On a conflict, read the record again and reassess.
 
 ## The organization
 
-The Organization level adds:
+The organization's own operations:
 - **Lifecycle.**
-  - `actor_create` creates a direct report. Do it only when the user's task and the organization's
-    conventions authorize it. Brief the report by Message, give it Work for its result, and start
-    its session through an authorized client workflow.
-  - `actor_close` closes an accepted leaf. A position with open reports can't be closed.
+  - `actor_create` creates an Actor beside every other. Do it only when the user's task and the
+    organization's conventions authorize it. Brief it by Message, give it Work for its result, and
+    start its session through an authorized client workflow.
+  - `actor_close` closes another Actor whose work is done; its part passes to the person, who is
+    never closed.
 - **Claims.** `claim` and `release` coordinate a shared resource.
 - **System.**
   - `system_status`, `connection_list` and `provider_list` observe the answering Hub run.

package/skills/agentorg/references/claude-code.md

@@ -1,8 +1,7 @@
 # Claude Code
 
 `agentorg-mcp connect claude-code` configures the project's `org` MCP server, context and waiter
-hooks, and this skill. `--level report` presents only your own report, for one agent and its
-person; `--level team` adds working with other Actors.
+hooks, and this skill.
 
 - **Tools.** Use `mcp__org__attach`, `mcp__org__interfaces` and `mcp__org__call`. For example, call
   `{name: "work_update", input: {ticketID: "…", progress: "The build passed; releasing next."}}`
@@ -17,8 +16,8 @@ person; `--level team` adds working with other Actors.
   binding before it can authorize a native request. Ordinary text and buttons do not create that
   binding through the generic adapter.
 - **Helpers.** Subagents sharing this MCP server share its Actor. They do not create an independent
-  position merely by running. Use the user's authorized workflow for separate report sessions.
-- **Lifecycle.** Close an accepted leaf Actor with `actor_close`, then end its session through an
+  Actor merely by running. Use the user's authorized workflow for other Actors' sessions.
+- **Lifecycle.** Close an Actor whose Work is accepted with `actor_close`, then end its session through an
   authorized client operation. Actor closure does not manage Provider resources.
 
 A session kept from before delivery moved to `attention` starts from now: what happened before its

package/vendor/workspace.json

@@ -1,9 +1,9 @@
 {
   "package": "@uniac/agentic-workspace",
-  "version": "0.0.1",
-  "source": "01a336b91fd1a3c2be51818e845b647f98b9094d",
-  "merge": "26fd0eedff2dea64b78e1f15d41ef016680770f0",
-  "tree": "c7452e1b3abd06faf4e321004e5c994510657cfe",
-  "archive": "uniac-agentic-workspace-0.0.1-26fd0ee.tgz",
-  "sha256": "0e92d13224bbcea74cda02a33a8ec17215366dcbc731ef61a4484aa48c1631fb"
+  "version": "0.0.2",
+  "source": "be74d42372682f59fc4b32ed1e28a4890ac1bc46",
+  "merge": "8aebc443a895456ef84fcf6947bdabdbf7a8bd7f",
+  "tree": "3ec20c9fb310e085f6379bfa7a5c9adbe22bd066",
+  "archive": "uniac-agentic-workspace-0.0.2-8aebc44.tgz",
+  "sha256": "6d1ecbe60b0298f3e4f4cc1a3ca8067df5e0e6c2e5702909a9bc38307c4ff81a"
 }

package/dist/src/clients/mcp/levels.d.ts

@@ -1,17 +0,0 @@
-/** Which of the Hub's interfaces a session at an organization level presents. */
-import { Level, type ToolDescriptor } from "../../domain/model/index.ts";
-/** The Hub's offers a session at `level` presents; without a level, all of them. */
-export declare const presented: (tools: ToolDescriptor[], level: Level | undefined) => {
-    interface: {
-        name: string;
-        title?: string | undefined;
-        description?: string | undefined;
-        input: Record<string, unknown>;
-        output?: Record<string, unknown> | undefined;
-        one_way: boolean;
-        long_running: boolean;
-    };
-    call: string;
-    read_only?: boolean | undefined;
-    level?: "organization" | "report" | "team" | undefined;
-}[];

package/dist/src/clients/mcp/levels.js

@@ -1,7 +0,0 @@
-/** Which of the Hub's interfaces a session at an organization level presents. */
-import { Level } from "../../domain/model/index.js";
-/** Whether an interface tagged `tag` is presented at `level`; each level contains the one before. */
-const presents = (level, tag) => level === undefined ||
-    (tag !== undefined && Level.options.indexOf(tag) <= Level.options.indexOf(level));
-/** The Hub's offers a session at `level` presents; without a level, all of them. */
-export const presented = (tools, level) => tools.flatMap((tool) => tool.interfaces.filter((offer) => presents(level, offer.level)));