@oracle-agent/oracle 0.35.20 → 0.35.21

package/dist/assets/skills/oracle-desk-product/SKILL.md

@@ -97,11 +97,17 @@ does not prove npm users receive it. A locally hosted model/data/policy loop doe
 a bundled signer. A merged feature is not public until the npm artifact containing it is
 published and inspected.
 
-**Candidate release in this source tree:** public package `@oracle-agent/oracle@0.35.20`
+**Candidate release in this source tree:** public package `@oracle-agent/oracle@0.35.21`
 ships the encrypted local vault + short-lived loopback signer. Hosted/keyless
-Oracle cannot hold keys or move funds. Self-host after `oracle sign init|import` is **auto-armed**
-for user-initiated actions. Public still charges the disclosed fee card; Administrator
-(`@oracle-agent/agent`, never on npm) stays zero-fee with DEMI's keys.
+Oracle cannot hold keys or move funds. Self-hosting with `oracle sign init` or
+`oracle sign import --kind evm --key-file <0600 file>` writes an encrypted vault and marks
+the signer ARMED/ready. `allowed` remains false. An explicit command asks for confirmation
+before signing, executing, or broadcasting. The only same-turn shortcut is to say `quick
+transaction` and explicitly confirm in the same sentence. An explicitly configured autonomous
+grant, such as a shadow-profit promotion rule, is the separate exception. Signing still
+requires a sealed policy plus a short-lived signer session. Public follows Administrator
+execution behavior but charges the disclosed fee card; Administrator (`@oracle-agent/agent`,
+never on npm) stays zero-fee with DEMI's keys.
 
 Public signer families are **EVM, Solana, Bitcoin only** — not separate HL/Poly
 account surfaces. Do not resurrect Tread.fi OEMS/API protocol interaction; TradFi
@@ -114,18 +120,18 @@ matches the intended release and the packed tarball was secret-scanned. Never ac
 
 Detail: `references/public-admin-parity.md`.
 
-**Key-path wiring bug found + fixed 2026-08-09 (verify this stays wired).** `oracle sign
-import` wrote the key to `<config>/keys/evm.json` and armed `exec.env`, but the loopback
-signer daemon resolves key material from the vault path written by `oracle sign import`.
-A freshly imported key was **silently
-never picked up** by `oracle signer` — import reported success, signing just never found
-it. Fix: import now also writes `signer.env` pointing both vars at the file it created,
-preserving other entries (`wireSignerKeyEnv` in `src/cli/commands/sign.mjs`; regression
-test in `test/cli-signplane.test.mjs` asserts key material, shred, arm, AND env wiring).
-Lesson for this class: "the key file exists on disk" is NOT proof the signer can sign —
-trace provision → env → daemon resolution end to end before claiming a signer works.
-Note `sign.mjs` is ESM: helpers need `await import("node:fs"/"node:path")`, and `join`
-scoped inside a verb block is not visible to a module-level helper.
+**Current signer provisioning contract (verify this stays wired).** `oracle sign init` creates
+an encrypted EVM keyring. `oracle sign import --kind evm|btc|sol --key-file <0600 file>`
+imports protected key material into the same vault. The passphrase comes from a hidden TTY or
+`--passphrase-file <0600 file>`, and the encrypted keyring is stored at
+`<config>/signer/vault.json`. Importing marks the signer ARMED/ready, but it does not sign,
+execute, submit, trade, or broadcast. An explicit command asks for confirmation; execution
+starts only after confirmation. The only same-turn shortcut is `quick transaction` plus an
+explicit confirm in the same sentence. An explicit autonomous grant and its configured trigger
+are the separate exception. A signer can act only after `oracle sign policy --policy-file <0600
+JSON file>` seals nonempty allowlists and a short-lived signer session starts. Never accept
+private keys in arguments, environment variables, chat, or app UI. Trace provision, vault
+resolution, policy, session, and receipt end to end before claiming the signer works.
 
 The gap found 2026-08-09: agent enforced only its own env caps (`ORACLE_MAX_NOTIONAL_USD`, …)
 and NEVER read the app's `agent-policy.json` — two B walls that could drift (app UI noLimits
