Surfaced while carrying the operational baseline into ptr727/ESPHome-Config (ESPHome-Config#46, PRs ESPHome-Config#47 and ESPHome-Config#48). ESPHome-Config is the first public repo to carry repo-config/README.md and a repo-scoped spec/secrets.json, which exposed two things worth fixing at the hub.
Finding 1: repo-config/README.md carries fleet carry-process narration (and a private-repo link) into every downstream copy
The hub's repo-config/README.md includes a ## Downstream Carry section that documents the fleet carry process (rules for the carried copy, "hub-only references stay plain text", the adapted self-audit carry, the regen snippet). That is meta-guidance for whoever performs the carry, not a current fact about the repo the file lands in. Because the README is itself carried verbatim, every downstream repo ships a copy of the fleet process narration.
It also hardcodes a reference link to a private repo:
[vantage-config]: https://github.com/ptr727/Vantage-Config
Every prior carrier (Vantage-Config, HomeAutomation-Config) is private, so the link resolved for the audience that could see the repo at all. ESPHome-Config is public, so that link now 404s for any external reader. This is the first public carrier, which is why it surfaced now.
In the ESPHome-Config carry we dropped the entire ## Downstream Carry section, the [vantage-config] link definition, and the now-dangling "(see Downstream Carry)" cross-refs, leaving the carried README to state current facts about that repo's config only.
Proposal: keep the carry-process guidance hub-only (e.g. in a hub-only doc, or a section that is stripped on carry), so the carried repo-config/README.md states only current facts about the repo it lands in. That also stops the private-repo link from ever leaking into a public carrier. If a reference example belongs in carried docs, point it at a public repo or de-link it.
Finding 2: repo-scoped spec/secrets.json (targetMechanisms, no mechanisms) reads as a schema bug to reviewers
The repo-scoped adaptation carries baseline plus targetMechanisms (the target -> mechanism routing map) and omits mechanisms/typeMechanisms when none apply (a source-only repo whose only target is github-release: null). AUDIT.md's secrets check enumerates:
[.baseline, ((.mechanisms // {}) | .[])] | map(... .requires[]) ...
It never reads targetMechanisms. That is correct - targetMechanisms is a routing map, and a repo-scoped spec only lists the mechanisms it actually uses - but the combination (a top-level targetMechanisms key the audit ignores, and no mechanisms key at all) reads as "the audit ignores the spec's mechanism list."
This is not a hypothetical: Copilot flagged it on both PRs of the standup - once on the develop PR (ESPHome-Config#47) and twice on the develop -> main PR (ESPHome-Config#48), each asserting the audit would "silently ignore" non-baseline required secrets. All three were declined as not-a-bug (the baseline App pair is enumerated correctly; a future secret-bearing mechanism would add a mechanisms entry that the audit then picks up). But two independent review passes tripping on the same shape is signal that the schema is non-obvious to a fresh reader.
Proposal (any one closes it):
- In the repo-scoped adaptation, drop
targetMechanisms when every target maps to a null mechanism (there is nothing to route), so the file carries just baseline.
- Have
AUDIT.md assert targetMechanisms/mechanisms consistency (every non-null targetMechanisms value resolves to a mechanisms entry), so the routing map is validated rather than silently unread.
- Add a one-line schema note in the repo-scoped spec stating that
targetMechanisms is a routing map and the audit enumerates baseline + mechanisms.
Surfaced while carrying the operational baseline into ptr727/ESPHome-Config (ESPHome-Config#46, PRs ESPHome-Config#47 and ESPHome-Config#48). ESPHome-Config is the first public repo to carry
repo-config/README.mdand a repo-scopedspec/secrets.json, which exposed two things worth fixing at the hub.Finding 1:
repo-config/README.mdcarries fleet carry-process narration (and a private-repo link) into every downstream copyThe hub's
repo-config/README.mdincludes a## Downstream Carrysection that documents the fleet carry process (rules for the carried copy, "hub-only references stay plain text", the adapted self-audit carry, the regen snippet). That is meta-guidance for whoever performs the carry, not a current fact about the repo the file lands in. Because the README is itself carried verbatim, every downstream repo ships a copy of the fleet process narration.It also hardcodes a reference link to a private repo:
Every prior carrier (Vantage-Config, HomeAutomation-Config) is private, so the link resolved for the audience that could see the repo at all. ESPHome-Config is public, so that link now 404s for any external reader. This is the first public carrier, which is why it surfaced now.
In the ESPHome-Config carry we dropped the entire
## Downstream Carrysection, the[vantage-config]link definition, and the now-dangling "(see Downstream Carry)" cross-refs, leaving the carried README to state current facts about that repo's config only.Proposal: keep the carry-process guidance hub-only (e.g. in a hub-only doc, or a section that is stripped on carry), so the carried
repo-config/README.mdstates only current facts about the repo it lands in. That also stops the private-repo link from ever leaking into a public carrier. If a reference example belongs in carried docs, point it at a public repo or de-link it.Finding 2: repo-scoped
spec/secrets.json(targetMechanisms, nomechanisms) reads as a schema bug to reviewersThe repo-scoped adaptation carries
baselineplustargetMechanisms(the target -> mechanism routing map) and omitsmechanisms/typeMechanismswhen none apply (a source-only repo whose only target isgithub-release: null).AUDIT.md's secrets check enumerates:It never reads
targetMechanisms. That is correct -targetMechanismsis a routing map, and a repo-scoped spec only lists themechanismsit actually uses - but the combination (a top-leveltargetMechanismskey the audit ignores, and nomechanismskey at all) reads as "the audit ignores the spec's mechanism list."This is not a hypothetical: Copilot flagged it on both PRs of the standup - once on the develop PR (ESPHome-Config#47) and twice on the develop -> main PR (ESPHome-Config#48), each asserting the audit would "silently ignore" non-baseline required secrets. All three were declined as not-a-bug (the baseline App pair is enumerated correctly; a future secret-bearing mechanism would add a
mechanismsentry that the audit then picks up). But two independent review passes tripping on the same shape is signal that the schema is non-obvious to a fresh reader.Proposal (any one closes it):
targetMechanismswhen every target maps to a null mechanism (there is nothing to route), so the file carries justbaseline.AUDIT.mdasserttargetMechanisms/mechanismsconsistency (every non-nulltargetMechanismsvalue resolves to amechanismsentry), so the routing map is validated rather than silently unread.targetMechanismsis a routing map and the audit enumeratesbaseline+mechanisms.