qriton 0.3.2 → 0.4.0

package/docs/terminal-interaction.md

@@ -1,38 +0,0 @@
-# Terminal interaction
-
-Qriton's interface should help users discover what they can do, show where their input will go, and preserve work when they change their mind. This applies equally to commands, saved conversations, model selection and approvals.
-
-## Principles
-
-- **One keyboard owner.** An approval or picker owns the keyboard while open. The composer retains its draft, and the transcript does not also consume navigation keys. Command suggestions are part of the composer.
-- **Show the available choices.** Slash commands and common arguments have descriptions. Long lists scroll around the highlighted item and show position and count. Search filters the full list, including previously hidden entries.
-- **Separate browsing from action.** Moving a selection never runs a command, changes permissions, switches a model or resumes a conversation. A visible selected item and an explicit submission determine the action.
-- **Make cancellation predictable.** Escape dismisses suggestions or a picker without losing input. At an approval, it rejects. With no open control, it interrupts active work. Ctrl+C still interrupts a running turn immediately from the composer.
-- **Keep shortcuts local and visible.** The footer changes with focus. Shift+Tab goes backward in a list; its existing mode-cycle shortcut applies only to an empty, idle composer.
-- **Use text as well as color.** A pointer identifies a selected list row, brackets identify the approval choice, and labels identify the focused control. Light and dark themes use the same structure.
-- **Keep discovery inexpensive.** Completion uses local command metadata. Model discovery runs only on `/models`; filtering does not query a provider or load a model. Session browsing reads local metadata without calling a chat model.
-
-These choices draw on [Command Line Interface Guidelines: consistency and discovery](https://clig.dev/#philosophy). The [W3C combobox pattern](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) informs preserving editable input, visible selection and Escape dismissal. Terminal keybindings are adapted to this application; this is not a claim of browser ARIA conformance.
-
-## Keyboard contract
-
-| Focus | Navigation | Action | Escape |
-|---|---|---|---|
-| Command suggestions | Up/Down; Shift+Tab previous | Tab fills. Enter fills a partial command; Enter on the completed command runs it. | Hide suggestions, keep text |
-| Session or model picker | Up/Down, Tab/Shift+Tab, Page Up/Down, Home/End; type to filter | Enter chooses; Ctrl+U clears the filter | Close, keep draft |
-| Approval | Tab/Shift+Tab or Left/Right selects; Up/Down and Page Up/Down scroll preview | Enter confirms the bracketed choice; y/n/a remain direct shortcuts | Reject |
-| Composer | Left/Right edits; Up/Down moves within multiline drafts or recalls single-line history | Enter sends; Ctrl+J adds a newline | Interrupt when working |
-| Empty, idle composer | Shift+Tab cycles approval modes | `/` opens command discovery | No action |
-| Feedback composer | Normal multiline editing; chat history is not offered | Enter saves locally; Ctrl+J adds a newline | Cancel without saving |
-
-Bracketed paste only inserts text or a filter. Pasted newlines and approval letters do not submit or approve. Approval starts with “approve once” selected, preserving the existing Enter behavior; selection alone never grants permission.
-
-The input remains docked. Short windows show fewer suggestions or picker rows, and long drafts retain their own scrolling behavior. Page Up/Down in the composer continues to scroll the conversation.
-
-## Implemented scope
-
-This interaction model covers slash commands, common fixed arguments, session selection, model selection and approval choices. Ordinary numbered lists in assistant prose remain text. File-path completion, interactive model-generated questions and mouse interaction need separate designs; they must not infer executable actions from arbitrary assistant text.
-
-`/servers` uses the same picker for explicit local/LAN discovery and verified server selection. Navigation never probes or connects until Enter. `/models` preserves provider ordering (newest OpenAI families first) and marks the current model in place. `/feedback` changes the composer into a local form with its own footer; its text is never passed to the agent, even when it begins with a slash command.
-
-Rendered terminal tests cover navigation beyond the visible rows, filtering, cancellation, explicit submission, mode isolation, pasted input, draft preservation and narrow-window resizing. They complement the existing streaming, approval-policy and session-restoration tests.

package/docs/workspace-trust.md

@@ -1,68 +0,0 @@
-# Workspace configuration trust
-
-Qriton requires an explicit grant before applying a project's `.qriton/config.json`. This includes existing project configuration. Without a valid grant, startup stops before loading credentials, contacting providers, or starting an optional Python runtime. A workspace without project configuration uses user/default settings without a grant.
-
-## Review and grant
-
-Run these commands in the intended workspace, or supply `-C /path/to/project` to each command:
-
-```sh
-qriton trust show
-```
-
-The offline report displays the canonical workspace, configuration file, a SHA-256 fingerprint, current trust status, and configuration with secret fields and URL credentials/query values redacted. Review the actual file, especially approval mode, shell rules, provider endpoints, model selection, and HLM/Energy executable and source paths. Then use the fingerprint you reviewed:
-
-```sh
-qriton trust grant <fingerprint>
-qriton doctor policy
-```
-
-Replace `<fingerprint>` with the reported 64-character value. A stale or incorrect value is rejected. Do not automate approval by piping a freshly computed fingerprint straight into `grant`; that skips review of what the configuration authorizes.
-
-Trust is bound to the canonical workspace and the exact configuration bytes. A symlink alias for the same workspace shares its grant; a different workspace cannot reuse it. Editing configuration, including formatting, requires review and a new grant. Removing the file returns new invocations to user/default configuration. Creating, changing, or removing it during an active session stops subsequent guarded operations and requires a restart.
-
-```sh
-qriton trust revoke
-```
-
-Revocation takes effect at the next execution boundary, including after a pending tool approval. It does not undo completed actions or terminate a subprocess already running. Revoke remains available when project configuration or the receipt is malformed. Plan mode cannot grant trust; revocation is allowed.
-
-Receipts live in `$QRITON_HOME/trust/`, normally `~/.qriton/trust/`, with private files and atomic replacement. The state directory and resolved user configuration must be outside the active workspace. Project configuration must be a bounded regular file inside that workspace; symlinked configuration files are rejected.
-
-## Effective policy
-
-`qriton doctor policy` works offline even when project configuration is untrusted. `/policy` displays the loaded session's settings in chat. Reports show whether project configuration was applied, current trust status, whether a restart is needed, allowed approval modes, and each setting's origin: default, environment, user, trusted project, invocation, or a runtime change.
-
-Untrusted project overrides are not merged into an inspection configuration. `qriton trust show` displays the proposed project values separately. Inspection configurations cannot execute actions. `qriton config init` writes user settings/defaults without copying project permissions or endpoints into global configuration.
-
-The regular precedence remains defaults/environment defaults, user configuration, trusted project configuration, and invocation overrides. `QRITON_MODEL` overrides configured model selection before an explicit `--model`; `OLLAMA_HOST` overrides the configured Ollama endpoint. Launcher-managed limits apply after merging. `--yolo` changes approval mode within those limits and does not grant workspace trust.
-
-## Launcher-managed limits
-
-A trusted launcher can set `QRITON_POLICY` to an absolute path outside the workspace:
-
-```json
-{
-  "version": 1,
-  "allowedModes": ["suggest", "plan"],
-  "allowProjectConfig": true
-}
-```
-
-```sh
-QRITON_POLICY=/absolute/path/to/managed-policy.json qriton -C /path/to/project
-```
-
-`allowedModes` is a nonempty list drawn from `suggest`, `auto-edit`, `full-auto`, and `plan`. The default allows all four. A disallowed configured or requested mode fails explicitly; Qriton does not silently choose another. The same check applies to `--mode`, `--yolo`, `/mode`, agent dispatch, and resume. Saved sessions cannot restore an older permission grant.
-
-`allowProjectConfig: false` prevents project settings from being applied even if a receipt already exists, and prevents new grants. Project configuration is still read for inspection and validated as a bounded JSON object; malformed files cause an error. This switch does not disable reading repository instruction files as task context.
-
-The optional `network` block adds [destination limits and hosted-fallback controls](https://unpkg.com/qriton/docs/network-policy.md). Every applicable user and managed network policy must permit a request; project configuration cannot set network policy. Only the documented policy fields and `version` are accepted. Invalid, missing, or unreadable selected policy files fail closed. Changing or removing a loaded policy causes subsequent guarded actions to stop until Qriton is restarted. Keep the policy file, launcher environment, and user-state location under the administrator's control when using these limits for a managed deployment.
-
-## Scope of these controls
-
-This feature authorizes configuration. It does not approve every repository file, establish that project instructions are safe, or bind the contents of an executable named by a trusted path. Repository instructions cannot grant programmatic permissions; they remain model context and can still contain prompt injection.
-
-CLI startup, interactive commands, agent mode changes, tool execution after approval, and background model/memory work check the loaded trust and policy. Internal programmatic callers that construct a `Config` directly are trusted host code; the public CLI uses the guarded loader.
-
-The implemented managed limits cover approval modes, project-configuration loading, and [HTTP destination policy](https://unpkg.com/qriton/docs/network-policy.md). [Session conflicts and save failures](https://unpkg.com/qriton/docs/session-recovery.md) also have recovery handling. This grant does not provide OS isolation or organization-wide memory administration. Restricted network profiles block unconfined shell, Git and Python execution. In unrestricted mode, shell commands run with the user's OS privileges. Application checks do not contain arbitrary code that already has access to the same account.