Conversation
## Summary Introduces a second, first-class branching/workflow model - **operational** - alongside the default **release** model, selected per repo by a new registry `workflowModel` field (`release` | `operational`, default `release`). **Operational** repos (live-service config: Vantage-Config, ESPHome-Config, HomeAutomation, HomeAssistant-Config) commit configuration **directly to `develop`** (no feature branch) and promote a known-good snapshot to `main` via an occasional PR. - Only the `develop` ruleset differs: new `repo-config/operational/develop.json` allows direct signed pushes (`deletion` + `non_fast_forward` + `required_signatures` only). `main.json` is **shared**, so the promotion PR still enforces the required lint check - a broken config can never reach `main`. - **`develop`** = live edits with *advisory* CI on push; **`main`** = known-good snapshot with CI *enforced* on the promotion. - CI is **lint/validation only** (editorconfig/EOL plus domain linters - HA/ESPHome config validation, firmware build - **no unit tests**). - Still cut GitHub releases, but **only** by manual `workflow_dispatch` (`releaseTrigger: dispatch-only`), never automatically. ## Changes - **registry**: `workflowModel` enum + property + default; four operational repos marked (`workflowModel`, `groundTruthBranch`, `dispatch-only` release, `github-release` publish); `validate.py` enforces the enum. - **repo-config**: `operational/develop.json` variant; `configure.sh` selects the `develop` ruleset from the repo's `workflowModel` (override via 2nd arg). - **spec/project-types.json**: branch-model audit is model-aware; adds the operational lint-CI expectation. - **docs**: AGENTS.md, WORKFLOW.md, repo-config/README.md, README.md document both models; cspell allows `esphome`/`hass`. ## Verification `python3 spec/validate.py` passes (21 cataloged clean; rejects an invalid `workflowModel`); `bash -n configure.sh` clean; `configure.sh` model resolution verified for all repos; markdownlint + cspell + editorconfig-checker green. ## Follow-up (separate, per-repo rollout) Bringing the four repos up to the operational baseline (missing files, lint+domain CI, `version.json` + `publish-release.yml`, apply rulesets) is a separate live-repo effort, starting with ESPHome-Config end-to-end. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…288) ## Summary A config repo is a *view into an application's configuration directory* (often the exact tree mounted into that app's container), so its files must use the line ending the app itself reads and writes - not the fleet CRLF default. Encode this per repo instead of forcing one rule on all config repos. - **AGENTS.md "Line Endings"**: operational repos set the global `[*] end_of_line` default to the consuming app's native platform - **LF** for Linux-native/container config (ESPHome, Home Assistant, devcontainer-only/HACS), **CRLF** for a Windows-native editor (Vantage-Config / Design Center). Execution-sensitive LF pins still apply; do not re-normalize such a repo to the fleet default. - **registry**: new `lineEndings` field (`lf` | `crlf`); set `lf` on ESPHome-Config, HomeAssistant-Config, HomeAutomation and `crlf` on Vantage-Config; schema + `validate.py` enforce the enum. - **spec/project-types.json** `recurring.eol`: the global default is CRLF for release repos or the registry `lineEndings` value for operational repos. ## Context Surfaced during the operational-repo rollout: ESPHome-Config uses a global `end_of_line = lf` (it is edited as the ESPHome container's `/config` view). Matching the app's platform is correct; converging it to fleet-CRLF would be over-normalization. ## Verification `python3 spec/validate.py` passes (rejects an invalid `lineEndings`); markdownlint + cspell clean on AGENTS.md. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary Follow-up from the operational-repo rollout. - **AGENTS.md "Line Endings"**: document **mixed-consumer** operational repos - the registry `lineEndings` records the *primary* platform's default, and a subtree carries a per-path `.editorconfig` override for its own consumer (treated like any tool-owned format). Example: `HomeAutomation` is `lf`-global (Linux Proxmox host: docker-compose, shell, dnsmasq/unbound) with its Windows-edited `Vantage/**` Design Center files (UTF-8 CRLF `.dc` XML) pinned `crlf`. - **registry**: remove `Vantage-Config`. Design Center is now freely available, so its installer archive is discarded; the Vantage config is consolidated into `HomeAutomation` (which already carries the newer snapshots). The consolidation + dual-EOL are recorded on the `HomeAutomation` entry. - **cspell**: add `dnsmasq`. ## Verification `python3 spec/validate.py` passes (20 cataloged); markdownlint + cspell clean on AGENTS.md. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ed-EOL repos (#290) ## Summary - **Rename** the registry entry `HomeAutomation` -> `HomeAutomation-Config` (name + url) for fleet naming consistency - config repos are `*-Config` (`ESPHome-Config`, `HomeAssistant-Config`, `Vantage-Config`). The GitHub repo is already renamed; old URLs redirect. - **AGENTS.md "Line Endings"**: rewrite the mixed-consumer guidance to lead with the *preferred* answer - **split by platform into single-platform repos** (the Vantage/Design Center config goes to its own Windows/CRLF `Vantage-Config`, not a `Vantage/**` subtree in the `lf` `HomeAutomation-Config`). The per-path `.editorconfig` override survives only as a fallback for a subtree that genuinely cannot be split. This supersedes the `#289` "HomeAutomation is a mixed repo" example, which the split decision makes obsolete. ## Context During the operational-repo rollout we decided to keep config repos single-platform: recreate a lean `Vantage-Config` (Windows/CRLF) rather than carry Vantage as a CRLF bolt-on inside the otherwise-Linux HomeAutomation repo. ## Verification `python3 spec/validate.py` passes (20 cataloged); markdownlint + cspell clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary
CODESTYLE.md's line-ending item stated a fixed "CRLF for YAML/JSON/..."
rule, which contradicts operational (Linux-consumed config) repos that
use a global **LF** default per their `.editorconfig` and the AGENTS.md
operational `lineEndings` rule. Line-ending governance already lives in
AGENTS.md ("Line Endings"), so point to it instead of restating a fixed
ending here.
## Context
Surfaced by Copilot while reviewing HomeAssistant-Config (an `lf`
operational repo) carrying CODESTYLE.md verbatim - the hardcoded CRLF
line read as misleading guidance for that repo.
## Verification
markdownlint + cspell clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Promotes develop to main while introducing and documenting an additional operational workflow/branching model for live-config repositories, including registry fields and tooling to apply model-specific rulesets and line-ending policy.
Changes:
- Document the
releasevsoperationalworkflow models and their CI/release expectations in governance docs. - Extend the fleet registry with
workflowModelandlineEndings, and validate these fields inspec/validate.py. - Add an operational
developruleset payload and updaterepo-config/configure.shto select the correctdevelopruleset by model.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| WORKFLOW.md | Documents the operational workflow model and how it maps onto the existing contract/scenarios. |
| spec/validate.py | Adds validation for workflowModel / lineEndings fields and defaults. |
| spec/project-types.json | Updates branch-model audit assertions to be workflow-model aware. |
| repo-config/README.md | Documents the model-specific develop ruleset and updated configure.sh usage. |
| repo-config/operational/develop.json | Adds the operational develop ruleset payload (direct signed pushes). |
| repo-config/configure.sh | Selects the develop ruleset based on registry workflowModel (or arg override). |
| registry/repos.schema.json | Adds schema enums/fields for workflowModel and lineEndings, and a conditional requirement. |
| registry/repos.json | Records workflowModel / lineEndings and related metadata for operational repos. |
| README.md | Updates repo operating model summary to mention workflowModel and operational repos. |
| cspell.json | Adds operational-repo vocabulary to the dictionary. |
| CODESTYLE.md | Defers line-ending governance to AGENTS.md (instead of hardcoding CRLF). |
| AGENTS.md | Documents operational workflow model and per-repo line-ending governance for config repos. |
Address Copilot review on the promotion PR #292: - `spec/validate.py`: require `lineEndings` by the effective workflow model (repo -> `defaults.workflowModel` -> release), matching `configure.sh`. - `registry/repos.schema.json`: use the standard `$comment` annotation keyword. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Comment on lines
+66
to
67
| for file in "$develop_ruleset" "$script_dir/main.json"; do | ||
| [ -e "$file" ] || continue |
This was referenced Aug 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promote the current
developsnapshot tomain.Adds the operational workflow model and its supporting rules/tooling (PRs #287-#291):
workflowModel(direct-to-developlive-config repos; sharedmainruleset; dispatch-only releases; model-awareconfigure.sh).lineEndingsfield (operational repos follow the consuming app's platform; validated).HomeAutomation->HomeAutomation-Config; EOL guidance leads with the split-preferred approach.lfoperational repos).Applied end-to-end to ESPHome-Config, HomeAutomation-Config, HomeAssistant-Config (lf) and the recreated Vantage-Config (crlf).
🤖 Generated with Claude Code