faramesh dev

faramesh dev is the no-infrastructure mode of the daemon. It compiles your governance.fms exactly like faramesh apply does, then runs the daemon against in-process stubs for every provider you haven't declared. You get the full policy engine without Vault, SPIRE, KMS, or a SIEM endpoint.

This is the command you'll use 90% of the time while writing policy or building an agent.

Usage

faramesh dev [--dir DIR]

When to use it

• Run your agent end-to-end while you write the policy.
• Reproduce a deny or defer locally before pushing a policy change.
• Demo Faramesh on a laptop without provisioning anything.
• Run integration tests in CI without a Vault container.

When you're ready for persistent WAL, OS-tier sandbox, and real providers, switch to faramesh apply. Nothing about your agent code or your policy rules changes: only the provider declarations.

What happens when you run it

1. governance.fms is compiled the same way apply compiles it (deterministic AST → .faramesh/).
2. The daemon goes through STARTING → INITIALIZING → READY and opens its Unix socket.
3. For every provider you didn't declare, an in-process stub takes its place.
4. The WAL is in-memory; nothing persists past daemon shutdown.

Every DPR emitted during a dev run is tagged so it's obvious in the chain that stubs were in use. A dev WAL cannot be confused with a production audit trail: faramesh audit verify flags the dev tag explicitly.

What the stubs provide

faramesh dev starts in-process stubs for every provider type. Each is realistic enough to exercise the full pipeline:

Secrets stub: returns a STUB-<id> placeholder secret with the TTL declared in policy. The SDK shim sees a real, scoped, time-bounded credential. Replace with a real provider block for production.

Identity stub: generates an ephemeral SPIFFE id under spiffe://dev.local/<host>/<pid>. Your agent gets a real identity string that works with policy conditions and principal.* claims. Replace with identity "spiffe" { ... } for production.

KMS stub: generates an ephemeral Ed25519 keypair per session and signs DPR records. The audit chain is cryptographically intact and verifiable for the lifetime of the run. Replace with provider "kms" { ... } for production.

WAL: in-memory only. DPR records exist only for the lifetime of the dev session. For persistent audit, use faramesh apply.

Audit sink: dPRs are pretty-printed to stderr instead of shipped to Splunk/Datadog/S3.

Cost provider: uses Faramesh's bundled pricing table for the major model APIs and a flat per-call cost for non-LLM tools.

None of these stubs make network calls. faramesh dev works on an airplane.

Stubs that replace external services

You can mix real providers with stubs. Declare provider "vault" { ... } in governance.fms and Vault runs as a real subprocess while everything else falls back to stubs. This is how most teams iterate: real Vault, stub everything else.

Output

$ faramesh dev
✓ governance.fms valid
✓ governance.fms compiled
✓ in-process providers stubbed: vault (dev server), spiffe (ephemeral CA), kms (ephemeral RSA)
✓ WAL: in-memory
✓ enforcement: application-tier only (OS enforcement not active in dev mode)
→ Unix socket: /Users/you/.faramesh/runtime/faramesh.sock
→ status:    faramesh status
→ approvals: faramesh approvals list
→ start agent: ./.faramesh/bin/agent -- python your_agent.py

The daemon stays in the foreground until you hit Ctrl-C. To run it in the background, use your shell's & or run it under a process supervisor.

Switching to full enforcement

When you're ready for production:

faramesh apply

apply refuses to launch with stubbed KMS or identity in runtime { mode = "enforce" }. Either declare real providers, or run in mode = "audit" while you finish provisioning. See From dev to production for the full migration.

Platform support

faramesh dev itself works on all three operating systems. The OS-tier sandbox is not active in dev mode (it's intentionally application-tier only). Turn on runtime { os_tier = true } and use faramesh apply when you want it.

Common issues

→ More: Troubleshooting.

What's next

• Quickstart: the full five-step walkthrough.
• faramesh apply: production path with real providers.
• Providers: declare Vault, AWS, GCP, Azure, SPIFFE.
• Workflows: first apply, change, monitor.