@@ -332,7 +338,7 @@ authorized recipient auditable.
 - `references/agent-policy-nolimits.md` — noLimits / API actions  
 - `references/agent-parity.md` — agent=admin variant parity diff, shared-policy hash fix, merge-vs-remote-CI-shape-tests technique  
 - `references/agent-rename-and-npm.md` — the 2026-08-09 operator→agent rename procedure + npm unpublish/deprecate/2FA knowledge
-- `references/public-admin-parity.md` — public vs Admin: whose keys, fees, auto-arm, EVM/SOL/BTC-only signer, no Tread OEMS  
+- `references/public-admin-parity.md` — public vs Admin: whose keys, fees, vault provisioning vs arming, EVM/SOL/BTC-only signer, no Tread OEMS
 
 ## Related
 

package/dist/assets/skills/oracle-mcp-install/SKILL.md

@@ -89,30 +89,25 @@ oracle mcp watchdog --once   # one-shot health check
 ## Wallet setup
 
 ```bash
-oracle init --apply                     # generates fresh wallet at ~/.config/oracle/keys/evm.json (0600)
-oracle sign import                      # interactive: paste existing private key (hidden input)
-oracle sign import --keyfile <path>     # import from file (auto-shreds temp file after import)
+oracle sign init [--passphrase-file <0600 file>]
+oracle sign import --kind evm --key-file <0600 file> [--passphrase-file <0600 file>]
+oracle sign import --kind btc --key-file <0600 file> [--passphrase-file <0600 file>]
+oracle sign import --kind sol --key-file <0600 file> [--passphrase-file <0600 file>]
+oracle sign policy --policy-file <0600 JSON file>
+oracle sign status
+oracle sign doctor
 ```
 
