Three divergence-ledger entries say a decision is owed and nothing records who owes it or when

[ptr727]

spec/divergences.json carries three entries whose disposition is investigate. That disposition is the only one in the schema's enum that names no outcome: accepted, retire, re-vendor, track and upstream-candidate each state what happens to the divergence, where investigate states that a decision has not been made. Nothing in the file schedules that decision, so the three sit as deferrals with no owner and no date.

The three entries

All in the gaps array, quoted from the file at 6864a9b:

path	reason as recorded
pyproject.toml	The hub gained a config-only Scripts-profile pyproject.toml in #388. Decide whether to track it (intent, appliesTo python) after confirming the python repos carry an equivalent.
.github/workflows/publish-release.yml	Carried by some repos, absent from others, and varies widely (12 divergent, 5 absent). Needs a fidelity call (interface vs intent) and an appliesTo scope before tracking, since it would surface many new findings.
.github/workflows/validate-task.yml	As publish-release.yml (11 divergent, 9 absent): fidelity plus appliesTo decision pending.

The divergent and absent counts are quoted as recorded rather than re-measured. They were written against the fleet as it stood in July, and spec/fidelity_honesty.py --report joins the ledger against live reality, so the current numbers come from a run rather than from this issue.

Why this is worth an issue rather than a ledger edit

All three were added in #390 (b5c248e, 2026-07-22) and none has been touched since, which is 20 days at the time of filing. The ledger's own note says a recorded divergence still present renders as a burn-down task with its disposition, so these render, and what they render as is a task that says "decide". A reader of the report cannot tell one that is waiting on a maintainer's call from one that was written and forgotten.

The field that would carry that distinction is tracking, typed string | null by the schema. It is null on all ten entries in the file, both dispositions and all eight gaps, so its being null on these three says nothing about them in particular. The field exists and nothing uses it, which means the ledger currently cannot express "deferred, and here is where the decision is being made".

What closing this takes

Two decisions per workflow entry, both named in the reasons themselves:

1. Fidelity: interface or intent. Whether the fleet must match the hub's file or only its behaviour. Both reasons flag that tracking these would surface many new findings, which is a consequence of choosing interface and is the reason the call was deferred rather than an argument against making it.
2. An appliesTo scope, so the entry names which repositories it governs rather than all of them.

pyproject.toml needs one confirmation rather than a judgement: whether the python repos carry an equivalent. The reason already states the disposition it would take if they do, track with intent fidelity and appliesTo python.

An acceptable outcome is that a decision is genuinely not ready. In that case the entry keeps investigate and gains a tracking value pointing at this issue, which is what the field is for, and the deferral becomes visible as a deferral rather than reading as an omission.

Related

Raised while closing #667, whose convergence work is otherwise complete. The two workflow entries are its last open item; the pyproject.toml entry is the same shape and was found by reading the file rather than by that PR, so it is included here rather than left to be filed a third time.

[ptr727]

One data point for the publish-release.yml fidelity call, from the ESPHome-Config resync on 2026-08-15, where this entry was the only finding the repo could not act on.

WORKFLOW.md's source-only bullet now prescribes that file's behavior in prose: "a standalone dispatch-only publish-release.yml that inlines NBGV for the tag and action-gh-release for the release: tag + source zip + README + LICENSE, with no reusable release task and no asset download", plus the gate that its publish job needs: the repo's reusable validation task. That repo's copy implements exactly that.

So for the source-only and operational shapes at least, the required outcomes are already written down and are already what WORKFLOW.md section 4 calls a contract. That reads as an argument for interface fidelity scoped by appliesTo, rather than the intent alternative the entry's reason offers, since interface is the fidelity that checks behavior against a named contract without asserting bytes. It says nothing about the shapes that reach the file through a reusable release task, which is presumably where the 12-divergent count comes from.

No action wanted here, and the entry is correctly not ESPHome-Config's to converge. Recording it so the fidelity call has one more worked example under it.

[ptr727]

Two of the three entries are settled, so the standing count is one rather than three. Not closing, since the issue's subject is that investigate schedules no decision, and that is unchanged.

Settled in #736 (aa7bf78 on develop), both by reading every cataloged repo's copy on its ground-truth branch rather than by re-quoting the July counts:

• .github/workflows/publish-release.yml and .github/workflows/validate-task.yml are now declared in spec/files.json at intent fidelity, the publisher scoped to the three publishing releaseTrigger values and the validator appliesTo: "*". Both ledger rows are deleted, a declared file no longer being a gap.

Worth recording against this issue's premise, because it is evidence for it: the first attempt (in #732) settled both as accepted on the reasoning that no interface contract fits either file. That was half right and shipped anyway. interface genuinely does not fit, but intent does, and accepted silences the finding and stops the audit measuring the file ever again, which is the opposite of what the fleet wants for these two. It took the maintainer reading the summary to catch it.

That is the cost of a deferral with no owner: the decision eventually gets made by whoever happens to touch the ledger next, under whatever framing they arrived with. A schema field naming an owner and a date would not have prevented the wrong call, but it would have said whose call it was.

pyproject.toml remains at investigate, unchanged since it was written: "Decide whether to track it (intent, appliesTo python) after confirming the python repos carry an equivalent."