README.md / PURPOSE.md document endpoints, sockets, and service myfs lifecycle scripts that don't exist in the codebase #41

Open
opened 2026-05-12 08:06:51 +00:00 by rawan · 0 comments
Member

Summary

The top-level docs describe a Hero-style Unix-socket service with a service myfs Nu-shell lifecycle, a /health endpoint, and a /.well-known/heroservice.json discovery endpoint. None of that exists in the code on development. A new user following the README cannot build, run, or health-check the server as documented.

Discrepancies

1. Lifecycle / build instructions don't exist. README.md and PURPOSE.md say:

All lifecycle management uses Nu shell service scripts only: service myfs start --update --reset / service myfs stop / service myfs status
No Makefiles or bash scripts — Nu shell scripts are the only supported way to build and manage this service.
Building from Source: service myfs install / service myfs install --update --release

There are no *.nu files anywhere in the repo, and no service wrapper. The real build is plain cargo build --release --workspace; the real way to run the server is myfs-hub serve --config-path ./server.toml. (Note the CI workflows simultaneously rely on a Makefile + scripts/build_lib.sh — see the separate CI issue — which also don't exist, contradicting the "no Makefiles or bash scripts" claim.)

2. GET /health does not exist. README "Key endpoints" and PURPOSE.md "Key APIs" both list GET /health. In myfs-hub/src/server/mod.rs the only health route is GET /api/v1handlers::health_check_handler. There is no /health route.

3. GET /.well-known/heroservice.json does not exist. Listed in README and PURPOSE.md; no such route is registered in mod.rs (grep -rn well-known --include='*.rs' → nothing).

4. The server does not listen on a Unix socket. README/PURPOSE.md: "The server (myfs-hub) listens on a Unix socket at ~/hero/var/sockets/myfs/rpc.sock". Actual code: tokio::net::TcpListener::bind(format!("{}:{}", config.host, config.port)). No UnixListener, no rpc.sock.

Likely cause

The README/PURPOSE.md appear to have been written against the target architecture in #35 ("WIP: microservice rearchitecture" — myfs-server daemon over UDS, hero_proc lifecycle, /health, etc.), which is not yet merged.

Suggested fix

Either:

  • Land #35 (which introduces the UDS daemon, /health, service/hero_proc lifecycle) so the docs become true; or
  • Until then, revert README.md / PURPOSE.md to describe the current reality: workspace + cargo build, myfs-hub serve --config-path, TCP host:port, health at GET /api/v1, and remove the service myfs / rpc.sock / /health / /.well-known/heroservice.json sections.
## Summary The top-level docs describe a Hero-style Unix-socket service with a `service myfs` Nu-shell lifecycle, a `/health` endpoint, and a `/.well-known/heroservice.json` discovery endpoint. None of that exists in the code on `development`. A new user following the README cannot build, run, or health-check the server as documented. ## Discrepancies **1. Lifecycle / build instructions don't exist.** `README.md` and `PURPOSE.md` say: > All lifecycle management uses Nu shell service scripts only: `service myfs start --update --reset` / `service myfs stop` / `service myfs status` > No Makefiles or bash scripts — Nu shell scripts are the only supported way to build and manage this service. > Building from Source: `service myfs install` / `service myfs install --update --release` There are **no `*.nu` files** anywhere in the repo, and no `service` wrapper. The real build is plain `cargo build --release --workspace`; the real way to run the server is `myfs-hub serve --config-path ./server.toml`. (Note the CI workflows simultaneously rely on a `Makefile` + `scripts/build_lib.sh` — see the separate CI issue — which also don't exist, contradicting the "no Makefiles or bash scripts" claim.) **2. `GET /health` does not exist.** README "Key endpoints" and `PURPOSE.md` "Key APIs" both list `GET /health`. In `myfs-hub/src/server/mod.rs` the only health route is `GET /api/v1` → `handlers::health_check_handler`. There is no `/health` route. **3. `GET /.well-known/heroservice.json` does not exist.** Listed in README and `PURPOSE.md`; no such route is registered in `mod.rs` (`grep -rn well-known --include='*.rs'` → nothing). **4. The server does not listen on a Unix socket.** README/`PURPOSE.md`: "The server (`myfs-hub`) listens on a Unix socket at `~/hero/var/sockets/myfs/rpc.sock`". Actual code: `tokio::net::TcpListener::bind(format!("{}:{}", config.host, config.port))`. No `UnixListener`, no `rpc.sock`. ## Likely cause The README/`PURPOSE.md` appear to have been written against the target architecture in #35 ("WIP: microservice rearchitecture" — `myfs-server` daemon over UDS, `hero_proc` lifecycle, `/health`, etc.), which is not yet merged. ## Suggested fix Either: - Land #35 (which introduces the UDS daemon, `/health`, `service`/`hero_proc` lifecycle) so the docs become true; or - Until then, revert `README.md` / `PURPOSE.md` to describe the **current** reality: workspace + `cargo build`, `myfs-hub serve --config-path`, TCP `host:port`, health at `GET /api/v1`, and remove the `service myfs` / `rpc.sock` / `/health` / `/.well-known/heroservice.json` sections.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
geomind_code/my_fs#41
No description provided.