feat(sync): custom bundle path + hybrid mode merge

[Copilot]

template-bundles.yml was hardcoded to .rhiza/template-bundles.yml in the upstream repo, and hybrid mode (templates: + include:) silently dropped explicit include: paths by overwriting them with resolved bundle paths.

Changes

RhizaTemplate model

• New template_bundles_path field (default: .rhiza/template-bundles.yml) — reads from template-bundles-path in YAML; omitted from serialisation when default to keep configs clean

_clone_template() in sync.py

• Uses template.template_bundles_path instead of the hardcoded string
• Hybrid mode fix: merges resolved bundle paths with explicit include: paths (deduplicated) rather than overwriting

# downstream template.yml — bundle definitions at a non-standard upstream location
template-bundles-path: tooling/my-bundles.yml
templates:
  - core
include:
  - extra/custom-file.txt   # now correctly synced alongside bundle files

Tests

• test_hybrid_mode_merges_bundle_and_include_paths — update_sparse_checkout receives both resolved bundle paths and explicit include: paths
• test_custom_template_bundles_path_is_used — custom path propagates to both clone_repository and RhizaBundles.from_yaml
• Model-level tests for default value, round-trip serialisation, and default suppression

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Allow users to point to a location for template</issue_title>
<issue_description>Allow users to point to a location for the template.yml file location and also where the template lock file will be produced. Write a clear e2e test for this.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Allow users to point to a location for template #439

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[HarryCampion]

@copilot perhaps we have path to template, e.g. --path-to-template . would be the root, and would look for both template.yml, and template.lock. E.g. all template related files are expected to be under the same path.

[Copilot]

@copilot perhaps we have path to template, e.g. --path-to-template . would be the root, and would look for both template.yml, and template.lock. E.g. all template related files are e...

Done in d0733b9. Replaced the two separate --config/--lock-file options with a single --path-to-template option. Both template.yml and template.lock are resolved from the same directory:

rhiza sync --path-to-template /custom/rhiza   # reads /custom/rhiza/template.yml, writes /custom/rhiza/template.lock
rhiza sync --path-to-template .               # uses project root for both files

The default behaviour (no flag → .rhiza/) is unchanged. E2e tests cover the custom directory, project-root (--path-to-template .), subsequent incremental syncs, and CLI wiring.

[HarryCampion]

@copilot perhaps we have path to template, e.g. --path-to-template . would be the root, and would look for both template.yml, and template.lock. E.g. all template related files are e...

Done in d0733b9. Replaced the two separate --config/--lock-file options with a single --path-to-template option. Both template.yml and template.lock are resolved from the same directory:

rhiza sync --path-to-template /custom/rhiza   # reads /custom/rhiza/template.yml, writes /custom/rhiza/template.lock
rhiza sync --path-to-template .               # uses project root for both files

The default behaviour (no flag → .rhiza/) is unchanged. E2e tests cover the custom directory, project-root (--path-to-template .), subsequent incremental syncs, and CLI wiring.

@copilot great. What about custom bundles?

[Copilot]

@copilot perhaps we have path to template, e.g. --path-to-template . would be the root, and would look for both template.yml, and template.lock. E.g. all template related files a...

Bundle definitions (template-bundles.yml) live inside the upstream template repository — they're fetched during sync via sparse checkout and aren't a local file. The --path-to-template option covers the local side: template.yml (which lists which bundles to use via templates:) and template.lock. So if you want to use a non-standard set of bundles, you'd point --path-to-template at a directory containing a template.yml with your chosen templates: list, and that's already supported.

If the ask is to support a locally-overridden template-bundles.yml (i.e. bundle definitions that don't come from the upstream repo), that would be a separate feature. Let me know if that's what you have in mind.