weft-command 2.1.0__tar.gz

weft_command-2.1.0/.gitignore

@@ -0,0 +1,78 @@
+# The donor checkout, reachable for reading and lifting only.
+# Never a build input: see CLAUDE.md and docs/README.md.
+/donor
+
+# Python
+__pycache__/
+*.py[cod]
+.venv/
+dist/
+build/
+*.egg-info/
+
+# Tooling
+.pytest_cache/
+.ruff_cache/
+.pyright/
+
+# `uv.lock` was here, filed between two caches. It is not a cache: `ci.yml` runs
+# `uv sync --frozen` in three of its four jobs, and every one of them died at that step
+# the first time CI ever ran. It is tracked now — the resolution CI installs and the
+# resolution a developer installs must be one artefact, which is the same argument
+# `docs/README.md` makes about single-sourcing anything two readers can disagree about.
+#
+# It constrains nobody downstream. A lockfile is not a dependency bound; what a consumer
+# resolves is decided by each distribution's `pyproject.toml`.
+
+# Session-local attempt counter for the guard_quality_gates.py PreToolUse hook — per-session
+# scratch, not a record anyone should read later. See the hook's module docstring.
+.claude/.gate-attempts.json
+
+# Secrets. `.env` holds live provider keys; only the documented, valueless
+# example is tracked. Listed before any tooling rule so a stray `git add -A`
+# cannot reach it.
+.env
+.env.*
+!.env.example
+
+# Corpus payload. Every subdirectory of /corpus is a materialised document set and
+# is deliberately untracked; `corpus/manifest.toml` and `scripts/fetch_corpus.py`
+# are the tracked artefact. `09` §4 V1 permits exactly this:
+# a corpus is "either redistributable or fetched by a pinned, checksummed script",
+# and the mRMR papers are published under publisher copyright, so committing them
+# would be redistribution this repository has no right to perform. The manifest
+# carries a sha256 per document, which is what makes the set reproducible without
+# the bytes being here. The pattern is a directory glob rather than a list of names
+# so that scaling the corpus up cannot silently start tracking a paper.
+/corpus/*/
+
+# Where a baseline run stages the corpus it indexes and writes the `weft.toml` it measures
+# through (`eval/run_baseline.py`). The staged copies are the same untracked papers one
+# directory over, and the configuration is reproduced by the harness rather than kept — what
+# is tracked is the run it produced, under `eval/baselines/`.
+/.baseline-run/
+
+# Working artefacts of a build session — a generated map of the codebase and a design
+# record produced while planning. Untracked on purpose: `docs/README.md` routes every
+# document this project owns, and a design that matters belongs in the `docs/` file
+# that owns its content, not in a root-level file nothing points at.
+/.phase2-*.md
+/.phase3-*.md
+/.phase4-*.md
+
+# Gate-session preparation: the Bring lists of `docs/05-grilling-sessions.md`, measured on the day
+# a session is about to run. Untracked for the same reason — the session's outcome belongs in
+# `docs/README.md`'s decision log and in the reference document the decision changes, never here.
+/.gate-brief-*.md
+
+# Claude Code local state
+.claude/settings.local.json
+
+.DS_Store
+
+# The build harness driving Phase 2, alongside its brief, findings and design record.
+/.phase2-build.js
+
+# Transient: harvested subagent findings, promoted into docs/lessons.md by implement-ll.
+# Never committed — its content belongs in the queue or nowhere.
+.claude/lessons-spool.md

weft_command-2.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Adam Krysztopa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

weft_command-2.1.0/NOTICE

@@ -0,0 +1,24 @@
+Weft
+Copyright (c) 2026 Adam Krysztopa
+
+This product is licensed under the MIT License. See the LICENSE file at the root
+of this repository.
+
+--------------------------------------------------------------------------------
+Original work
+--------------------------------------------------------------------------------
+
+**Weft contains no source text from any other codebase.** Every line here is
+written for this project, against this project's contracts.
+
+This is a rule, not a description of the current state: no file may be copied or
+adapted from another project's source, and no third-party source text may be
+pasted into this repository. Where a prior system informed a design, what was
+carried across is understanding — an approach, an ordering, a measurement, a
+reason a guard exists — restated in this project's own words and implemented
+fresh. Copyright does not reach any of that, and nothing in this repository
+depends on a licence granted by anyone else.
+
+`docs/04-donor-inventory.md` records what was learned from prior work and what
+was deliberately not taken. It is a design record. Nothing in it authorises a
+copy, because copying is not permitted here at all.

weft_command-2.1.0/PKG-INFO

@@ -0,0 +1,9 @@
+Metadata-Version: 2.5
+Name: weft-command
+Version: 2.1.0
+Summary: First-party command pack. Publishes the Command contract and PermissionClass.
+License-Expression: MIT
+License-File: LICENSE
+License-File: NOTICE
+Requires-Python: >=3.12
+Requires-Dist: weft-kernel<1.0.0,>=0.1.0

weft_command-2.1.0/pyproject.toml

@@ -0,0 +1,20 @@
+[project]
+name = "weft-command"
+version = "2.1.0"
+description = "First-party command pack. Publishes the Command contract and PermissionClass."
+requires-python = ">=3.12"
+license = "MIT"
+license-files = ["LICENSE", "NOTICE"]
+dependencies = ["weft-kernel>=0.1.0,<1.0.0"]
+
+# No `[project.entry-points."weft.packs"]` block — the identical reasoning
+# `packages/weft-prompts/pyproject.toml` already carries: fitness function 2 asserts that
+# every distribution declaring this entry point is active *and contributing*, and this
+# distribution registers no `Command` of its own. `weft-cli`'s own built-in commands
+# (`weft index`, `weft ask`, ...) stay on `weft_cli.cli.COMMANDS` until a later task moves
+# them onto this contract; the first plugin-contributed `Command` adds the entry-point line
+# in the same commit it lands in, exactly as `weft-retrieve` did at 2.13.
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"

weft_command-2.1.0/src/weft_command/__init__.py

@@ -0,0 +1,43 @@
+"""First-party command pack. Publishes the `Command` contract and `PermissionClass`.
+
+Task **3.1**: "a pack registers a command exactly as it registers a retriever, and a command
+that declares no permission class fails to register while its author is standing there."
+`weft_command.contract`'s own module docstring carries the full reasoning for why this
+distribution exists at all — in particular why `Command` lives here rather than in
+`weft-kernel` (G1: the kernel names no capability) or `weft-cli` (a pack implementing a
+contract must not depend on the driving adapter that calls it).
+
+**Registers nothing, and declares no `weft.packs` entry point**, on `packages/weft-prompts`'s
+own precedent (see that distribution's module docstring for the identical reasoning): fitness
+function 2 requires every distribution declaring that entry point to be active *and
+contributing*, and every first-party command belongs to the pack whose behaviour it exposes —
+none of which is this one's to own. `weft_cli.commands` carries every built-in command since
+task 3.2, registered through `weft-cli`'s own entry point (see that module's docstring for why
+`weft-cli` is the owner rather than a twelfth distribution); a third party's first
+plugin-contributed `Command` adds the entry-point line to *its own* `pyproject.toml` in the same
+commit it registers, exactly as `weft-retrieve` did at task 2.13.
+
+There is therefore no `Settings` model and no `register` function here — a pack declaring no
+entry point is never handed either, and declaring them unused would be two more things to keep
+true. `packages/weft-generate` and `packages/weft-prompts` take the same shape for the same
+reason.
+
+**Task 6.20 (G13) adds `ExitCode` and `Rendered` to this namespace** — `weft_command.render`'s
+own module docstring carries the reasoning in full: a renderer a third-party pack registers
+through `weft_kernel.discovery.PackRegistrar.add_renderer` has to answer with a `Rendered`
+carrying an `ExitCode`, and a pack implementing `Command` must not depend on `weft-cli`, the
+driving adapter, for the vocabulary its own renderer speaks.
+"""
+
+from weft_command.contract import COMMAND_CONTRACT_VERSION, Command, CommandResult
+from weft_command.permission import PermissionClass
+from weft_command.render import ExitCode, Rendered
+
+__all__ = [
+    "COMMAND_CONTRACT_VERSION",
+    "Command",
+    "CommandResult",
+    "ExitCode",
+    "PermissionClass",
+    "Rendered",
+]

weft_command-2.1.0/src/weft_command/contract.py

@@ -0,0 +1,221 @@
+"""The `Command` contract — published here, never by the kernel and never by `weft-cli`.
+
+Task **3.1**: "a pack registers a command exactly as it registers a retriever, and a command
+that declares no permission class fails to register while its author is standing there"
+(`docs/build-ledger.md`). `docs/03-cli.md` → *Plugin-contributed commands*: "A pack registers
+commands against the `Command` contract exactly as it registers a retriever."
+
+**Why this distribution, and not `weft-kernel` or `weft-cli` — an architectural decision this
+task took, which no prior document had settled.**
+
+- **Not `weft-kernel`.** G1 draws the line exactly: the kernel expresses, loads and runs
+  contracts it knows nothing about, and publishes none of its own (`docs/02-extension-model.md`
+  §1 → *Who publishes a contract*). `Command` names a capability — "a CLI-invoked action" — the
+  same way `Extractor`, `Chunker` and `Prompt` do, and CLAUDE.md states the test plainly: "if
+  you cannot describe the kernel without naming a capability, it is too big."
+- **Not `weft-cli`.** `weft-cli` is `docs/03-cli.md`'s **driving adapter** — "every operation it
+  performs is a library call a FastAPI route could make identically" — and a pack that
+  contributes a command is a **driven** side of that same call, exactly as a pack contributing a
+  retriever is. Publishing `Command` from `weft-cli` would mean a third-party command pack
+  depending on the adapter to implement the contract the adapter itself drives, which inverts
+  the dependency direction the whole extension model is organised around (`docs/02` §1: "a pack
+  depends on the pack that publishes the contract it implements, exactly as it would on any
+  third-party protocol" — never on the thing that *calls* it). Concretely, `weft-cli`'s own
+  `pyproject.toml` already names nine other distributions as dependencies
+  (`weft-kernel`, `weft-extract`, `weft-chunk`, `weft-embed`, `weft-store`, `weft-llm`,
+  `weft-prompts`, `weft-retrieve`, `weft-generate`); a command pack that had to depend on
+  `weft-cli` to get `Command` would inherit every one of those transitively for the sole purpose
+  of reading one Protocol.
+- **The precedent is `weft-prompts`.** A distribution that publishes a contract and registers no
+  plugin of its own is not a new shape — `weft_prompts.contract.Prompt` lived exactly this way
+  from task 2.10 until the first prompt landed and added the entry-point line. `weft-command`
+  takes the identical position: it publishes `Command` and `PermissionClass`
+  (`weft_command.permission`), declares no `[project.entry-points."weft.packs"]` block (fitness
+  function 2 requires every distribution declaring that entry point to be active *and
+  contributing*, and this one contributes nothing of its own), and `weft-cli` gains it as a
+  ninth-turned-tenth dependency the same way it already depends on `weft-prompts` for `Prompt`.
+
+**`Command` is not a pipeline position**, on `weft_prompts.contract.Prompt`'s own footing and
+for the identical reason: `.phase2-design.md` §3 groups `Prompt` and `LLMProvider` as "named and
+registered, but not pipeline positions", and a CLI command is invoked once per `weft` invocation
+(or once per REPL turn), never composed into an ingest or query `StageSpec` list. It therefore
+declares no `Stage` base — `weft_kernel.runner.Runner.resolve` has no reason to see it, and
+`weft_cli.contract_reference.capability_siblings`' own `_is_stage_protocol` filter, built for
+exactly this family of "one method, several unrelated contracts sharing its name", never needs a
+special case for it.
+
+**`args_model` and `result_model` are declared in the Protocol body, deliberately** — the
+identical choice `weft_prompts.contract.Prompt` makes for `input_model`/`output_model`, and for
+the same reason stated there: a command whose arguments are an untyped `argparse.Namespace` is
+the shape this contract exists to replace, and a renderer needs `result_model` to introspect a
+result's shape without having been written against any one command by name. Required for
+`isinstance` is the cost, stated once so nobody rediscovers it: `issubclass` against a Protocol
+with non-method members raises `TypeError`, so a future walk over registered `Command`s must use
+`isinstance` against a constructed instance, never `issubclass` against the class.
+
+**`run` takes `args` at the call, not at construction — `Prompt.render`'s shape, not `Stage`'s.**
+A `Stage` plugin binds its `with:` configuration once, at construction, because one pipeline
+position runs many payloads through the identical configuration. A `Command` is the opposite: the
+same registered instance answers a different, freshly parsed `args` on every invocation — one
+shot from the CLI, or turn after turn in the REPL (`docs/03-cli.md` → *Two modes, one
+implementation*: "Both go through the same command objects.") — so binding `args` at construction
+would mean constructing a fresh instance per invocation for no reason `Lifetime.PROCESS` could
+ever amortise.
+
+**The governing property this task builds into the signature, per `docs/03-cli.md` → *Two modes,
+one implementation*:** "a `Command` returns a typed result and never writes to a stream." `run`
+returns a decided `Outcome[CommandResult]` — `Produced` / `NothingToProduce` / `Failed`, `02` §1's
+own vocabulary applied here as it is everywhere else a contract answers — never a printed line and
+never a bare value. `weft_cli` renders `Produced.value` for a human, `--json` renders the
+identical value for a script, and the REPL renders it again with the session's context around
+it; none of that is buildable if this method had already chosen a renderer by printing.
+
+**`permission_class` is mandatory and declared nowhere in this file** — the same asymmetry
+`weft_chunk.contract.Chunker` has with `destroys`, and for the identical reason. `docs/03-cli.md`
+→ *Permissions*: "The class is a `ClassVar` on the `Command` contract, read at registration
+alongside `lifetime`, `requires` and `provides`; a command that declares none fails to register,
+loudly, while its author is standing right there. No default is safe." Declaring
+`permission_class` directly in the Protocol body would make it a required `isinstance` member,
+checked only once an *instance* exists — too late, since refusing at registration means refusing
+before any instance is ever constructed. `Command.required_declarations = ("permission_class",)`
+is instead read by `weft_kernel.registry`'s generalised mandatory-declaration check (task 3.1's
+own repair to that module — see its docstring, *"`destroys` generalised into
+`required_declarations`, not duplicated"*), the identical mechanism `Chunker.
+publishes_property_vocabulary` already drives for `destroys`, applied to a second name without
+the kernel ever learning the word `Command` or `permission`.
+
+**What this task deliberately leaves to 3.2 and 3.4.** Namespacing a pack's commands under its
+own name (`docs/03-cli.md`: "`weft graph build`") is a registration-*name* convention, not a
+contract shape — `registrar.add(Command, "graph build", GraphBuildCommand)` registers under
+`weft_kernel.registry` exactly as any other string name would, and turning that string into
+argparse subcommand wiring, generated `--help` text and REPL completion is task 3.2's own
+("`weft --help` cannot drift from what is installed, because core has no command list to edit").
+Likewise, rewiring `weft_cli.cli.COMMANDS`'s five built-in commands onto this contract, and
+building the renderer that actually turns a `CommandResult` into text/JSON/REPL output, are 3.4's
+("the interactive session and the one-shot invocation are the same commands with a different
+implementation") — `weft_cli.permissions.CliCommand` was expected to stay untouched a task
+longer than it did: task 3.2 found the 3.2/3.4 split stated above too narrow (converting the
+built-ins requires exactly the parser-generation and a minimal renderer it names, neither the
+REPL nor the plural `--json`/REPL renderers 3.4 owns) and rewired all five onto this contract
+immediately, deleting `CliCommand` and `weft_cli.permissions` as dead code — see
+`weft_cli.commands`'s own module docstring for the full account.
+
+**Task 3.2 adds `help` — the one piece of metadata 3.1 left this contract without, and the one a
+generated `--help` cannot do without.** `docs/03-cli.md` → *Plugin-contributed commands*: "Core has
+no list of commands to edit. The help text is generated from the registry" — which needs a
+one-line string to generate *from*, and nothing on `Command` as 3.1 shipped it carried one.
+`required_declarations` grows to `("permission_class", "help")` rather than gaining a second,
+parallel mechanism: `help` is exactly as mandatory as `permission_class` and for the identical
+reason — a command with no help text is not a smaller problem than one with no permission class,
+it is `weft --help` printing a blank line or crashing outright for whichever plugin forgot it,
+discovered by a stranger long after the author who could have been told at registration is gone.
+Declared under `if TYPE_CHECKING:`, exactly like `version` and `required_declarations` themselves
+— never a required `isinstance` member, for the same reason `permission_class` is not one: refusing
+at registration means refusing before any instance exists to check, and `hasattr` on the class is
+the only test available at that point.
+
+**`COMMAND_CONTRACT_VERSION` was recorded as `"1.1.0"` here, and that was a mis-recorded major —
+corrected to `"2.0.0"` at task **5.2a**, per `docs/README.md` → G9's settled two-audience rule
+(`docs/09-release.md` §2.3).** Adding `help` to `required_declarations` is a minor change for a
+*caller* — nothing that only ever reads a `Command` through this Protocol changes — but a **major**
+change for an *implementer*: every existing `Command` that does not already declare `help` breaks
+at registration, loudly, the instant this contract is depended on at the corrected range. G9's
+table classifies exactly this row ("add a name to `required_declarations`") as `—` / **major** /
+**major**, and the bump a Protocol change takes is the maximum of the two audiences, never the
+caller's alone. At the time this docstring first recorded `"1.1.0"`, G9 had not yet settled that
+rule, so the bump was chosen from the caller's side only; it is corrected here rather than left
+mis-recorded once the rule existed to correct it against — the identical honesty G9's own settled
+row applies to itself.
+
+**Task 6.20 (G13) bumps `COMMAND_CONTRACT_VERSION` again, to `"2.1.0"` — this time minor, not
+major, and the reasoning is stated at the time the bump is taken rather than left for a later
+task to reconstruct.** `weft_command.render.Rendered` and `.ExitCode` are published from this
+distribution and re-exported here (see that module's own docstring for why a renderer's
+vocabulary belongs beside the contract that produces the result it formats), and
+`weft_kernel.discovery.PackRegistrar` gains a further registration seam, `add_renderer` — but
+nothing on the `Command` Protocol itself changed, `required_declarations` is untouched, and a
+pack that registers no renderer still works exactly as it did before this task, because the
+unregistered-result structured-dump fallback is the floor and stays the floor. Applying G9's
+table honestly: additive for a *caller* (nothing that reads `Command` through this Protocol
+changes) and additive for an *implementer* (no existing `Command` implementation breaks at
+registration), and the maximum of the two is minor.
+"""
+
+from typing import TYPE_CHECKING, ClassVar, Protocol, runtime_checkable
+
+from pydantic import BaseModel, ConfigDict
+
+from weft_command.render import ExitCode as ExitCode
+from weft_command.render import Rendered as Rendered
+from weft_kernel.context import Context
+from weft_kernel.payload import Outcome
+
+#: Fitness function 6's subject for this contract — see the module docstring's note on the
+#: correction at task 5.2a: the 3.2 bump to "1.1.0" (when `help` joined `required_declarations`)
+#: was a mis-recorded major, per G9's two-audience rule, corrected to "2.0.0".
+#:
+#: **Task 6.20 bumps this to "2.1.0" — additive for both audiences, so minor, not major.**
+#: `docs/09-release.md` §2.3, G9's two-audience rule, applied at the time this bump is taken
+#: rather than left for a later task to reconstruct: nothing on the `Command` Protocol itself
+#: changed, `required_declarations` is untouched, and a pack that registers no renderer through
+#: the new `PackRegistrar.add_renderer` seam still works exactly as before — the unregistered-
+#: result structured-dump fallback is the floor, and stays the floor. Publishing `Rendered` and
+#: `ExitCode` from this module (see `weft_command.render`) grows the surface without breaking
+#: anything either audience already depended on, which is what "minor" means under G9's table:
+#: the maximum of "additive for a caller" and "additive for an implementer" is still additive.
+COMMAND_CONTRACT_VERSION = "2.1.0"
+
+
+class CommandResult(BaseModel):
+    """The typed result a `Command` returns — never printed text, per the module docstring.
+
+    Frozen per CLAUDE.md ("Frozen where the value is a domain object"), and the base every
+    concrete command's own result model subclasses with its own fields, the same relationship
+    `weft_kernel.payload.outcome`'s `Produced[T]` has to whatever `T` a contract names: a
+    renderer built against this base type can accept any command's result without having been
+    written against that command by name, which is what lets `weft_cli` render a plugin's
+    command exactly as it renders a built-in one. Carries no fields of its own — a bare
+    `CommandResult()` states nothing, and every real command adds what it actually produced.
+    """
+
+    model_config = ConfigDict(frozen=True, extra="forbid")
+
+
+@runtime_checkable
+class Command(Protocol):
+    """One CLI-invoked action a pack contributes, registered exactly as it registers a retriever.
+
+    Not a pipeline position — see the module docstring's *"`Command` is not a pipeline
+    position"* paragraph. `run` accepts the parsed, already-validated arguments and returns a
+    decided `Outcome[CommandResult]`, never printed text — see the module docstring's paragraph
+    on *"The governing property this task builds into the signature."*
+    """
+
+    if TYPE_CHECKING:
+        #: See `weft_extract.contract`'s module docstring for the full `__protocol_attrs__`
+        #: reasoning behind the `if TYPE_CHECKING:` / assign-after-the-class-body split, which
+        #: applies here unchanged for both of these: neither may become a required `isinstance`
+        #: member, or a structurally-conforming `Command` that never restates them would fail a
+        #: capability check that has nothing to do with capability.
+        version: ClassVar[str]
+        #: See the module docstring's paragraph on `permission_class` — this names the class
+        #: attribute every implementation must carry; it does not carry the value itself.
+        required_declarations: ClassVar[tuple[str, ...]]
+        #: The one-line summary `weft --help` prints beside this command's name — see the
+        #: module docstring's *"Task 3.2 adds `help`"* paragraph. Mandatory via
+        #: `required_declarations`, not a required `isinstance` member, for the identical
+        #: reason `permission_class` is not one.
+        help: ClassVar[str]
+
+    #: The model `run` accepts. Required for `isinstance` — see the module docstring's
+    #: `args_model`/`result_model` paragraph.
+    args_model: ClassVar[type[BaseModel]]
+    #: The `CommandResult` subclass `run` produces on success. Required for `isinstance`, for
+    #: the identical reason `args_model` is.
+    result_model: ClassVar[type[CommandResult]]
+
+    async def run(self, args: BaseModel, ctx: Context) -> Outcome[CommandResult]: ...
+
+
+Command.version = COMMAND_CONTRACT_VERSION
+Command.required_declarations = ("permission_class", "help")

weft_command-2.1.0/src/weft_command/permission.py

@@ -0,0 +1,44 @@
+"""`PermissionClass` — the five-member, closed vocabulary `docs/03-cli.md` → *Permissions* fixes.
+
+Task **3.1** moves this out of `weft_cli.permissions`, where it lived as a stand-in until the
+`Command` contract itself existed (`weft_cli.permissions`'s own former docstring: "the `Command`
+*contract* ... is Phase 3's ... gated on G8"). G8 settled 2026-08-18 and this distribution is
+that contract's home — see `weft_command.contract`'s module docstring for why `Command` lives
+here rather than in `weft-kernel` or `weft-cli`. `PermissionClass` moves with it because a
+permission class is meaningless without the contract that reads it: `Command.required_declarations`
+names `permission_class` as mandatory (`weft_kernel.registry`'s generalised check, task 3.1), and
+the vocabulary that field's values are drawn from belongs beside the contract, not beside one
+particular renderer of it.
+
+**`weft_cli.permissions` — the re-export this class briefly had — is gone as of task 3.2.** It
+existed only to keep `weft_cli.cli.COMMANDS`'s hand-written table importing one name from two
+places during the 3.1→3.2 transition; 3.2 deleted `COMMANDS` itself (every built-in command is
+now a `weft_command.contract.Command` plugin in `weft_cli.commands`, which imports
+`PermissionClass` directly from here, on the same footing any third-party command pack does), so
+the stand-in had no remaining caller and staying would have been the exact kind of drift-prone
+duplicate name this contract's own placement exists to avoid.
+
+`Enum`, never `Literal[...]`, per CLAUDE.md. The five members are fixed by `docs/03-cli.md`'s own
+table — `read`/`write` default to allow, `overwrite`/`destroy` default to ask, `network` defaults
+to allow but stays configurable — and defaults are policy a renderer or `weft.toml` enforces,
+not a fact this enum carries; see `docs/03-cli.md` → *Permissions* for the table in full.
+"""
+
+from enum import StrEnum
+
+
+class PermissionClass(StrEnum):
+    """The five classes `docs/03-cli.md` → *Permissions* names.
+
+    **No default anywhere a `Command` implementation reads this from.** A plugin-contributed
+    command must declare exactly one of these — `Command.required_declarations` makes silence a
+    registration refusal, never a fallback to `read` — because `read` silently under-protects and
+    `destroy` trains an operator to pass `--yes` reflexively, disarming the whole table
+    (`docs/03-cli.md` → *Permissions*).
+    """
+
+    READ = "read"
+    WRITE = "write"
+    OVERWRITE = "overwrite"
+    DESTROY = "destroy"
+    NETWORK = "network"

weft_command-2.1.0/src/weft_command/render.py

@@ -0,0 +1,67 @@
+"""`ExitCode` and `Rendered` — a renderer's own vocabulary, published beside the `Command`
+contract that produces the result a renderer formats.
+
+Task **6.20**, G13's third repair (`docs/03-cli.md` → *Plugin-contributed commands*): "a
+result type nobody outside the CLI can format is only half a contract." Both classes moved
+here from `weft_cli` — `ExitCode` out of `weft_cli.exit_codes`, `Rendered` out of
+`weft_cli.render` — because a renderer registered by a third-party pack (`weft_kernel.
+discovery.PackRegistrar.add_renderer`) has to build one of these to answer with, and a pack
+implementing `Command` must not depend on `weft-cli`, the driving adapter that calls it, for
+the vocabulary its own renderer speaks — the identical reasoning `weft_command.contract`'s
+own module docstring already gives for why `Command` itself lives here rather than in
+`weft-cli`.
+
+**`ExitCode` travels with `Rendered` rather than staying behind, and that is a deliberate
+choice, not a convenience.** A renderer that cannot say the run failed is a renderer a
+built-in could not have used: `weft delete` and `weft index` both compute their own exit
+code from their own result's fields (a partial deletion, or an index run with failures, is
+success at the process level and failure at the operation level — see `weft_cli.render`'s
+own `_render_delete`/`_render_index`), so a third-party renderer needs the identical
+five-value vocabulary to state the same kind of fact about its own result. `weft_command.
+permission.PermissionClass` is the standing precedent for a `docs/03-cli.md` concept living
+in this pack rather than in `weft-cli`: this pack already publishes a vocabulary that
+document defines, because the contract is unusable without it.
+
+**`CommandResult` still names no exit code — what moved is the *renderer's* vocabulary, not
+the result's.** `weft_cli.render`'s retired docstring argued exactly this, and the argument
+still holds unchanged now that `ExitCode` and `Rendered` live here instead: `CommandResult`
+is capability-agnostic, and `IndexCommandResult.summary.failed > 0` still has to become exit
+code `1` somewhere — that "somewhere" is still whichever renderer a pack registers through
+`PackRegistrar.add_renderer`, computed from the typed fields a command actually returned,
+never smuggled into the result itself.
+"""
+
+from __future__ import annotations
+
+from dataclasses import dataclass
+from enum import IntEnum
+
+
+class ExitCode(IntEnum):
+    """`docs/03-cli.md` → *Output*: "0 success, 1 operation failed, 2 bad usage, 3 refused for
+    permissions, 4 pipeline failed to resolve." `2` is never assigned by a renderer — `argparse`
+    itself calls `sys.exit(2)` on a usage error, before any command runs, so nothing downstream
+    of a `Command`'s own `run` ever needs to produce it.
+    """
+
+    SUCCESS = 0
+    OPERATION_FAILED = 1
+    BAD_USAGE = 2
+    POLICY_REFUSED = 3
+    RESOLUTION_FAILED = 4
+
+
+@dataclass(frozen=True, slots=True)
+class Rendered:
+    """What a renderer answers with — stdout, stderr, and the exit code the process should
+    report. `None` on either stream means nothing prints on it.
+
+    Every renderer registered through `weft_kernel.discovery.PackRegistrar.add_renderer`
+    returns one of these, whether it is one of `weft_cli`'s own eighteen built-in renderers
+    or a third party's — a `Rendered` built by a stranger's pack is indistinguishable from
+    one `weft_cli.render` built itself, which is the property task 6.20 exists to make true.
+    """
+
+    stdout: str | None
+    stderr: str | None
+    exit_code: ExitCode