You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Complete the remaining work required to make the Docs Registry the production knowledge and schema source for Wrangles. The Registry contract remains pre-production until the acceptance criteria below are met.
This issue tracks two distinct migrations. Neither is the process for deprecating or removing an executable wrangle key.
1. Retiring Baver's local source files
The committed wrangles-docs/wrangle-docs/**/_sources/ files belong to the previous documentation workflow. They are migration input and reconciliation evidence, not the ongoing authoring source.
Inventory every _sources file and migrate useful descriptions, examples, access requirements, and provenance into registry/wrangles/, recording intentional omissions.
Review the Registry-generated pages and confirm final routes and redirects.
Remove _sources from Registry reconciliation.
Retire the old _sources generation and synchronization workflow, including .github/agents/sync.md.
Preserve a tagged or archived rollback snapshot.
Deploy the Registry pages and remove the obsolete _sources files.
This workstream is complete when no supported build, compiler, or authoring workflow reads from or writes to _sources.
2. Migrating the schema from WranglesPY to the Docs Registry
WranglesPY remains authoritative for callable signatures, runtime defaults, and behavior. The Docs Registry becomes authoritative for descriptions, parameter guidance, accepted-value constraints, examples, access, lifecycle, and provenance.
Reconcile every callable wrangle and public parameter against a pinned WranglesPY runtime manifest; resolve every unexplained key, required-state, default, common-control, and accepted-value conflict.
Complete Registry content and assign canonical database UUIDs where missing.
Stabilize and version the Registry entry schema, compiled contract, recipe-schema URLs, compatibility rules, and change-management policy.
Generate the recipe JSON Schema and any temporary WranglesPY _schema compatibility view from the Registry.
Add deterministic parity checks so schema copies cannot drift.
Cut over WranglesXL, VS Code, APIs, the docs site, and Recipe Writer clients to Registry-generated contracts.
Remove hand-maintained WranglesPY _schema content, or retain only a generated compatibility view for explicitly supported legacy readers.
Add offline execution verification for local examples and controlled live verification for service-backed examples.
Make invalid source, duplicate keys, invalid recipes, missing fixtures, runtime drift, and stale generated outputs fail CI.
Deploy and verify stable documentation routes and immutable Registry artifacts at canonical public URLs.
Document ownership, release, rollback, and deprecation procedures.
Tag the first production Registry version and change the contract status to production.
Acceptance criteria
registry/wrangles/ is the sole editorial source for Registry content.
WranglesPY code remains the sole authority for executable behavior and runtime-owned facts.
Supported consumers use the Registry-generated schema and contracts.
Hand-maintained _schema content and the old _sources workflow no longer create competing authorities.
The production Registry release is immutable, publicly reachable, reproducible, and covered by CI.
Goal
Complete the remaining work required to make the Docs Registry the production knowledge and schema source for Wrangles. The Registry contract remains pre-production until the acceptance criteria below are met.
This issue tracks two distinct migrations. Neither is the process for deprecating or removing an executable wrangle key.
1. Retiring Baver's local source files
The committed
wrangles-docs/wrangle-docs/**/_sources/files belong to the previous documentation workflow. They are migration input and reconciliation evidence, not the ongoing authoring source._sourcesfile and migrate useful descriptions, examples, access requirements, and provenance intoregistry/wrangles/, recording intentional omissions._sourcesfrom Registry reconciliation._sourcesgeneration and synchronization workflow, including.github/agents/sync.md._sourcesfiles.This workstream is complete when no supported build, compiler, or authoring workflow reads from or writes to
_sources.2. Migrating the schema from WranglesPY to the Docs Registry
WranglesPY remains authoritative for callable signatures, runtime defaults, and behavior. The Docs Registry becomes authoritative for descriptions, parameter guidance, accepted-value constraints, examples, access, lifecycle, and provenance.
_schemacompatibility view from the Registry._schemacontent, or retain only a generated compatibility view for explicitly supported legacy readers.production.Acceptance criteria
registry/wrangles/is the sole editorial source for Registry content._schemacontent and the old_sourcesworkflow no longer create competing authorities.Related implementation work: #26.