Skip to content

Commit 600993d

Browse files
committed
Align the standalone-plane example with ask()'s grant config
CL-4522 gives createKnowledgePlane a required GrantConfig second argument so ask() can evaluate knowledge:search internally. Update the README example to match, and be precise about which methods check the capability grant: - ask() — checks it internally; an in-process caller cannot skip it - capture() — does not; applies per-document visibility only - search() — does not; applies per-document visibility only Per-document visibility and "may this principal search at all" are different questions, and AUTH.md is explicit that both layers must allow. Refs CL-4508, CL-4522 Claude-Session: https://claude.ai/code/session_017GTgGzn5xAwvkU2GAPAHpF
1 parent 6971361 commit 600993d

1 file changed

Lines changed: 15 additions & 5 deletions

File tree

‎README.md‎

Lines changed: 15 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -72,15 +72,23 @@ import {
7272
loadKnowledgeConfig,
7373
} from "@corbits/knowledge-engine";
7474

75-
const knowledge = createKnowledgePlane(loadKnowledgeConfig());
75+
const knowledge = createKnowledgePlane(loadKnowledgeConfig(), {
76+
grantStore,
77+
conditionRegistry,
78+
});
7679
await knowledge.capture({ tenantId, principalId, title, text });
7780
await knowledge.close();
7881
```
7982

80-
Note that this path bypasses the `requireGrant` route guard, since there is no
81-
request. If the caller is acting for a user rather than as an operator, check the
82-
capability yourself — the per-document visibility the engine applies is not a
83-
substitute for "may this principal search at all":
83+
The grant config is required so the plane can evaluate capabilities on the paths
84+
that check them — `ask()` does its own `knowledge:search` check internally,
85+
precisely because an in-process caller never passes through the `requireGrant`
86+
route guard.
87+
88+
`capture()` and `search()` do **not** check the capability grant. They apply
89+
per-document visibility and block lists, which is not the same question. So if
90+
the caller is acting on behalf of a user rather than as an operator, check it
91+
yourself:
8492

8593
```ts
8694
import { authorize } from "@intx/authz";
@@ -96,6 +104,8 @@ const decision = await authorize(
96104
if (decision.effect !== "allow") throw new Error("not permitted");
97105
```
98106

107+
Or just use `ask()`, which cannot be called without that check happening.
108+
99109
Apply the knowledge/vector schema once (idempotent):
100110

101111
```ts

0 commit comments

Comments
 (0)