runward 0.12.1 → 0.13.0

package/templates/rules/security-code-execution-sandbox.md

@@ -0,0 +1,20 @@
+---
+title: Unexpected Code Execution Runs Sandboxed, Never In-Process
+impact: CRITICAL
+asi: [ASI05, ASI02]
+phases: [govern]
+impactDescription: Caps the blast radius of any code the agent runs (generated or tool-provided) by isolating it from the host, secrets and network
+tags: [security, code-execution, sandbox, isolation]
+---
+
+## Unexpected Code Execution Runs Sandboxed, Never In-Process
+
+> **Code the model produced, or a tool ran, is untrusted input that acts.** It executes in an isolated, least-privilege sandbox, never in the agent's own process.
+
+Any path where a model output becomes execution — a code interpreter, a shell tool, an `eval`, a generated script, a plugin that runs code — is treated as **unexpected code execution** and confined:
+
+- **Isolation, not trust.** The code runs in a sandbox with no access to the host filesystem, the agent's process memory, the network, or secrets, unless a capability was explicitly and narrowly granted. Generated code never inherits the agent's privileges.
+- **An explicit, approved capability, never an implicit tool.** "Run arbitrary code" is not a default tool the model may call at will; it is a declared, approval-gated capability with a bounded scope (allowed language, timeout, resource ceiling, allowed paths and syscalls).
+- **No path from untrusted content to execution.** Retrieved or user-supplied content must not reach a code-execution surface without the deterministic guard and human approval on the action (see `security-prompt-injection`, the 2-of-3 rule).
+
+Form validation is not enough: a model can emit syntactically valid code that deletes data or exfiltrates a secret. The boundary around execution is owned and tested, not hoped.

package/templates/rules/security-human-agent-trust.md

@@ -0,0 +1,20 @@
+---
+title: Provenance on Every Field, So the Human Never Trusts a Guess
+impact: HIGH
+asi: [ASI09]
+phases: [govern]
+impactDescription: Stops a model-proposed value being read as a verified fact at the approval point — the human decides on real provenance, never on fabricated confidence
+tags: [security, trust, provenance, human-oversight]
+---
+
+## Provenance on Every Field, So the Human Never Trusts a Guess
+
+> **The model writes the prose; the program owns the facts — and the human must be able to tell which is which.** A model-proposed value is never presented as verified.
+
+Human-agent trust breaks when a person approves an action believing the agent's output was checked, when it was only proposed. The guard is provenance made visible, and approval placed on the action:
+
+- **Every field carries a provenance marker** — `computed`, `verified`, or `model-proposed` — so the human, and the code, can tell a fact the program owns from a value the model guessed. A `model-proposed` value that would act on the world is refused fail-closed until it is verified or approved (see `frontier-deterministic-boundary`, `data-memory-provenance`).
+- **Approval is on the action, shown with its provenance**, never on a wall of confident prose. The human sees what is proposed versus verified before deciding, so a sign-off is a real decision, not a reflex.
+- **The agent never impersonates a human or an authority.** It is an identified principal, distinct from the user it serves; its outputs are attributable to the agent, and it never claims a certainty, a sign-off, or an identity it does not have.
+
+Confident tone is not correctness. The system makes the difference legible, so the human's trust is placed on evidence, not on fluency.

package/templates/workflows/architect.md

@@ -19,11 +19,11 @@ Use this workflow once framing is decided and structure must follow: "how do we
 
 ## Procedure
 
-**Refuse stack questions, again.** Contracts first, technology later. The phase rests on the method's founding inversion — the LLM Boundary Principle: the architecture constrains the model, never the reverse. The model and the infrastructure are adapter decisions, taken behind stable contracts. That is why boundaries come before stack. Each stack choice is taken adapter by adapter once boundaries are known, justified by a local technical reason — never by habit.
+**Refuse stack questions, again.** Contracts first, technology later. The phase rests on the doctrine's guiding principle: the architecture constrains the model, never the reverse. The model and the infrastructure are adapter decisions, taken behind stable contracts. That is why boundaries come before stack. Each stack choice is taken adapter by adapter once boundaries are known, justified by a local technical reason — never by habit.
 
 **Fix the two boundaries that make the stack secondary.**
 
-1. **Domain ports.** The domain expresses its needs as contracts: generate a model completion, persist state, execute an action, read a source. Each contract is honored by an adapter written in any language, as long as it honors the contract. The model port is a port like any other: the reasoning engine is bound only by its contract, not by its brand. The daily dividend is a domain testable without the model; substitutability is the insurance you keep in reserve. This is the founding inversion made concrete: the model is a replaceable adapter behind a stable port.
+1. **Domain ports.** The domain expresses its needs as contracts: generate a model completion, persist state, execute an action, read a source. Each contract is honored by an adapter written in any language, as long as it honors the contract. The model port is a port like any other: the reasoning engine is bound only by its contract, not by its brand. The daily dividend is a domain testable without the model; substitutability is the insurance you keep in reserve. This is the guiding principle made concrete: the model is a replaceable adapter behind a stable port.
 2. **The cross-process integration protocol.** When a capability lives in another process or language, expose it through a standardized tool protocol. The system consumes that process as a tool provider and publishes its own capabilities the same way. A service is just an adapter that moved into its own process; the domain does not change.
 
 **Govern every contract.** A port is more than a typed schema. Version it; make changes additive by default; read as a tolerant reader that ignores unknown fields and accepts missing optional ones. For a genuinely breaking change, expand then contract: introduce the new, migrate consumers, retire the old — never in one move. Track provenance: who produces, who consumes, under which version, so impact is measurable before a change. Fix meaning per bounded context: without pinned semantics the model will invent false mappings; the semantic contract is to meaning what the typed schema is to malformed data. On legacy, the adapter becomes an anticorruption layer that translates the old dialect into the domain language without contaminating the new — and that boundary is never free: name the translation cost and budget it.

package/templates/workflows/method.md

@@ -12,7 +12,7 @@ Use this workflow whenever an agentic-system mission needs to be planned, advanc
 
 ## Procedure
 
-**Hold the posture before any phase.** Three rules outrank every tooling preference. Mentor as much as engineer — listening outranks solving: understand the process as it actually runs, not as it is described. Prove with a running system, not a deck. Decide architecture before models: the model and the infrastructure are adapter choices, reversible, made behind stable ports. The founding inversion underneath — the LLM Boundary Principle: the architecture constrains the model, never the reverse — opens the method; what carries it is the six phases, the **five architecture gestures** — boundaries before stack; isolate by contract and complexify on proof; take determinism out of the model; keep state explicit and memory governed; govern, trace and evaluate from day zero — and the decision matrix. These architecture gestures shape the system, and are not to be confused with the opening moves that start the mission (below).
+**Hold the posture before any phase.** Three rules outrank every tooling preference. Mentor as much as engineer — listening outranks solving: understand the process as it actually runs, not as it is described. Prove with a running system, not a deck. Decide architecture before models: the model and the infrastructure are adapter choices, reversible, made behind stable ports. The principle underneath — the architecture constrains the model, never the reverse — opens the method; what carries it is the six phases, the **five architecture gestures** — boundaries before stack; isolate by contract and complexify on proof; take determinism out of the model; keep state explicit and memory governed; govern, trace and evaluate from day zero — and the decision matrix. These architecture gestures shape the system, and are not to be confused with the opening moves that start the mission (below).
 
 **Open the chain with four opening moves, in order, with the sponsor** — the mission's opening ritual, distinct from the five architecture gestures above. Together with show-before-you-build, they form four opening moves plus a standing show-before-you-build discipline.