fuli-context 0.7.10-beta.0 → 0.8.0

package/dist/web/index.html

@@ -9,16 +9,22 @@
     />
     <link rel="icon" type="image/png" href="/assets/fuli-logo-ER1wQ8Kk.png" />
     <title>复利 · Context Graph</title>
-    <script type="module" crossorigin src="/assets/index-B-rXoqYP.js"></script>
-    <link rel="modulepreload" crossorigin href="/assets/i18n-C7r_00q2.js">
-    <link rel="modulepreload" crossorigin href="/assets/console-CYXvhGCR.js">
-    <link rel="modulepreload" crossorigin href="/assets/useApi-CROJJdhE-DERnOR_k.js">
-    <link rel="modulepreload" crossorigin href="/assets/vue-router-DJ6C6-8v.js">
-    <link rel="modulepreload" crossorigin href="/assets/fuli-logo-Bu9WBuQe.js">
+    <script type="module" crossorigin src="/assets/index-BUMq5zNh.js"></script>
+    <link rel="modulepreload" crossorigin href="/assets/i18n-CVFADb_M.js">
+    <link rel="modulepreload" crossorigin href="/assets/client-Bl4oiW3E.js">
+    <link rel="modulepreload" crossorigin href="/assets/console-BAIVNC-N.js">
     <link rel="modulepreload" crossorigin href="/assets/_plugin-vue_export-helper-BDNMzG2s.js">
-    <link rel="modulepreload" crossorigin href="/assets/avatars-BfZueqlm.js">
+    <link rel="modulepreload" crossorigin href="/assets/GrowthLoading-WXCj8b0r.js">
+    <link rel="modulepreload" crossorigin href="/assets/useApi-CROJJdhE-CuJ16v2S.js">
+    <link rel="modulepreload" crossorigin href="/assets/vue-router-C8KuEZ6a.js">
+    <link rel="modulepreload" crossorigin href="/assets/fuli-logo-Bu9WBuQe.js">
+    <link rel="modulepreload" crossorigin href="/assets/AgentHand-BfLYPGjg.js">
+    <link rel="modulepreload" crossorigin href="/assets/useModalDialog-Ddv2XJQi.js">
     <link rel="modulepreload" crossorigin href="/assets/paths-CDREouhi.js">
-    <link rel="stylesheet" crossorigin href="/assets/index-Ch1jmkyO.css">
+    <link rel="stylesheet" crossorigin href="/assets/GrowthLoading-B_Hh0CRS.css">
+    <link rel="stylesheet" crossorigin href="/assets/AgentHand-D9sQu2vc.css">
+    <link rel="stylesheet" crossorigin href="/assets/index-C0ci8dnU.css">
+    <link rel="stylesheet" crossorigin href="/assets/employee-dialog-Bh5ccIbK.css">
   </head>
   <body>
     <div id="app"></div>

package/docs/agent-interface-architecture.md

