What
The gds binary on the operator device reports:
gds version 0.6.0+source.3f98c262c605
3f98c262c605 is fix(ruleset): accept exact post-write serialization in NDDev-it-com/github-device-sync — the legacy control plane that was archived on 2026-08-23. The commit does not exist in this repository:
$ git -C modules/github-device-sync cat-file -t 3f98c262c605
fatal: Not a valid object name
So the tool every local operation runs through is compiled from a retired repository rather than from the module the estate pins.
Why it matters, concretely
The two sources disagree about a required field, and the disagreement is load-bearing.
gds module update-pin --plan refuses on this repository's own sibling module:
GDS_INSTANCE_INVALID: modules/github-actions/.gds/repository.yaml violates repository:
at '/ci': missing property 'workflow_ref'
But this module's schema does not require it:
schemas/v1/repository.schema.json -> /ci required = [profile, go_version,
build_command, test_command, timeout_minutes] # workflow_ref optional
The legacy schema required it; the public one relaxed it. The binary carries the old rule, so the canonical engine rejects the canonical anchors. Module pin transactions cannot run at all on the affected modules.
Rebuilding from the pinned commit with the repository's own recipe clears that rejection, which confirms the cause rather than merely correlating with it.
Two things that block a straight swap
Both are why this is filed instead of fixed in place — replacing the binary today would break gds for the operator.
1. No release tags here. scripts/bootstrap-device.sh:source_build_version() derives the version from git describe --tags --match 'gds-v[0-9]*'. This repository has no such tag, so the canonical recipe produces:
0.1.0-dev+source.0dd0b0a7ff85 # rebuilt, correct source
0.6.0+source.3f98c262c605 # installed, legacy source
A correct rebuild therefore reads as a downgrade from 0.6.0 to 0.1.0-dev. The version line has to mean something before the swap is safe to make.
2. Estate trust is registered against a different repository id. The rebuilt binary reaches further and then stops:
GDS_POLICY_ESTATE_NOT_PROVEN: A trusted estate root is required to resolve
canonical policy sources.
repository_id: repo_01M0EYTYCS3DNXDHZ0CVKXWWW1
That id is not the estate's own (repo_01M0F128B3N0VGB1A71Y5SCQGM). Trust needs to be re-established for the public-module lineage.
What would close this
- cut a
gds-v* release tag here so the canonical build recipe produces a truthful version;
- re-register the trusted estate root against the public-module lineage;
- rebuild and install through
scripts/bootstrap-device.sh --apply rather than by hand, so the device descriptor records what it runs;
- add a check that fails when the running
gds reports a source commit absent from the pinned module — the current failure mode is a confusing schema error several layers away from its cause.
The last one is the general fix. A tool built from a repository nobody consumes any more will keep producing errors that look like data defects.
What
The
gdsbinary on the operator device reports:3f98c262c605isfix(ruleset): accept exact post-write serializationinNDDev-it-com/github-device-sync— the legacy control plane that was archived on 2026-08-23. The commit does not exist in this repository:So the tool every local operation runs through is compiled from a retired repository rather than from the module the estate pins.
Why it matters, concretely
The two sources disagree about a required field, and the disagreement is load-bearing.
gds module update-pin --planrefuses on this repository's own sibling module:But this module's schema does not require it:
The legacy schema required it; the public one relaxed it. The binary carries the old rule, so the canonical engine rejects the canonical anchors. Module pin transactions cannot run at all on the affected modules.
Rebuilding from the pinned commit with the repository's own recipe clears that rejection, which confirms the cause rather than merely correlating with it.
Two things that block a straight swap
Both are why this is filed instead of fixed in place — replacing the binary today would break
gdsfor the operator.1. No release tags here.
scripts/bootstrap-device.sh:source_build_version()derives the version fromgit describe --tags --match 'gds-v[0-9]*'. This repository has no such tag, so the canonical recipe produces:A correct rebuild therefore reads as a downgrade from
0.6.0to0.1.0-dev. The version line has to mean something before the swap is safe to make.2. Estate trust is registered against a different repository id. The rebuilt binary reaches further and then stops:
That id is not the estate's own (
repo_01M0F128B3N0VGB1A71Y5SCQGM). Trust needs to be re-established for the public-module lineage.What would close this
gds-v*release tag here so the canonical build recipe produces a truthful version;scripts/bootstrap-device.sh --applyrather than by hand, so the device descriptor records what it runs;gdsreports a source commit absent from the pinned module — the current failure mode is a confusing schema error several layers away from its cause.The last one is the general fix. A tool built from a repository nobody consumes any more will keep producing errors that look like data defects.