Use website branding in docs

src/pages/getting-started/agent-setup.mdx

@@ -10,25 +10,24 @@ An agent should then:
 
 1. Install or build the `bloom` binary.
 2. Run `bloom init`.
-3. Prefer a mounted filesystem when available.
-4. Fall back to `bloom vfs cat|ls|write` when mounting is blocked.
-5. Inspect `/docs/README.md`, `/status/`, and the top-level tree before taking actions.
-6. Explain what it can do and ask before confirming any transaction.
+3. Mount Bloom at `/bloom` or the configured mount path.
+4. Inspect `/bloom/docs/README.md`, `/bloom/status/`, and the top-level tree before taking actions.
+5. Explain what it can do and ask before confirming any transaction.
 
 ## Rules for agents
 
-- Do not write custom signing or broadcast code unless Bloom cannot satisfy the task.
+- Do not write or use custom signing or broadcast code.
 - Read generated plans before asking the user to approve anything.
 - Treat missing config, disabled broadcasts, and policy failures as safety signals, not obstacles to bypass.
 - Keep live mainnet and L2 sends opt-in.
 
 ## Useful discovery commands
 
 ```sh
-bloom vfs ls /
-bloom vfs cat /docs/README.md
-bloom vfs cat /status/daemon.json
-bloom vfs cat /status/backends/summary.json
-bloom vfs ls /chains
-bloom vfs ls /tools
+ls /bloom/
+cat /bloom/docs/README.md
+cat /bloom/status/daemon.json
+cat /bloom/status/backends/summary.json
+ls /bloom/chains
+ls /bloom/tools
 ```

src/pages/getting-started/quickstart.mdx

@@ -1,6 +1,6 @@
 # Quickstart
 
-This walkthrough uses the CLI fallback. If the mount is available, the same paths work through `/bloom` or your selected mount directory.
+This walkthrough uses the mounted `/bloom` filesystem. Bloom’s command-specific fallbacks exist for constrained environments, but normal shell tools against the mount are the default interface.
 
 ## Prerequisites
 
@@ -14,33 +14,25 @@ cargo build -p bloom --all-features
 cargo run -p bloom -- init
 ```
 
-`bloom init` creates the Bloom home directory, writes the default config, and registers read-ready chain defaults.
-
-## Inspect chain state
-
-```sh
-cargo run -p bloom -- vfs ls /
-cargo run -p bloom -- vfs cat /docs/README.md
-cargo run -p bloom -- vfs cat /chains/ethereum/head/number
-cargo run -p bloom -- vfs cat /prices/spot/eth.usd
-```
+`bloom init` creates the Bloom home directory, writes the default config, and registers read-ready chain defaults. The default mount path is `/bloom`.
 
 ## Mount the filesystem
 
-Create a mount directory and start the daemon:
+Create the mount directory and start the daemon:
 
 ```sh
-mkdir -p "$HOME/bloom"
-cargo run -p bloom -- serve --mount "$HOME/bloom"
+sudo mkdir -p /bloom
+cargo run -p bloom -- serve --mount /bloom
 ```
 
 Then inspect it like any other directory:
 
 ```sh
-ls ~/bloom
-cat ~/bloom/docs/README.md
-ls ~/bloom/chains
-cat ~/bloom/chains/ethereum/head/number
+ls /bloom/
+cat /bloom/docs/README.md
+ls /bloom/chains
+cat /bloom/chains/ethereum/head/number
+cat /bloom/prices/spot/eth.usd
 ```
 
 ## Create a demo wallet
@@ -57,16 +49,15 @@ The key is encrypted in the keystore. The filesystem exposes address and public
 With Anvil running on `127.0.0.1:8545`:
 
 ```sh
-bloom vfs write \
-  /wallets/alice/chains/anvil/outbox/new.tx \
-  --data 'send 0.01 eth to 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 on anvil'
+echo 'send 0.01 eth to 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 on anvil' \
+  > /bloom/wallets/alice/chains/anvil/outbox/new.tx
 ```
 
 Review the pending entry:
 
 ```sh
