Skip to content

Complete Docs Registry migration and production cutover #27

Description

@ebhills

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.

  • 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.

Related implementation work: #26.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions