@openrig/cli 0.1.5 → 0.1.7

package/daemon/specs/agents/apps/vault-specialist/skills/vault-user/SKILL.md

@@ -0,0 +1,64 @@
+# Vault User
+
+You have access to a HashiCorp Vault instance managed by this rig's environment.
+
+## Connection
+
+- **Address:** `http://127.0.0.1:8200`
+- **Token:** `openrig-dev-token`
+- **Auth header:** `X-Vault-Token: openrig-dev-token`
+
+Always set the token before making API calls. For curl, use `-H "X-Vault-Token: openrig-dev-token"`.
+
+## Health Check
+
+```bash
+curl -s http://127.0.0.1:8200/v1/sys/health | jq .
+```
+
+A healthy response has `"initialized": true` and `"sealed": false`.
+
+## Secret Operations
+
+### Write a secret
+
+```bash
+curl -s -X POST http://127.0.0.1:8200/v1/secret/data/<path> \
+  -H "X-Vault-Token: openrig-dev-token" \
+  -d '{"data": {"key": "value"}}' | jq .
+```
+
+### Read a secret
+
+```bash
+curl -s http://127.0.0.1:8200/v1/secret/data/<path> \
+  -H "X-Vault-Token: openrig-dev-token" | jq .
+```
+
+The secret value is in `.data.data`.
+
+### List secrets
+
+```bash
+curl -s -X LIST http://127.0.0.1:8200/v1/secret/metadata/ \
+  -H "X-Vault-Token: openrig-dev-token" | jq .
+```
+
+List a subdirectory by appending the path: `.../secret/metadata/<prefix>/`.
+
+### Delete a secret
+
+```bash
+curl -s -X DELETE http://127.0.0.1:8200/v1/secret/data/<path> \
+  -H "X-Vault-Token: openrig-dev-token"
+```
+
+## Explaining Secrets
+
+When asked to explain the current secret structure, list all paths and summarize what each contains. Use the list endpoint recursively if needed.
+
+## Important Notes
+
+- This is Vault dev mode — all data is in-memory and lost on restart
+- The KV secrets engine is mounted at `secret/` by default in dev mode
+- Use the `rig env status` command to verify Vault health through OpenRig before direct probing

package/daemon/specs/agents/apps/vault-specialist/startup/context.md

@@ -0,0 +1,46 @@
+# Startup Context: Vault Managed App
+
+## Environment
+
+This rig runs HashiCorp Vault in dev mode as a managed environment service. Vault boots before you launch — by the time you receive this context, Vault should already be healthy.
+
+## Access
+
+- **Address:** `http://127.0.0.1:8200`
+- **Dev root token:** `openrig-dev-token`
+- **UI:** `http://127.0.0.1:8200/ui`
+- **API:** `http://127.0.0.1:8200/v1`
+
+## Ground Yourself First
+
+Before making topology or registration claims, ground yourself with OpenRig identity:
+
+```bash
+rig whoami --json
+```
+
+Trust the startup identity context OpenRig gives you. Do not claim that the rig is unlaunched, unattached, or unregistered unless `rig whoami --json` or another direct OpenRig command proves it.
+
+## Checking Status
+
+Use OpenRig env surfaces first:
+
+```bash
+rig env status <rig-name>
+```
+
+For direct Vault health checks:
+
+```bash
+curl -s http://127.0.0.1:8200/v1/sys/health | jq .
+```
+
+Or via the Vault CLI if available:
+
+```bash
+vault status -address=http://127.0.0.1:8200
+```
+
+## Your Role
+
+You are the Vault specialist. Other agents in larger topologies may delegate Vault-domain work to you. When they do, use your domain knowledge to perform the requested operations and report results clearly.

package/daemon/specs/agents/development/implementer/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, openrig-user, development-team, test-driven-development, systematic-debugging, verification-before-completion, writing-plans, executing-plans]
+      skills: [using-superpowers, openrig-user, development-team, test-driven-development, mental-model-ha, systematic-debugging, verification-before-completion, writing-plans, executing-plans]
       guidance: []
       subagents: []
       hooks: []

package/daemon/specs/agents/development/implementer/guidance/role.md

@@ -9,6 +9,7 @@ Load these packaged skills now before editing:
 - `openrig-user`
 - `development-team`
 - `test-driven-development`
+- `mental-model-ha`
 - `systematic-debugging`
 - `writing-plans`
 - `executing-plans`

