The service heartbeat carries no host

Every service that embeds the heartbeat publisher sends its name, its instance id and its release, and it never says which machine it runs on. The compute side is the mirror: each node sample carries the host id of the machine that published it, and no release and no instance id. The two describe the same fleet, and no key joins them:

• The grid screen cannot place a compute wrapper on the node it runs on, so the wrappers sit in a panel beside the node table (Watch the compute grid).
• The services screen cannot say where an instance runs (See the running services).

The candidate is one field: a host_id on service_heartbeat_message, stored on service_sample beside instance_id. The publishing process already holds the id — the compute wrapper takes it at startup and stamps its node samples with it, and its heartbeat sender is constructed with the same id — so the message drops a value the sender already has. One field answers both questions, and each node row of the grid could then state the release it runs. The alternative — a release and an instance id on the node sample — answers the first question only.

The operator's questions are the join: which node runs this wrapper, and which host runs this instance. Both screens are read-only views over samples the installation already stores, and both stop at the same missing key. The fix is cheap while the heartbeat is one message and one table; every future screen that reads samples inherits either the join or the gap.

Done in task Carry the host on the heartbeat, under story Implement the operations journeys in ores.web. The candidate became the field: host_id sits on service_heartbeat_message and service_sample, and the join exists.

The publishing process fills it where it already holds it. The compute wrapper passes cfg.host_id, the same value it stamps on its node samples; every other service sends the empty string. The telemetry service copies each beat's host beside its instance, so a wrapper's row can name its node, and an instance's row its host.

Verification lives on the task: a repository test writes a sample with a host id and reads it back, the telemetry and compute suites pass, and the recreated database stores the column.

• projects/ores.telemetry/modeling/ores.telemetry.service_samples.org — service_heartbeat_message (service name, instance id, release) and service_sample, the stored row
• projects/ores.compute/modeling/ores.compute.telemetry.org — node_sample_message, which carries host_id and no release
• projects/ores.compute/wrapper/src/app/application.cpp — the node sample message is stamped with host_id, and the heartbeat sender receives the same id
• projects/ores.service/modeling/component_overview.org — the shared heartbeat publisher every service embeds

• Watch the compute grid — the wrappers panel that cannot join its rows to the nodes
• See the running services — the screen that cannot say where an instance is