HydraIssues

What happened

The rebuilt nimsforest.com /signup page promises "We reply personally, within two working days". The first real lead it took was lost.

It was logged and dropped on Wind as lead.captured. The drop succeeded, but Wind is NATS Core: ephemeral, delivered only to whoever is subscribed at that instant. Nothing in any repo subscribes to lead.captured, no active subscription matched it, and no JetStream stream captured it (the streams are river.>, tap.>, decision.>, efficiency.>, humus.>). The leaf went to zero consumers. The only surviving copy was a container log line, which any replant would have erased.

That lead is preserved at /opt/nimsforestecommerce/leads/pre-taproot-leads.log on land-shared-one.

Already fixed (nimsforestecommerce v0.10.1, deployed)

Leads now publish on tap.ecommerce.leads.captured. The taproot convention means the event is captured by the TAPROOT JetStream, so it is durable the moment it is published, survives having no consumer, and can be replayed to a handler added later. Verified live: a submission produces [Wind] Dropped leaf: subject=tap.ecommerce.leads.captured and the TAPROOT message count increases.

This deliberately fixes durability before adding a subscriber. A subscriber alone would not have helped: the next lead arriving while it was down would have vanished the same way.

Still missing: nothing acts on a lead

No consumer exists, so a submission still results in nobody being told. The promise on the page is not yet backed by anything.

Proposed shape, smallest first:

1. Notify. nimsforestmaddy already runs on land-shared-one, so a lead can become an email to cederik@nimsforest.com. Honours the promise immediately.
2. A nim that owns leads. Declared in nimregistry (data/nims/<name>/intent.md frontmatter subjects), consuming from TAPROOT. Subjects must come from nimregistry, not forest.yaml, which is the multi-node-correct source of truth.
3. Configurable from the admin dashboard. Let an operator wire a subscriber to a leaf from the nimsforest admin UI for the nimsforest organization. nimsforestadmin (v0.66.0) runs on the org land at 46.225.164.179. Blocker: nimregistry's API is read-only today (GET /api/nims, GET /api/nims/{name}/prompt, GET /api/nims/). Write endpoints are needed before any dashboard can configure a subscription.

Constraint worth recording

nimsforestecommerce runs on the central shared land (land-shared-one, role shared), not on the nimsforest org land. A subscriber configured on the org land cannot receive this leaf as things stand: org forests reach the hub over a NATS leaf node whose organisationland account may publish only hub.tap.landregistry.* and subscribe only to land.status.>, and forwarding is org to hub for tap.> subjects. There is no hub to org path for this event.

So either the consumer lives on the shared land beside the publisher, or the marketing site moves onto the nimsforest org land so leads stay inside that forest. The second is the better long-term story (the org owns its leads) but it is a relocation, not a small change.

Separate bug found while verifying: tap events are stored twice

Each submission writes two messages to TAPROOT. Measured directly: one submission moved the stream from 14 to 16 messages.

Cause: TAPROOT is configured with subjects tap.>, so JetStream captures the service's core publish directly. The PersistenceTree also catches tap.> on Wind and calls js.Publish(leaf.Subject, payload), landing a second copy on the same subject (nimsforest2/internal/trees/persistencetree.go:127-136).

The copies are not identical: the direct capture holds the full Leaf envelope, while the PersistenceTree republishes only json.Marshal(leaf.Data), the bare payload. Any consumer therefore sees each event twice in two different shapes, which for leads means two emails per enquiry.

This affects every service that publishes tap.* directly, so it predates the change above and probably deserves its own issue against nimsforest2.

Test data

Two test leads are in TAPROOT from verifying this: verify@nimsforest.test and delta@nimsforest.test. Whoever builds the consumer should filter or ignore them.

Note on tracker

This belongs on issues.nimsforest.mynimsforest.com, which is returning 502: there is no nimsforestissue container on the org land at all, so the route has no backend. Filed here alongside #411 so it is not lost. Move it when the tracker is restored.