You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fleet(#1376): serving advertisement — roster serving tag + device_type on boot #1379
Problem — A peer's roster row currently has capabilities: [] and no device_type — the Fleet Manager's attach list can't show which machines have engines available to attach to. Approach — On boot, a peer writes its roster serving tag + reach coordinates (placement descriptor) + device_type (from the #1368 self-report vocabulary) so the Fleet Manager and the resolver's keeper path see it as an attach candidate. Scope — in: boot-time roster serving tag write, device_type population, placement descriptor reach coordinates. out: the resolver wiring (Slice 1), attach lifecycle (Slice 2).
Acceptance Criteria
A standalone (engine-armed) machine writes serving to its roster row's capabilities[] on boot
placementDescriptor(row) returns serving: true for the row
The roster row passes parseRosterRow validation
A machine that is NOT engine-armed (a hosted-only / never-fork client) does NOT write serving
Testing Decisions
Extend the existing fleet_roster.test.ts suite: add a case for boot-time serving write on an engine-armed machine, and a negative case for a never-fork client. Reuse placementDescriptor assertions already in the suite.
Key Decisions
serving is derived from being engine-armed, not a user toggle (H1). The user-facing toggle comes with the ADR 0029 surface-collapse follow-up.
Constraints & Invariants
The serving tag rides the existing capabilities[] axis (ADR 0026) — no new roster schema fields.
server_mode is unchanged; serving is orthogonal.
Prior Art
fleet_roster.ts — the serving tag, placementDescriptor, KNOWN_CAPABILITY_TAGS, device_type.
Important
Problem — A peer's roster row currently has
capabilities: []and nodevice_type— the Fleet Manager's attach list can't show which machines have engines available to attach to.Approach — On boot, a peer writes its roster
servingtag + reach coordinates (placement descriptor) +device_type(from the #1368 self-report vocabulary) so the Fleet Manager and the resolver's keeper path see it as an attach candidate.Scope — in: boot-time roster
servingtag write,device_typepopulation, placement descriptor reach coordinates. out: the resolver wiring (Slice 1), attach lifecycle (Slice 2).Acceptance Criteria
servingto its roster row'scapabilities[]on bootdevice_typeis populated using the fleet: self-reported device identity (friendly name + device type) in the roster #1368 self-report vocabularyplacementDescriptor(row)returnsserving: truefor the rowparseRosterRowvalidationhosted-only/ never-fork client) does NOT writeservingTesting Decisions
Extend the existing
fleet_roster.test.tssuite: add a case for boot-timeservingwrite on an engine-armed machine, and a negative case for a never-fork client. ReuseplacementDescriptorassertions already in the suite.Key Decisions
servingis derived from being engine-armed, not a user toggle (H1). The user-facing toggle comes with the ADR 0029 surface-collapse follow-up.Constraints & Invariants
servingtag rides the existingcapabilities[]axis (ADR 0026) — no new roster schema fields.server_modeis unchanged;servingis orthogonal.Prior Art
fleet_roster.ts— theservingtag,placementDescriptor,KNOWN_CAPABILITY_TAGS,device_type.Source
Part of #1376. References #1341 (peer serving advertisement) as the original slice.