package/daemon/specs/agents/orchestration/orchestrator/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, openrig-user, orchestration-team, systematic-debugging, verification-before-completion, writing-plans, executing-plans, brainstorming]
+      skills: [using-superpowers, openrig-user, orchestration-team, mental-model-ha, systematic-debugging, verification-before-completion, writing-plans, executing-plans, brainstorming]
       guidance: []
       subagents: []
       hooks: []

package/daemon/specs/agents/orchestration/orchestrator/guidance/role.md

@@ -8,6 +8,7 @@ Load these packaged skills now before doing substantive work:
 - `using-superpowers`
 - `openrig-user`
 - `orchestration-team`
+- `mental-model-ha`
 - `systematic-debugging`
 - `brainstorming`
 - `writing-plans`

package/daemon/specs/agents/shared/agent.yaml

@@ -20,6 +20,8 @@ resources:
       path: skills/process/using-superpowers
     - id: openrig-user
       path: skills/core/openrig-user
+    - id: mental-model-ha
+      path: skills/mental-model-ha
     - id: systematic-debugging
       path: skills/process/systematic-debugging
     - id: test-driven-development

package/daemon/specs/agents/shared/skills/core/openrig-user/SKILL.md

@@ -16,6 +16,40 @@ Most work in OpenRig reduces to this loop:
 - read context: `rig transcript ...`, `rig ask ...`, `rig chatroom history ...`
 - act: `rig send`, `rig capture`, `rig broadcast`, lifecycle commands
 
+## Agent-Managed Apps
+
+An agent-managed app is a deployable OpenRig unit made of:
+- the software or service
+- one specialist agent dedicated to that software
+
+Treat the specialist as the domain delegate for that app.
+The current canonical example is:
+- rig: `secrets-manager`
+- pod: `vault`
+- member: `specialist`
+- logical ID: `vault.specialist`
+- session: `vault-specialist@secrets-manager`
+
+Typical operator loop:
+
+```bash
+rig up secrets-manager --cwd /path/to/project
+rig ps --nodes --json
+rig send vault-specialist@secrets-manager "Check Vault health and report back." --verify
+rig env status secrets-manager
+rig env logs secrets-manager
+```
+
+Cross-rig communication is valid when the target session resolves uniquely.
+Example:
+
+```bash
+rig send vault-specialist@secrets-manager "Read secret/data/dogfood and report the value." --verify
+```
+
+Use the specialist instead of teaching every peer the same app-specific toolchain.
+For Vault, ask `vault.specialist` to do secrets-domain work rather than improvising curl or Vault CLI usage in unrelated agents.
+
 ## Identity and Recovery
 
 Start here after launch, compaction, or confusion:
@@ -63,6 +97,9 @@ rig daemon status
 rig config
 rig preflight
 rig doctor
+rig env status <rig>
+rig env logs <rig>
+rig env down <rig>
 ```
 
 ## Transcript and Communication
@@ -161,6 +198,7 @@ This is an evidence/context command. It is not a hidden second-LLM call.
 rig up <source>
 rig up <source> --plan
 rig up <source> --yes
+rig up <source> --cwd /path/to/project
 rig up <source> --json
 ```
 
@@ -176,9 +214,9 @@ Bare names are special:
 
 Current behavior notes:
 - `--target <root>` is only for `.rigbundle` / package installation. It does not change agent cwd.
+- `rig up --cwd` is shipped. `rig up --cwd <path>` sends a per-run cwd override for all members in that launch.
 - `local:` `agent_ref` values resolve relative to the rig spec directory, not your shell cwd.
 - if you copy a built-in spec elsewhere, keep its `agents/` tree beside the YAML or rewrite those refs to `path:/absolute/path`
-- there is no shipped `rig up --cwd` override yet
 
 Legacy/spec-specific surfaces still ship too:
 
@@ -199,6 +237,20 @@ rig down <rigId> --json
 
 If `--snapshot` succeeds, human output includes the restore hint.
 
+### Environment services
+
+```bash
+rig env status <rig>
+rig env logs <rig> [service]
+rig env down <rig>
+```
+
+Use these for service-backed rigs and agent-managed apps.
+For `secrets-manager`, these are the fastest CLI surfaces for:
+- confirming whether Vault is healthy
+- reading Vault container logs
+- stopping the Vault env without tearing down the specialist session first
+
 ### Release management without killing live claimed sessions
 
 ```bash
@@ -463,6 +515,5 @@ Design assumptions that hold in the shipped CLI:
 
 Do not assume these exist unless the shipped help starts listing them:
 - `rig claim`
-- `rig env`
 - `rig blame`
 - `rig replay`