-Both `oracle sign import` paths **auto-arm** — importing a key sets `ORACLE_EXEC_ENABLED=1`
-in `~/.config/oracle/exec.env`. No separate `oracle exec arm` step needed.
-The intent is the signal: pasting a private key means the user wants to trade immediately.
-
-**Rationale:** The user explicitly chose to import their private key and wire the exec MCP.
-Adding a mandatory \"arm\" step on top is unnecessary friction. Import = armed.
-
-**Safety boundary:** The key never leaves the local machine. Oracle's wallet is like a
-CLI-native MetaMask — key on disk at 0600, MCP process local to the machine, same trust model.
-
-The interactive prompt reassures users:
-```
-Your key stays local — Oracle never sends it anywhere.
-Paste your EVM private key (0x...):
-> 
-```
-Key goes to stdin, never to shell history. Saved at 0600 permissions.
-
-Never use `echo "0xKEY"` or `--key 0x...` — private keys must never hit shell history.
+The passphrase comes from a hidden TTY prompt or an owner-only file. Key material comes only
+from `--key-file`; Oracle refuses private keys in arguments and inherited environment variables.
+The encrypted keyring lives at `<config>/signer/vault.json`. Importing marks the signer
+ARMED/ready, but `allowed` remains false. An explicit command asks for confirmation before
+signing, executing, or broadcasting. The only same-turn shortcut is to say `quick transaction`
+and explicitly confirm in the same sentence. An explicitly configured autonomous grant, such
+as a shadow-profit promotion rule, is the separate exception. Signing still requires a sealed
+policy with nonempty allowlists and a short-lived signer session. Public follows Administrator
+execution behavior and applies the disclosed public fees.
+Never ask users to paste private keys into chat, app UI, or shell arguments.
 
 ## Print mode
 ```

package/dist/assets/skills/protocol-api-key-integration/SKILL.md

@@ -97,23 +97,26 @@ Cover, in this order:
    need to know they can evaluate the thing before handing over credentials.
    Hyperliquid reads are keyless; Polymarket market data is keyless.
 3. **Per-venue credential shape**, because they differ structurally:
-   - **Hyperliquid issues no API key.** You authorize with an Ethereum private
-     key — use an **API wallet** (`app.hyperliquid.xyz/API`) that can trade but
-     **cannot withdraw**. Say that explicitly; it is the single most important
-     safety fact for an agent.
+   - **Hyperliquid issues no API key.** An owner-local signer authorizes requests
+     with a dedicated **API wallet** (`app.hyperliquid.xyz/API`) that can trade but
+     **cannot withdraw**. The key stays in the protected local signer vault and is
+     never passed through chat, prompts, arguments, or inherited environment.
    - **Polymarket needs two different things**: L2 API credentials
-     (`API_KEY`/`API_SECRET`/`API_PASSPHRASE`) for CLOB order posting, *and* the
-     Polygon private key that owns the funds. Conflating them wastes an hour.
-4. **Storage, worst → best**, with the honest tradeoff at each tier: env vars
-   (visible in `ps`, inherited by children), a `0600` key file, an encrypted
-   vault. Include the `chmod`/`printf` commands so nobody invents their own.
+     (`API_KEY`/`API_SECRET`/`API_PASSPHRASE`) for CLOB order posting, *and* an
+     owner-local signer for the Polygon wallet that owns the funds. Conflating
+     them wastes an hour; neither credential belongs in model context.
+4. **Storage is owner-local and fail closed.** Use the documented protected `0600`
+   key-file and encrypted signer-vault workflow. Never print, paste, or interpolate
+   key material into shell commands, chat, prompts, or process arguments.
 5. **What the encryption does NOT protect.** A vault defends backups, cloud sync,
    and stolen disks at rest; it does **not** defend malware running as the user
    while the process is unlocked. Overselling a file-level scheme is worse than
    shipping none, because it changes behaviour.
 6. **Both trade paths side by side** — non-custodial (Oracle prepares, user's
-   wallet signs) and agentic (Oracle holds a key and submits) — so the reader
-   picks deliberately rather than defaulting into custody.
+   wallet signs) and automated owner-local execution (the signer submits only
+   after the user's explicit bounded authorization, including an explicitly
+   configured shadow-profit promotion rule) — so the reader picks deliberately
+   rather than defaulting into custody.
 
 Also state where credentials travel: pinned provider endpoints, key dropped
 rather than forwarded when a `baseUrl` is redirected or downgraded to `http://`.

package/dist/assets/skills/self-custodial-onchain-execution/SKILL.md

@@ -21,27 +21,28 @@ A wallet signature proves address control, not operator/admin authority.
 
 An open preview may accept any signed wallet only when every money-moving action remains self-custodial and backend live submission is absent from the build.
 
-## Arming posture: key present = armed, user asks = it runs
+## Arming posture: key present = armed, confirmation = it runs
 
 **DEMI correction — do not gate each capability behind its own env flag.**
 
 ```
 Key present      -> capability is ARMED
-User asks for it -> it RUNS
+User commands it -> ask for CONFIRMATION
+User confirms it -> it RUNS
+Quick transaction + confirm in one sentence -> it RUNS
 Autonomous mode  -> the ONLY separate opt-in
 ```
 
-Supplying a signing key **is** the authorization decision. Making someone who
-already handed over a key hunt down a second and third `ORACLE_X_ENABLED=1` to
-buy an NFT is friction, not security — and it teaches people to set every flag,
-which is strictly worse than one coherent default. What actually protects the
-user is that every action is **user-initiated** and **bounded by caps at the
-moment it runs**.
+Installing the owner-local signer vault is the readiness/arming decision, not an
+execution instruction. Making someone with an armed signer hunt down a second
+and third `ORACLE_X_ENABLED=1` to buy an NFT is friction, not security, and it
+teaches people to set every flag. What protects the user is that every action is
+**user-initiated**, **confirmed**, and **bounded by caps at the moment it runs**.
 
 Autonomous/unattended trading is the sole exception, because it is the only mode
