ditc edit-pass: verified → ditc@3.5.0 (stable-promotion unblock) #22
Loading…
Reference in a new issue
No description provided.
Delete branch "lockstep-repair-ditc-3.5.0"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The ditc manual edit-pass for the ditc 3.5.0 stable promotion. Every covering page is re-checked and its
verified:advanced toditc@3.5.0. Five pages had real drift, and those are fixed. The glossary registry definitions are synced to canon 6.0.0. Do not merge until the realm agent (deepnet) has reviewed this.What the re-check measured each page against
captures/ditc/**. Every capture body was diffed against the live release binary's--help(ditc 3.5.0-rc.1,/tmp/opencode/e2e/ditc-x86_64-unknown-linux-musl) on all 39 surfaces. There were 0 differences.v3.3.0..v3.5.0-rc.1delta in dit-client. Behavior changes are infff3c56(bare-domain sign-in),8c64450(dit.requires/dit.gated_pathscapability negotiation, plus commented scaffold examples) and7ddcc81(feedback session-token selection). The rest are release, CI and canon re-vendor commits with nosrc/change. The two pages still at 3.2.0 were also checked againstv3.2.0..v3.3.0.v3.5.0-rc.1, for every printed string and behavior the pages quote:No session for tenant …,No session to clear.,declaration refreshed,Active tenant: <slug>, the three-step first-run tour, the harness set (Claude Code / Codex / opencode),resolvable:, the--linesdefault of 100, the--ttldefault of 24 and max of 168, the--purge/--forcesemantics, and the specify/clarify limits of 3 and 5.ditc …command and--flagon all pages against the captures. It found 0 unknown groups, subcommands or flags, and everyUsage:line matches.Per-page verdicts
forge.form. One sentence added; the help example still printsforge.<tenant>.<zone>, so the existing guidance standskey: urlcaution is still true at 3.5.0)session login/logout,tenant useandfeedbackhave none. Now scoped to commands that change an app or its secretsverified:)stable/testingregistry_definitionsynced verbatim to canon 6.0.0 (LIFECYCLE-016). This was the pre-existingcheck-proseREGISTRY failureCommits:
af206c7glossary ·be51f6edrift fixes ·778db4averified advance.Gate outputs (worktree, after the commits)
Before this branch: check-prose had 2 REGISTRY findings, and lockstep showed 16 FRESHNESS warnings, which become failures under the promotion gate.
Gaps and items for the reviewer
ditc@3.5.0, but the binary checked is3.5.0-rc.1. Canon 6.0.0 has stable name its rc, so the stable bytes should be identical. If stable is re-cut from a later rc, re-diff the captures first.--help/--versionwere run. Printed strings come from source at the tag, not from running the commands. The five MESSAGE SKIPs remain because there is no message catalog for ditc 3.5.0-rc.1.stabledefinition reads "it moves only on the operator's word". In the ditc manual, "operator" means the DeepNet operator, but an app's stable channel moves when the user deploys a release tag. The glossary shows the registry definition next to the plain gloss, which carries the correct meaning. The REGISTRY gate forces the verbatim copy, so this is a canon-vs-app-channel wording question for the canon owner, not a page fix.int_621bfef0a99440c4913c3351ad990b21was published after the edits, so it was not declared before editing. It found 0 conflicts. The in-flight intentint_2fdbb835…(deepnet-26-channel) addssrc/ditc/250-release-channel.md. That file does not overlap with this branch, and its surface is not in the 3.5.0 binary.Assisted-by: author:anthropic/claude-opus-5-5
capture-cli.py run per the tools README ('run after every release ships') against the released binaries: ditc v3.5.0-rc.1 (the stable-to-be; host from the publish at forge.deepnet.com/deepnet/dit-releases), dito v6.1.0 (tonight's stable, 0cb03c002170). Every capture body is byte-identical to the 3.3.0/rc.26-era set — 3.4.x shipped no --help-visible surface change — only the provenance headers move. Assisted-by: deepnet:synthetic/hf:zai-org/GLM-5.3Merge conflict note: the only conflicting file is
provenance.json. Its branch-side change comes from the pre-existing capture-refresh commit6cb7f68(a local ditc deploy rewrote it:builder: jsutter,channelkey dropped), not from this edit-pass. Main's4de1682(generated: stable publication) also rewrote it. This is a generated file outside the edit-pass lane, so it is left to the publishing step. Taking main's copy, or regenerating it at publish, resolves it. src/ditc/** merges cleanly.