@@ -0,0 +1,97 @@
+# Agent interface architecture
+
+FULI exposes product data operations through structured Agent tools so an AI Agent does not need browser automation to act on the user's behalf. The console and the Agent interface are peer clients of the same application services; neither client owns a second copy of the business rules.
+
+## Contract
+
+`list_agent_interfaces` returns the versioned `agent-interface-parity-v1` catalog. Every console data mutation is classified as one of:
+
+- `agent`: the catalog names the structured Agent tool or tools that perform the same business operation.
+- `local_user_only`: the catalog records why the operation requires local human presence.
+
+The parity catalog is executable product metadata, not just documentation. Tests verify that every `agent` entry names a registered tool and that sensitive local-only routes remain explicit. A route with multiple actions, such as ignoring or resetting routing-learning evidence, lists every matching tool.
+
+## Request path
+
+```text
+Console UI ───────┐
+                  ├─> application service ─> scoped Provider / local store
+Agent tool / MCP ─┘
+```
+
+Agent handlers delegate to existing application-service methods. They do not call the console over HTTP, render pages, write browser state, or bypass scope checks. Existing Host/Origin protection remains relevant to the console; Agent access is independently guarded by the Agent-access policy before any tool handler runs.
+
+## Required operating sequence
+
+### Agent names and human attention
+
+Agent identity (`agentId`) and role (`profile.name`, `responsibility`) remain stable.
+`profile.displayName` is the editable person-like nickname. Legacy role-style names
+receive a deterministic nickname derived from their Agent ID; existing custom names
+and explicit display names are preserved. These are product nicknames, not real people.
+Reading a legacy profile does not rewrite its stored history.
+
+Use `request_agent_attention` only for an explicit human action, with the exact space,
+project and Agent, optional task ID, request kind, context and `requestedAction`.
+The same idempotency key and payload returns the same request, including after closure;
+reusing a key with another payload is a conflict. Running, waiting in a queue and
+recoverable retries do not create attention requests automatically.
+
+`list_agent_attention` supports project/Agent/status filters and pagination. Counts
+cover the whole filtered set. Agents can withdraw obsolete requests with
+`cancel_agent_attention`, using `expectedRevision` and a reason. Only the local-user
+`POST /api/agent-attention/respond` workflow records a human reply. A reply closes the
+attention item but does not itself grant permission, accept a task or run a command.
+Agents read resolved replies and continue within the existing authority boundaries.
+Original context, response, actor and timestamps remain in the private graph.
+
+The console uses one shared attention store and dialog for the sidebar and personnel
+views. Failed reads remain visible as errors, not a false empty state. Replies use
+revision checks and preserve the user's draft on failure. Public reports never query
+or expose this private attention queue.
+
+An Agent should:
+
+1. call `list_agent_interfaces`;
+2. resolve exact space, project, item and version identifiers with read tools;
+3. inspect the selected tool's current schema;
+4. read current state before a write;
+5. execute the narrowest scoped mutation with available compare-and-swap or idempotency fields;
+6. verify through a structured read.
+
+The bundled `operating-fuli` Skill teaches this sequence and is installed by `fuli setup` for supported Agents. Browser automation is permitted only as optional visual verification after a structured operation, never as a data-mutation fallback.
+
+## Human-only boundaries
+
+The following operations intentionally remain local-user-only:
+
+- enabling or disabling Agent access;
+- device-level runtime settings;
+- completing a preference conflict as a human decision;
+- confirming preference visibility scope;
+- batch confirmation of knowledge.
+- Jefa task completion that records explicit human acceptance (other task updates remain available through the employee tools).
+
+These are trust boundaries, not missing interfaces. An Agent may explain where the user can perform the action, but must not substitute direct HTTP, storage, shell, or browser scripting.
+
+## External knowledge
+
+Connector discovery, binding creation, readiness checks, target updates, scoped synchronization, live retrieval, conflict policy and deletion have dedicated tools. Connector secrets are referenced by environment-variable name; tool results and catalog listings must not expose secret values.
+
+Moving a connection between projects updates the binding targets. Deleting and recreating a binding is not the default because it breaks audit continuity and can discard connector state.
+
+Target updates require the Agent's last-read `targetsVersion`. Registry mutations take a cross-process SQLite reservation, so sync/check/delete cannot overwrite a concurrent scope update. Busy or stale writes fail with a controlled conflict and must be re-read, not blindly retried. The legacy HTTP contract still accepts callers without a version for compatibility; current console and Agent clients supply one.
+
+## Adding a feature
+
+When a console feature adds a data mutation:
+
+1. implement the business operation in an application service;
+2. have the console route call that service;
+3. add or reuse a typed Agent definition and a handler that calls the same service;
+4. annotate read/write, destructive and open-world behavior for MCP clients;
+5. add the route-to-tool mapping to `src/agent-tools/interface-catalog.js`, or document a narrowly justified `local_user_only` boundary;
+6. add contract tests covering dispatch, scope, error behavior and the parity mapping;
+7. update the `operating-fuli` workflow reference if the operation needs a non-obvious sequence.
+
+A missing Agent interface must remain visible as a parity defect. Do not silently ship a browser-only write path.

package/docs/employee-agents.md

@@ -1,6 +1,6 @@
 # Specialist Agents
 
-An employee template is a reusable role with an optional FULI-hosted workbench. Recruitment reuses the existing durable Project Agent identity and assignment model. The first built-in template is **Jefa, project manager**; adding another employee does not require a host-side special case.
+An employee template is a reusable role with an optional FULI-hosted or native workbench. Recruitment reuses the existing durable Project Agent identity and assignment model. The built-in specialists are **Jefa**, the project manager, and **Bole**, the fixed system HR Agent. Bole is created with every personal space, cannot be archived or replaced by another `hr` identity, and does not require a separate runtime package.
 
 ## User flow
 
@@ -16,7 +16,7 @@ The directory's **Filter projects** control supports multi-selection and inversi
 
 Repeat recruitment is idempotent. Customized profile preferences and executor/model policies are preserved. One employee identity can have multiple project assignments. Reactivating an inactive identity is an explicit action; a conflicting unrelated identity is never overwritten. Recruitment does not start an executor or constitute model usage.
 
-The catalog shows whether a workbench package is actually installed. Identity-only templates need no runtime and remain valid employees without a sidebar workbench.
+The catalog shows whether a workbench package is actually installed. Identity-only templates need no runtime and remain valid employees without a sidebar workbench. A trusted built-in template may declare `workbench: { "kind": "native", "view": "people" }`; Bole uses this native panel to summarize Agent distribution, current tasks, and timestamped recruitment reasons from the same Project Agent APIs used elsewhere in the console.
 
 ## Local installation
 
@@ -71,8 +71,12 @@ Context includes `personalSpaceId`, `project`, `agentId`, and `basePath`; HTTP a
 
 Optional manifest fields `defaultProjectScope: "all" | "selected"` and `taskEntry: { "boardTool": "read_board", "titleTool": "prepare_session_title" }` declare defaults and task-entry participation without a template-specific host branch. Context also carries the trusted `management` policy and native `session` identity when available. Task-entry board tools must declare `board.read`; the host returns bounded data and guidance, not an automatically started worker. A failed employee runtime degrades manager context without breaking collaboration preferences.
 