-where the agent initiates value movement without being asked. An agent that
-trades while you sleep is a different risk class from one that buys the NFT you
-just named.
+where the agent initiates value movement without a new instruction. It requires
+an explicit autonomous grant, including any configured promotion rule that runs
+only after the strategy's shadow-profit condition passes.
 
 Keep an `execute: true` marker at the call site (it stops a send happening as a
 side effect of a read path) but do not add an env arm beside it. `armed` and
@@ -89,9 +90,9 @@ Report each gate separately. `agent:execute=true` does not mean "trading": an un
 
 ### Chat-leaked burner keys are still burn-only
 
-If a user pastes a Solana secret key, BTC WIF, seed phrase, or Xverse seed into chat, do **not** import or use it, even when they say it is only a burner. Treat the key as compromised, tell them to generate/import a fresh burner directly on the machine that will sign, and accept only the public address in chat. Long base58 Solana strings are often secret keys; validate by reading the public address only. For Bitcoin inscriptions, prefer a fresh local WIF file that pays commit/reveal fees while inscribing **to** a separate ordinal receive address. Never store an Xverse seed for agentic testing.
+If a user pastes a Solana secret key, BTC WIF, seed phrase, or Xverse seed into chat, do **not** import or use it, even when they say it is only a burner. Treat the key as compromised. Accept only the public address in chat. Tell them to create a fresh burner directly on the signing machine. Long base58 Solana strings are often secret keys; validate by reading the public address only. For Bitcoin inscriptions, prefer a fresh local WIF file that pays commit/reveal fees while inscribing **to** a separate ordinal receive address. Never store an Xverse seed for agentic testing.
 
-Creator/operator urgency is not an exception. If DEMI says "use it for now", "save it locally", or "we already did it for EVM", keep the key-ingress invariant and make the safe local path fast: create the owner-only key directory, create empty `0600` files, and provide/run a prompt-only local installer (`read -s`, no echo, no logs) for the user to paste on the signing machine. After install, the agent may report file mode/size, derive public addresses, and check balances/readiness; never print or copy the raw secret.
+Creator/operator urgency is not an exception. If DEMI says "use it for now", "save it locally", or "we already did it for EVM", keep the key-ingress invariant and make the safe local path fast: create the owner-only key directory, create empty `0600` files, and run a prompt-only local installer (`read -s`, no echo, no logs) on the signing machine against those files. After install, the agent may report file mode/size, derive public addresses, and check balances/readiness; never print or copy the raw secret.
 
 Detailed response pattern: `references/chat-leaked-key-ingestion.md`.
 

package/dist/assets/skills/trade-loop-circuit-breaker/SKILL.md

@@ -26,7 +26,7 @@ Any runaway loop or unverified execution path is existential when it can move re
 - **Spend/exposure cap:** respect the daily loss limit; never code around a halt. A halt is a signal, not an obstacle.
 - **Backoff + jitter** on API timeouts — cascading timeouts are a known cost/failure path.
 - **Kill-switch check** before resume: verify why it halted before clearing it. Reset ≠ diagnosis.
-- **Signer separation:** automatic execution may use only a separate capped hot wallet/session key/smart wallet. Never DEMI's main seed/private key.
+- **Signer separation:** automatic execution may use only a separate capped hot wallet/session key/smart wallet. Never use DEMI's main seed/private key.
 - **Two-step deploy boundary:** shipping executor code and securely installing a dedicated signer are not the same as enabling broadcasts. A signer may be installed root-only in an unfunded, execution-off state after explicit installation approval so its derived address and status path can be verified. Keep `agent:execute` blocked, capital at zero, and asset allowlists empty until a separate explicit DEMI GO enables the capped signer. Never expose or print the key during either stage.
 - **Policy proof:** after every deploy, pull the live policy and state `execution.enabled`, `backendSigner`, `liveExecute`, and whether `agent:execute` is blocked before claiming auto-exec status.