com_r35157_nenjim-hubd-impl_ref/openspec/changes/archive/2026-09-04-83-remove-burner-service-lifecycle-operations/design.md

Context

The Burner implementation is already both EvelynIOUBurnerService and NenjimProcess, but the service contract contains no domain operation: it exposes only duplicated startup and an implementation-specific stop lifecycle. The canonical NenjimProcess contract supports only Hub-owned start() and deliberately provides no common stop or restart.

Goals / Non-Goals

Goals:

• Preserve EvelynIOUBurnerService as an empty typed component contract for Registry lookup and dependency injection.
• Keep startup exclusively on the implementation's NenjimProcess view.
• Remove public normal stop and the internal fields/helpers used only by that operation.
• Preserve immediate fixed-delay worker startup and cleanup if worker scheduling fails.
• Describe loss of process-local uncertainty state only across a complete process restart.

Non-Goals:

• No stop or restart addition to NenjimProcess.
• No Hub shutdown or worker-control API.
• No new external Burner domain operation.
• No transaction, polling, notification, dependency, or test behavior change.

Decisions

Keep an empty typed service view

The empty interface remains a NenjimComponent. This preserves the domain-specific type, Registry visibility, and future extension point without leaking Hub-owned lifecycle to consumers or exposing the concrete implementation.

Retain only process startup

EvelynIOUBurnerServiceImpl.start() remains unchanged in responsibility and implements NenjimProcess.start(). The Hub already constructs and registers the same object, resolves it through NenjimProcess, and starts it through that view.

Remove general stop state without weakening failed-start cleanup

Delete public stop(), its stopping flag, termination wait timeout, and interruption-aware stop helper. The start() scheduling failure path continues to call shutdownNow(), clear the worker reference, reset process-local state, and throw before startup succeeds. A successful process has no public stop/restart path until Nenjim defines one centrally.

Risks / Trade-offs

• [A successful worker cannot be stopped through this implementation] → This is intentional; lifecycle expansion belongs in the common Hub/process architecture.
• [An empty service interface has no callable API] → It still supplies meaningful typed identity and prevents consumers from depending on implementation classes.
• [Operational recovery now requires process restart] → Document that restart forgets pending uncertainty state and requires external reconciliation first.

Migration Plan

1. Recompile consumers against the empty service interface.
2. Remove direct Burner start/stop calls and select startup through the existing Hub process configuration.
3. Restart the complete process only after reconciling uncertain on-chain activity; no data or configuration migration is required.