+The optional built-in-only native workbench declaration is `workbench: { "kind": "native", "view": "people" }`. It renders host-owned read models and does not load third-party code. Installable employee packages continue to use the runtime contract above.
+
 The reserved identity is `employee.<template-id>`, recognized by the generic `fuli.employee:<template-id>` capability. Preserve this marker when customizing employee profiles. The actual role, history, memory and project assignments remain in FULI's existing Agent model.
 
+`employee.bole` is additionally reserved as the only system HR identity. Its Provider type is `hr`; other identities cannot claim that type. Recruitment history records the coordinating and HR Agent IDs, time, reason, proposed identity and final recruited identity, which powers Bole's people panel without inventing activity.
+
 ## HTTP and MCP
 
 The host serves `/api/employee-templates`, recruitment/workspace/tool endpoints below it, and `/employee-workspaces/<template-id>/<project-id>/…`. Existing Host/Origin, JSON-body and LAN authorization checks apply. All workbench requests require an active matching identity and authorized responsibility policy, including assets and Agent discovery. Selected mode additionally requires an active assignment; all mode includes future active projects but enforces explicit exclusions and ended assignments before reaching the runtime.
@@ -87,6 +91,42 @@ Jefa supplies eight workbench tools for board/task reading, task creation, optim
 
 ## Verification and release boundary
 
+Jefa uses one native `EmployeeTaskBoard` for every project scope. `/employees/jefa` and
+`?project=all` show the current managed projects; legacy `__all__` is normalized. A single
+project query or repeated `project` query parameters filter the same board, without changing
+assignments. Task details and creation use the existing `get_task`, `create_tasks`, and
+version-checked `update_tasks` interfaces. Explicit human confirmation of `done` continues
+through the existing human HTTP endpoint. Other employee packages retain their generic iframe
+workspaces; Jefa no longer switches to the package board when a card is opened.
+
+The external-report action beside Jefa's identity has an independent project selection,
+including all, one, several, and inverted selection. Generating a link explicitly enables
+sharing for selected projects through `PATCH /employee-workspaces/jefa/<project>/api/projects/<project>/sharing`
+with `{ publicShareEnabled: true, acceptsPublicRequests: false }`. Merely opening or filtering
+the dialog performs no writes. Sharing status comes from the existing scoped snapshot API;
+disabling uses the same endpoint with both flags false and invalidates that project's old slug.
+
+One `/reports/jefa` link aggregates the selected project capabilities in its URL fragment,
+keeping them out of HTTP access logs and referrer query strings. The report loads only
+`GET /employee-workspaces/jefa/<project>/api/public/<slug>` and uses the same board in read-only
+mode. It never loads the console shell or private board/task endpoints. The existing public
+projection controls visibility: private tasks, details, evidence, and unrelated projects are
+not included. Partial enablement is reported without claiming a complete link, and selection
+changes clear the previously generated link. “All” is the current selection, not consent to
+publish future projects automatically.
+
+Before presenting a report link, the dialog verifies the selected public projections and
+shows their task count. A zero-task selection is not presented as a successful report;
+existing empty links explain that no tasks have been approved for public viewing. This
+never changes task privacy or substitutes private board data for a public projection.
+Refreshing the preview preserves the selected projects.
+
+These structured HTTP operations remain subject to the host's existing scope, Origin and LAN
+authentication checks. The link is not a separate authorization layer for the entire console.
+Loopback links work only on the same computer; this UI does not enable LAN access, tunnels,
+production hosting, or new public task visibility. Do not expose the local management service
+as a public multi-user report server.
+
 Run FULI's normal Node/web tests and typecheck. For an actual Jefa build:
 
 ```sh
@@ -97,3 +137,19 @@ node scripts/employee-package-smoke.js <built-package-directory> --serve
 The smoke fixture uses a synthetic FULI directory but the real installed employee bundle, SQLite and MCP transport. The UI mode does not query a personal provider or external model. It deletes its temporary test data on shutdown.
 
 Signing, remote catalog distribution, a runtime sandbox, database migration/uninstall UX, and production multi-user authorization remain separate release work. This feature does not authorize or publish a Feishu application.
+
+### Bole identity upgrades
+
+Local startup calls the idempotent system-HR endpoint for both fresh and existing installs.
+It consolidates the reserved legacy `fuli-project-hr` identity into `employee.bole` in one
+transaction. Names never identify merge targets. The legacy node remains an audit alias;
+assignments, recruitment references, attention and task history follow the canonical Bole.
+Old profile links resolve to Bole, and the obsolete ID cannot be recreated as another role.
+Working-memory heads and immutable checkpoint JSON/hashes are retained; equivalent old/new-ID
+memory retries address the same checkpoint. Knowledge visibility metadata is migrated only
+inside the owning space, without changing historical evidence UUIDs.
+
+Conflicting memory heads, locked executor policies, relationship properties or overlapping
+learning buckets abort the complete migration. Nothing is silently selected or overwritten.
+The Neo4j acceptance tests require an explicitly disposable loopback database; they never
+clear or seed an existing user's graph.