feat: add bounded filesystem projection server

README.md

@@ -5,12 +5,18 @@ Rust building blocks for the Web Interface Protocol (WIP).
 The repository is a resolver-3 virtual Cargo workspace whose packages all live
 under `crates/*`. It provides a transport-independent protocol model, the
 standard framework-independent WIP over HTTPS v1 binding, a Rust
-interface-authoring facade, a request-scoped host runtime, and a private
-public-API conformance consumer. The repository root is not itself a package.
+interface-authoring facade, a request-scoped host runtime, a bounded Linux
+filesystem projection server, and a private public-API conformance consumer. The
+repository root is not itself a package.
 
 ## Crate graph and responsibilities
 
 ```text
+wip-fs-server (request-time filesystem projection and loopback listener)
+├── wip-https                 standard routes/codecs/envelopes/batching
+├── wip-host                  request-scoped publication and dispatch
+└── wip-interface             macro-generated filesystem capabilities
+
 wip-public-api-example (workspace-only executable, integration tests, doctest)
 ├── wip-protocol              logical declarations, values, calls, and validation
 ├── wip-https                 standard HTTPS v1 routes, JSON codecs, envelopes, and batching
@@ -29,7 +35,8 @@ wip-public-api-example (workspace-only executable, integration tests, doctest)
 | `wip-https` | Standard HTTPS v1 endpoint/route derivation, UTF-8 JSON codecs, direct success bodies, error/status classification, and retrieval batches. | HTTP I/O, TLS termination, authentication schemes, server frameworks, filesystem projection, or client presentation/cache policy. |
 | `wip-interface` | The public `WipType`/`interface` authoring API, Rust-to-protocol codecs, generated descriptors, and typed implementation dispatch. | Object publication, backend lifetime, or transport policy. |
 | `wip-interface-macros` | Procedural-macro expansion used by `wip-interface`. It is not an application dependency. | A supported direct user API. |
-| `wip-host` | Opaque interface registration, explicit object membership, validator checks, and interface-qualified dispatch against one host-owned instance. | Backend atomicity, global object lookup, or network serving. |
+| `wip-host` | Opaque interface registration, explicit object membership, validator checks, interface-qualified dispatch against one host-owned instance, and descriptor-guided argument decoding inside that same resolution boundary. | Backend atomicity, global object lookup, or network serving. |
+| `wip-fs-server` | Linux directory-handle-confined request-time projection, bounded BFS trees and file operations, standard `wip-https` dispatch/batch handling, and a loopback HTTP binary for TLS-proxy or explicit development use. | A new wire profile, implicit symlink following, non-loopback cleartext, authentication policy, or filesystem-wide preregistration. |
 | `wip-public-api-example` | An independently compiled consumer of the protocol, authoring, and host public crates. Its DTOs and traits are application-owned; its implementation and backend handle remain host-private. | Reusable library API or a production server. |
 
 The boundary is intentional: protocol types describe what can cross a
@@ -238,6 +245,17 @@ rolled back. Without that proof, post-invocation failures remain
 comparison and backend commit atomic and return a validator describing the state
 that becomes committed.
 
+## Filesystem projection server
+
+[`crates/wip-fs-server`](crates/wip-fs-server) contains the practical server
+binary and its full security model, configuration, curl walkthrough, and
+resource/failure semantics. It resolves every object from current filesystem
+state, uses pinned directory-relative handles without following symlinks, omits
+non-UTF-8 backend names, performs bounded breadth-first tree discovery, and
+publishes validator-protected replacement only in explicit read-write mode.
+The built-in cleartext listener is loopback-only: production HTTPS is explicitly
+delegated to a reverse proxy, while local plain HTTP requires an opt-in flag.
+
 ## Validation
 
 Enter the dev shell and run the acceptance commands exactly: