hero_foundry source has diverged from deployed binary (--allow-dir / WebDAV files API missing) #25

New issue

Closed

opened 2026-05-03 18:10:06 +00:00 by zaelgohary · 1 comment

zaelgohary commented

2026-05-03 18:10:06 +00:00

Member

Summary

The hero_foundry_server binary running on herodev is incompatible with the source at lhumina_code/hero_foundry on the development branch. They appear to be two different forks/versions:

	Running binary (Apr 29 build, e.g. rawan)	Current `development` source build (May 3)
CLI flags	`--allow-dir`, `--webdav-storage`, `--read-write`, `--bind`, `--default-repo`, `--repo`	`--path`, `--sync-listen` only
Tagline	"version control and code repository system" with WebDAV file API	"version control and code repository system" without WebDAV
Has `/api/files/<context>/` route	yes	no
Auto-creates context dir	yes (per `state.rs:284` in cached crate, `hero_foundry-41aeeb1ffd98771c/e786a43`)	n/a (handler doesn't exist)

How this surfaced

A QA sweep against the deployed instance reported 4 × 404s on:

GET /hero_foundry/rpc/api/files/geomind/
GET /hero_foundry/ui/static/js/connection-status.js
GET /hero_foundry/ui/hero-bootstrap-bridge.css

When I rebuilt lhumina_code/hero_foundry to pick up auto-create logic an investigation agent had identified (in a different cached source), the new binary lost the entire WebDAV /api/files surface and rejected the existing service-action's --allow-dir/--webdav-storage arguments. The previously-working binary on rawan's account (Apr 29) is still serving the old API.

What this means

Whichever fork the team intends as canonical is unclear
Anyone who rebuilds lhumina_code/hero_foundry from development will lose the WebDAV files API
Consumers (hero_archipelagos/.../office/src/service.rs:64's OfficeEndpoint::file_url()) hard-code /hero_foundry/rpc/api/files/{ctx}/{name} — they'll start 404'ing as soon as the new binary is deployed

What's needed

A decision: which version is the production target? Then either:

Bring the missing WebDAV/files API into lhumina_code/hero_foundry's development branch, or
Migrate consumers to whatever the new model exposes (different RPC? OpenRPC method instead of REST?)

Filing as a discovery, not a fix request — needs ownership input.

## Summary The `hero_foundry_server` binary running on herodev is **incompatible** with the source at `lhumina_code/hero_foundry` on the development branch. They appear to be two different forks/versions: | | Running binary (Apr 29 build, e.g. rawan) | Current `development` source build (May 3) | |---|---|---| | CLI flags | `--allow-dir`, `--webdav-storage`, `--read-write`, `--bind`, `--default-repo`, `--repo` | `--path`, `--sync-listen` only | | Tagline | "version control and code repository system" with WebDAV file API | "version control and code repository system" without WebDAV | | Has `/api/files/<context>/` route | **yes** | **no** | | Auto-creates context dir | yes (per `state.rs:284` in cached crate, `hero_foundry-41aeeb1ffd98771c/e786a43`) | n/a (handler doesn't exist) | ## How this surfaced A QA sweep against the deployed instance reported 4 × 404s on: - `GET /hero_foundry/rpc/api/files/geomind/` - `GET /hero_foundry/ui/static/js/connection-status.js` - `GET /hero_foundry/ui/hero-bootstrap-bridge.css` When I rebuilt `lhumina_code/hero_foundry` to pick up auto-create logic an investigation agent had identified (in a different cached source), the new binary lost the entire WebDAV `/api/files` surface and rejected the existing service-action's `--allow-dir`/`--webdav-storage` arguments. The previously-working binary on rawan's account (Apr 29) is still serving the old API. ## What this means - Whichever fork the team intends as canonical is unclear - Anyone who rebuilds `lhumina_code/hero_foundry` from `development` will lose the WebDAV files API - Consumers (`hero_archipelagos/.../office/src/service.rs:64`'s `OfficeEndpoint::file_url()`) hard-code `/hero_foundry/rpc/api/files/{ctx}/{name}` — they'll start 404'ing as soon as the new binary is deployed ## What's needed A decision: which version is the production target? Then either: - Bring the missing WebDAV/files API into `lhumina_code/hero_foundry`'s development branch, or - Migrate consumers to whatever the new model exposes (different RPC? OpenRPC method instead of REST?) Filing as a discovery, not a fix request — needs ownership input.

zaelgohary self-assigned this

2026-05-03 18:10:07 +00:00

zaelgohary commented

2026-05-03 18:27:25 +00:00

Author

Member

Update: clarified after reading `bfc845b`

Found the divergence point: commit bfc845b feat(foundry)!: rename fossil to foundry, per-repo layout, multi-repo + dashboard UI (May 2, despiegk) is the breaking refactor. It's not a fork divergence at all — it's an intentional, semver-major rewrite:

	Pre-bfc845b (rawan still runs this)	Post-bfc845b (current `development`)
CLI	`--allow-dir`, `--read-write`, `--webdav-storage`, `--repo`, `--bind`, `--default-repo`, `--max-cache`, `--fossil-dir`	single `--foundry-dir` (server always RW)
Storage layout	global webdav root + .fossil files	`<base>/<reponame>/{db.foundry, webdav/, repo.toml}`
`/api/files/*` API	by context (auto-creates)	by registered repo (must be pre-registered)
WebDAV path	`/webdav/...` (single root)	`/webdav/<reponame>/...` (per-repo)
UI env	`HERO_FOUNDRY_REPOS`	`HERO_FOUNDRY_DIR`

So the 404 on /hero_foundry/rpc/api/files/geomind/ was the consumer (hero_archipelagos/.../office/src/service.rs:64 OfficeEndpoint::file_url()) calling the old "context" API surface against the new per-repo server: geomind is a context name, not a registered repo, so the new server correctly 404s.

What this means

The consumer needs to migrate. hero_archipelagos/embed/office/src/service.rs:64 should either (a) ensure geomind is registered as a foundry repo before calling, or (b) switch to whatever the new model intends for ad-hoc file storage. The Office archipelago workflow needs a design call.
rawan's setup is on the old fossil-era code. It works because she's running an Apr 29 build that predates bfc845b. Rebuilding from current development will lose those args — that's by design, not a bug.
There is no fork divergence. I was wrong to file this as one — it's just an unmigrated consumer.

Reframing this issue from "fork divergence" to "hero_archipelagos office consumer needs migration to post-bfc845b foundry API". Closing this and the relevant follow-up should be opened against hero_archipelagos.

## Update: clarified after reading bfc845b Found the divergence point: commit `bfc845b feat(foundry)!: rename fossil to foundry, per-repo layout, multi-repo + dashboard UI` (May 2, despiegk) is the breaking refactor. It's not a fork divergence at all — it's an intentional, semver-major rewrite: | | Pre-bfc845b (rawan still runs this) | Post-bfc845b (current `development`) | |---|---|---| | CLI | `--allow-dir`, `--read-write`, `--webdav-storage`, `--repo`, `--bind`, `--default-repo`, `--max-cache`, `--fossil-dir` | single `--foundry-dir` (server always RW) | | Storage layout | global webdav root + .fossil files | `<base>/<reponame>/{db.foundry, webdav/, repo.toml}` | | `/api/files/*` API | by **context** (auto-creates) | by **registered repo** (must be pre-registered) | | WebDAV path | `/webdav/...` (single root) | `/webdav/<reponame>/...` (per-repo) | | UI env | `HERO_FOUNDRY_REPOS` | `HERO_FOUNDRY_DIR` | So the 404 on `/hero_foundry/rpc/api/files/geomind/` was the consumer (`hero_archipelagos/.../office/src/service.rs:64` `OfficeEndpoint::file_url()`) calling the old "context" API surface against the new per-repo server: `geomind` is a context name, not a registered repo, so the new server correctly 404s. ## What this means 1. **The consumer needs to migrate.** `hero_archipelagos/embed/office/src/service.rs:64` should either (a) ensure `geomind` is registered as a foundry repo before calling, or (b) switch to whatever the new model intends for ad-hoc file storage. The Office archipelago workflow needs a design call. 2. **rawan's setup is on the old fossil-era code.** It works because she's running an Apr 29 build that predates bfc845b. Rebuilding from current `development` will lose those args — that's by design, not a bug. 3. **There is no fork divergence.** I was wrong to file this as one — it's just an unmigrated consumer. Reframing this issue from "fork divergence" to **"hero_archipelagos office consumer needs migration to post-bfc845b foundry API"**. Closing this and the relevant follow-up should be opened against `hero_archipelagos`.

zaelgohary closed this issue

2026-05-03 18:27:25 +00:00