Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions docs/api.html
Original file line number Diff line number Diff line change
Expand Up @@ -534,11 +534,14 @@ <h2 id="widget-dev-sessions">Widget dev sessions</h2>
<tr><td>DELETE</td><td><code>/widget-dev/sessions/{id}</code></td><td>–</td><td>Stops watching. The running generation stays installed and keeps rendering where it was placed.</td></tr>
<tr><td>POST</td><td><code>/widget-dev/sessions/{id}/rebuild</code></td><td>–</td><td>Builds the folder now. <code>409 SESSION_STOPPED</code> for a stopped session. Person-only.</td></tr>
<tr><td>POST</td><td><code>/widget-dev/sessions/{id}/place</code></td><td><code>{ conversationId, widgetId? }</code></td><td>Places the running widget in a conversation. Person-only.</td></tr>
<tr><td>POST</td><td><code>/widget-dev/chosen-folders/forget</code></td><td><code>{ root }</code></td><td>Takes back your choice of a folder: it no longer lets Clark start sessions in it, or in the folders inside it. Answers <code>{ root, forgotten, stillCoveredBy? }</code>; <code>forgotten</code> is <code>false</code> when the folder was not chosen, so a second press is harmless. <code>stillCoveredBy</code> names a folder Clark may still develop in that holds this one (another folder you chose, or a <code>workspace.roots</code> value you recorded), so Clark keeps access there until that one goes too. Running sessions stay as they are. Person-only.</td></tr>
</tbody>
</table></div>
<p>Starting, rebuilding and placing install code, so the WebSocket relay, <code>clarkcant api</code> and MCP refuse them with <code>403 PERSON_ONLY</code>. Reading and stopping a session stay reachable everywhere. In the conversation, Clark's <code>develop_widget</code> tool (<code>start</code>, <code>status</code>, <code>rebuild</code>, <code>place</code>, <code>stop</code>) drives the same sessions; it starts, rebuilds or places only in a turn the person sent, never in one a machine surface, an automation or a paired node sent.</p>
<p>Starting, rebuilding and placing install code, so the WebSocket relay, <code>clarkcant api</code> and MCP refuse them with <code>403 PERSON_ONLY</code>. Forgetting a chosen folder is refused the same way: taking a choice back is yours, as making it is. Reading and stopping a session stay reachable everywhere. In the conversation, Clark's <code>develop_widget</code> tool (<code>start</code>, <code>choose</code>, <code>folders</code>, <code>status</code>, <code>rebuild</code>, <code>place</code>, <code>stop</code>) drives the same sessions; it starts, rebuilds or places only in a turn the person sent, never in one a machine surface, an automation or a paired node sent. <code>choose</code> and <code>folders</code> only show you the <code>develop</code> card (a folder to choose, or the folders you chose, each with <strong>Forget</strong>); neither starts nor forgets anything. <code>choose</code> offers a lasting choice, so it too runs only in a turn you sent; <code>folders</code> only narrows access and runs in any turn.</p>
<ul>
<li><strong>Folders.</strong> <code>root</code> is resolved to its real path first. <code>400 ROOT_NOT_LOCAL</code> refuses a Windows network share or device path; <code>400 ROOT_IN_DATA_FOLDER</code> refuses the node's data folder, a folder inside it or one that holds it, except Clark's widget workspace <code>&lt;dataDir&gt;/widget-workspace</code>. A session Clark starts may watch only that workspace; any other folder is <code>403 ROOT_NOT_OWNED</code>.</li>
<li><strong>Folders.</strong> <code>root</code> is resolved to its real path first. <code>400 ROOT_NOT_LOCAL</code> refuses a Windows network share or device path; <code>400 ROOT_IN_DATA_FOLDER</code> refuses the node's data folder, a folder inside it or one that holds it, except Clark's widget workspace <code>&lt;dataDir&gt;/widget-workspace</code>. A session you start on the route marks its folder as one you chose (<code>chosenByPerson</code> in the session view), but only when the path you gave is the folder itself as it resolves at that moment: a path through a link or junction starts the session it leads to without marking anything, so a link swapped in after the card was drawn grants nothing. The choice covers every folder inside it. A whole drive or your home folder itself is never marked: a session may run there, but Clark keeps no access. A chosen folder is kept as the real path it had when you started it, so if that path later leads somewhere else (the folder was replaced by a link or junction, moved or removed) the choice no longer counts; it is still listed, as not found, so you can forget it. A session Clark starts may watch that workspace, a folder you chose (or one inside it), or a folder inside a <code>workspace.roots</code> preference you recorded yourself; any other folder is <code>403 ROOT_NOT_OWNED</code>, nothing starts, and Clark's answer carries a host-drawn <code>develop</code> card offering the folder to you.</li>
<li><strong>Choosing a folder.</strong> <code>/develop</code> and <code>/develop &lt;folder&gt;</code> (or asking Clark, which uses <code>develop_widget</code> <code>choose</code>) answer with the same <code>develop</code> command card. It names the folder the path resolves to when the card is drawn, and shows the path given when that differs; a press sends that canonical path, which is kept as your choice only if it is still the folder itself when pressed. A path that is not found, not absolute, or a network share or device gets no button, only a note saying why. Each row's action is <code>{ "kind": "develop-folder", "root"? }</code>, and the card starts nothing itself: a press in your own app calls <code>POST /widget-dev/sessions</code> as you, so no agent, widget or machine surface chooses a folder for itself. Without a <code>root</code> the desktop app opens the system folder dialog; where it cannot (a browser, a node on another machine, a dialog that does not open) the row asks for the path.</li>
<li><strong>Forgetting a folder.</strong> <code>/develop forget</code> (or asking Clark which folders it may use) lists the folders you chose, each with a <strong>Forget</strong> button whose action is <code>{ "kind": "develop-folder-forget", "root" }</code>. A press calls <code>POST /widget-dev/chosen-folders/forget</code> as you. Forgetting does not stop a running session, and a folder inside another folder you chose stays reachable through that one; the answer says so.</li>
<li><strong>Packages.</strong> Only <code>isolated-ui</code> and <code>declarative</code> facets run. A package with a service, tools or native facet fails to build with <code>FACET_LANE_UNSUPPORTED</code>. A package id that belongs to something else on the node is refused as <code>activation.state: "refused"</code> with <code>PACKAGE_LISTED</code>, <code>PACKAGE_IN_OTHER_SESSION</code> or <code>PACKAGE_INSTALLED_OTHERWISE</code>.</li>
<li><strong>Builds.</strong> A build that does not read as a package produces no generation: <code>lastBuild.ok</code> is <code>false</code> with up to 32 <code>diagnostics</code>, the running generation keeps running, and <code>showingLastKnownGood</code> is <code>true</code>. A folder over 5,000 files or 64 MiB fails with <code>FILES_TOO_LARGE</code>, a link out of it with <code>FILES_LINK_REFUSED</code>, and files that could not be read with <code>FILES_UNREADABLE</code>.</li>
<li><strong>Consent.</strong> Each install is decided under a consent scope: the package id with its declared reach, resources, facet lanes, facets, permissions and requested capabilities. The install question in <code>GET /inbox</code> carries that scope as its <code>operationDigest</code> and is decided on <code>POST /packages/approvals/{approvalId}/decision</code>. A later build with the same scope installs on that approval; a build whose scope changed is a new question, and the generation before it keeps running meanwhile.</li>
Expand Down
2 changes: 1 addition & 1 deletion docs/cli.html
Original file line number Diff line number Diff line change
Expand Up @@ -108,7 +108,7 @@ <h2 id="widget-dev-sessions">Develop a widget in the conversation</h2>
<p><code>clark widget dev</code> simulates a node. To see the widget on your node itself, ask Clark to develop one (“build me a timer widget”), or start a session on the <a href="api.html#widget-dev-sessions">widget dev session routes</a>. Your node watches the folder with the same build engine the dev host uses. Every change that reads as a package becomes a new build, named by the digest of its files, copied into the node's package cache and listed for this node alone, then installed through the ordinary install path. Nothing goes through npm, the Marketplace or a directory index, and nothing is published. A <code>node_modules</code> folder at the top is left out of each build; built output such as <code>dist</code> is kept.</p>
<p>The widget appears in the conversation in the real widget frame, with the real sandbox, bridge, state and migrations. A new build reloads only the frame: the widget keeps its state, which goes through the package's own migrations when the version changes. Beside the frame, your node says which build is on screen and, when it is not the newest, why: the new build failed (with its problems listed), it waits for your answer in the inbox, or the policy refused it. “Showing the last successful build” appears exactly when that is what you see.</p>
<ul>
<li><strong>Where.</strong> Clark develops widgets in its own widget workspace, <code>&lt;dataDir&gt;/widget-workspace</code>, where it scaffolds a new one. To have Clark work on a widget project you already have, copy its folder there. Pointing Clark at another project folder is not available yet (<a href="https://github.com/digitopvn/clarkcant/issues/538" rel="noopener">#538</a>). A session you start yourself on the route may watch any other local folder, but never the node's own data folder or a network share.</li>
<li><strong>Where.</strong> Clark develops widgets in its own widget workspace, <code>&lt;dataDir&gt;/widget-workspace</code>, where it scaffolds a new one. To have Clark work on a widget project you already have, choose its folder yourself: type <code>/develop</code> (or <code>/develop &lt;folder&gt;</code>, or ask Clark) and press <strong>Choose folder…</strong> in the card that answers. The desktop app opens your system's folder dialog; a browser, or a desktop app connected to a node on another machine, asks for the folder's full path on the node's machine and says why. If Clark wants to develop a folder you have not chosen, nothing starts, and the same card offers it to you with <strong>Develop this folder</strong>. The card names the folder the path really leads to, and says so when that differs from the path you gave; a path that is not found gets no button. A press keeps the folder as your choice only if the path is still that folder itself when you press, so a link put in its place meanwhile gains nothing. Only a message you sent can make Clark show a folder to choose. Once you start a folder, Clark may work in it, and in every folder inside it, without asking again, until you take that back: type <code>/develop forget</code> (or ask Clark which folders it may use) and press <strong>Forget</strong> beside the folder. Forgetting does not stop a running session, and a folder inside another folder you chose stays reachable through that one (the answer says so). A chosen folder that is moved away is listed as not found, so you can still forget it. A whole drive or your home folder can be developed for one session, but Clark never keeps access to it. A session you start yourself may watch any local folder, but never the node's own data folder or a network share.</li>
<li><strong>What.</strong> A session runs only widgets that stay in the frame and declarative data (<code>isolated-ui</code> and <code>declarative</code> facets). A package with a service, tools or a native part is refused with a problem saying so; install it the ordinary way.</li>
<li><strong>Consent.</strong> Your execution policy decides each install as it decides any other. A session Clark started is Clark's own proposal, so guarded mode asks before its first install; a session you started is your request. When your mode asks, the first install is a question, and so is every build that changes what the package reaches: declared reach, resources, facet lanes, facets, permissions or requested capabilities. A build that changes only code or UI reuses your answer and runs at once. A mode that does not ask runs every build, and when a build reaches more than the one before it without anyone being asked, the conversation says what it added.</li>
<li><strong>Limits.</strong> A node watches at most 8 folders at once. A folder over 5,000 files or 64 MiB, or one holding a link that points outside it, is refused with what to change.</li>
Expand Down
1 change: 1 addition & 0 deletions docs/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -97,6 +97,7 @@ <h2 id="slash-commands">Slash commands</h2>
<li><code>/thinking</code> chooses how hard the next turns think, from a list, or directly: <code>/thinking high</code>, <code>/thinking default</code>. It is the same setting as Settings → AI &amp; Routing → Thinking level.</li>
<li><code>/background &lt;request&gt;</code> runs the request as background work beside the conversation and reports back in it.</li>
<li><code>/report</code> reports a bug or asks for a feature in ClarkCant itself. See <a href="#report">below</a>.</li>
<li><code>/develop</code> chooses a folder to develop a widget from, live in the conversation; <code>/develop &lt;folder&gt;</code> offers that folder, and <code>/develop forget</code> lists the folders you chose so you can take one back. See <a href="cli.html#widget-dev-sessions">developing a widget in the conversation</a>.</li>
</ul>
<p>A command typed in the middle of a sentence is just text. Commands are not sent to the model. See <a href="api.html#provider-sign-in">provider sign-in routes</a>.</p>

Expand Down
Loading
Loading