-bloom vfs ls /wallets/alice/chains/anvil/outbox/pending
-bloom vfs cat /wallets/alice/chains/anvil/outbox/pending/<id>/plan.md
+ls /bloom/wallets/alice/chains/anvil/outbox/pending
+cat /bloom/wallets/alice/chains/anvil/outbox/pending/<id>/plan.md
 ```
 
 Confirm only after reading the plan.

src/pages/index.mdx

@@ -1,4 +1,36 @@
-# Bloom Docs
+---
+title: /bloom | Documentation
+description: Documentation for Bloom, the agentic Ethereum wallet mounted as a virtual filesystem.
+---
+
+<div className="bloom-wordmark" aria-label="/bloom">
+  <span className="bloom-wordmark-slash">/</span>bloom
+</div>
+
+<style>{`
+  @import url('https://fonts.googleapis.com/css2?family=Instrument+Serif:ital@0;1&display=swap');
+
+  .bloom-wordmark {
+    margin: -3rem 0 -1.5rem;
+    font-family: "Instrument Serif", "Times New Roman", serif;
+    font-size: clamp(5rem, 16vw, 15rem);
+    font-style: italic;
+    font-weight: 400;
+    letter-spacing: -0.04em !important;
+    line-height: 0.85;
+    color: #141310;
+    text-shadow:
+      0 0 32px #f1ece1,
+      0 0 16px #f1ece1,
+      0 0 8px #f1ece1;
+  }
+
+  .bloom-wordmark-slash {
+    color: #8a2a3a;
+    font-style: normal;
+    letter-spacing: -0.04em !important;
+  }
+`}</style>
 
 Bloom is an **agentic Ethereum wallet mounted as a virtual filesystem**.
 
@@ -29,4 +61,4 @@ For the shortest onboarding path, tell your agent:
 Read https://bloom.directory/SKILL.md and set up Bloom.
 ```
 
-The agent should then mount Bloom or use the `bloom vfs` fallback, inspect the in-tree docs, explain the capabilities it found, and use Bloom instead of writing bespoke Web3 SDK code.
+The agent should then mount Bloom at `/bloom`, inspect the in-tree docs, explain the capabilities it found, and use Bloom instead of writing bespoke Web3 SDK code.

src/pages/introduction/benefits.mdx

@@ -12,10 +12,10 @@ Bloom is designed around the operating model agents already understand: files.
 
 ## For agents
 
-- **No custom Web3 loop.** Agents can use `ls`, `cat`, and writes rather than assembling RPC calls and signing flows from scratch.
+- **No custom Web3 loop.** Agents can use `ls`, `cat`, and file writes under `/bloom` rather than assembling RPC calls and signing flows from scratch.
 - **Discoverable capabilities.** The mounted tree exposes docs, status, supported chains, wallets, tools, and control files in one place.
 - **Plans before actions.** Every write-oriented workflow is staged into readable artifacts such as `plan.md`, `intent.json`, and `policy_check.json`.
-- **Lower integration cost.** The same paths work through the mounted filesystem and through the `bloom vfs cat|ls|write` fallback.
+- **Lower integration cost.** The same paths work through ordinary shell tools, scripts, and file-aware agent runtimes once `/bloom` is mounted.
 
 ## For developers and integrators
 

src/pages/introduction/core-concepts.mdx

@@ -6,16 +6,12 @@ Bloom exposes blockchain and wallet operations as paths. Reading a file performs
 
 ## Mounted directory
 
-The preferred interface is a mounted directory such as `~/bloom`, `/bloom`, or `/Volumes/bloom`. The mount lets any agent or shell tool interact with Bloom using ordinary filesystem operations.
-
-## `bloom vfs` fallback
-
-When mounting is unavailable, the CLI exposes the same paths:
+The preferred interface is the mounted `/bloom` directory. The mount lets any agent or shell tool interact with Bloom using ordinary filesystem operations.
 
 ```sh
-bloom vfs ls /
-bloom vfs cat /docs/README.md
-bloom vfs write /wallets/new --data alice
+ls /bloom/
+cat /bloom/docs/README.md
+echo alice > /bloom/wallets/new
 ```
 
 ## Stage-confirm flow
@@ -28,4 +24,4 @@ Policies live per wallet and enforce caps, recipient rules, contract-call gates,
 
 ## Audit log
 
-Bloom appends writes and side-effecting reads to a hash-chained audit log under the Bloom home directory. The current head is exposed through `status/audit/head`.
+Bloom appends writes and side-effecting reads to a hash-chained audit log under the Bloom home directory. The current head is exposed through `/bloom/status/audit/head`.

src/pages/petals/overview.mdx

@@ -1,44 +1,35 @@
 # Petals
 
-A petal is a Bloom application module compiled to WebAssembly. A deployed petal
-is content-addressed by its wasm hash and bound to a human-readable path such as
-`/bloom/core/fungible` or `/bloom/dex/pool`.
+## ⚠️ WARNING - EARLY / UNFINISHED
 
-Petals are invoked through programmable transaction blocks, or PTBs. A PTB can
-call multiple petal functions, pass outputs from one command into later
-commands, transfer objects, split and merge coins, and commit or revert
-atomically.
+Petals are not ready for prime-time use. They are in active development, the APIs and runtime model may change, and the current documentation is primarily for Bloom developers rather than end users.
+
+Today, Petals should be understood as the path toward safe extensions to WalletFS: small, reviewable modules that can add capabilities behind Bloom’s policy, planning, and filesystem boundaries without asking agents to write custom signing or broadcast code.
+
+For an early example of a custom petal, see [`bloombook`](https://github.com/bloom-directory/bloombook). It is useful as a developer reference for how Petals can package new filesystem-backed capabilities, but it should be treated as experimental alongside the Petals runtime itself.
+
+A petal is a Bloom application module compiled to WebAssembly. A deployed petal is content-addressed by its wasm hash and bound to a human-readable path such as `/bloom/core/fungible` or `/bloom/dex/pool`.
+
+Petals are invoked through programmable transaction blocks, or PTBs. A PTB can call multiple petal functions, pass outputs from one command into later commands, transfer objects, split and merge coins, and commit or revert atomically.
 
 ## What Petal Authors Write
 
-Petal authors should start in their own Rust project, not inside the Bloom
-monorepo. Today, depend on the Bloom repo by git URL, build your crate to wasm,
-and use the Bloom CLI to deploy the resulting `.wasm`.
+Petal authors should start in their own Rust project, not inside the Bloom monorepo. Today, depend on the Bloom repo by git URL, build your crate to wasm, and use the Bloom CLI to deploy the resulting `.wasm`.
 
 Petal authors write Rust crates that depend on the Bloom runtime and macros:
 
-- `bloom-resource`: guest-side runtime types such as `Resource<T>`, `Coin<T>`,
-  `Capability<T>`, `Signer`, `UID`, `BloomType`, and host wrappers.
-- `bloom-resource-macros`: `#[bloom::petal]`, `#[bloom::object]`,
-  `#[bloom::capability]`, `#[derive(BloomType)]`, and
-  `#[bloom::invariant]`.
+- `bloom-resource`: guest-side runtime types such as `Resource<T>`, `Coin<T>`, `Capability<T>`, `Signer`, `UID`, `BloomType`, and host wrappers.
+- `bloom-resource-macros`: `#[bloom::petal]`, `#[bloom::object]`, `#[bloom::capability]`, `#[derive(BloomType)]`, and `#[bloom::invariant]`.
 - `bloom-objects`: object IDs, owners, access modes, and type tags.
 
-Every public function inside a `#[bloom::petal]` module becomes a callable
-entry point. The macro emits:
+Every public function inside a `#[bloom::petal]` module becomes a callable entry point. The macro emits:
 
 - one wasm export named `__petal_<function>`;
 - a `bloom_petal_manifest_v0` custom section;
 - an accessor for the encoded manifest bytes, used heavily by tests.
 
 ## What The Chain Uses
 
-At deploy time, Bloom checks that the wasm contains a manifest section, that the
-manifest path matches the deploy path, and that every manifest function has a
-matching wasm export.
+At deploy time, Bloom checks that the wasm contains a manifest section, that the manifest path matches the deploy path, and that every manifest function has a matching wasm export.
 
-At call time, the PTB validator loads the manifest, checks argument kinds and
-object access modes, then the executor runs the wasm under a deterministic
-chain VM. Constants, returns, and object payloads use Bloom's canonical,
-manifest-driven value codec; old ad hoc petal payload layouts are not the
-supported authoring model.
+At call time, the PTB validator loads the manifest, checks argument kinds and object access modes, then the executor runs the wasm under a deterministic chain VM. Constants, returns, and object payloads use Bloom's canonical, manifest-driven value codec; old ad hoc petal payload layouts are not the supported authoring model.