Skip to content

feat(plugin): compose each served unit's schema, then unify it onto the base - #1115

Merged
github-actions[bot] merged 4 commits into
mainfrom
feat/plugin-schema-per-unit-compose
Nov 9, 2026
Merged

feat(plugin): compose each served unit's schema, then unify it onto the base#1115
github-actions[bot] merged 4 commits into
mainfrom
feat/plugin-schema-per-unit-compose

Conversation

@aitrawog

@aitrawog aitrawog commented Nov 9, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

opencharly/sdk#490's second ordered root: the host's plugin schema gate no longer joins unit
sources into one compilation unit.

compileBasePlusServed compiled strings.Join(everyLoadedUnit, "\n") onto charly's base, and
registerPluginUnitSchema first compiled each unit's text standalone with no CUE module in
scope. Both shapes are text, and text cannot carry the import this cutover exists for. Measured
on the pre-change tree, with a plugin schema that imports github.com/opencharly/spec/schema:

ONE unit, old text compile            -> package "github.com/opencharly/spec/schema" imported but not defined in  (and 1 more errors)
TWO units joined, old text compile    -> expected label or ':', found 'STRING' "github.com/opencharly/spec/schema"

The second is a failure #490 names as independent of the first: N units joined into one file
put N import clauses in one compilation unit, which is not CUE at all.

Now each unit is COMPOSED as its own CUE module instance and the values are unified onto the
base — the unit boundary lands exactly where CUE's own package boundary is: one package per
plugin. The composer is spec/schemacompose, the ONE composer in the contract module: this host
may import github.com/opencharly/spec and may NOT import github.com/opencharly/sdk (this
repo's import-purity gate, "the sdk mechanism kits and the sdk root plugin-authoring package are
for PLUGINS to import, never the host"), while the serve side may import both — so the shared
home is the only place the two halves can judge the same schema with the same code.

The running value is grown one unify per registration, not rebuilt from the base. That is a
measured requirement, not a refinement: rebuilding made plugin loading quadratic, and
charly/charly's TestMain — which registers the 63 builtin plugin schemas — went from 1.4 s to
26.4 s, which then pushed TestConnectPluginReady_HonorsACallerCancellation past its 10 s bound,
because the fixture's child process could not finish its own TestMain and answer the handshake.
With one unify per registration TestMain is 1.1 s and that test passes at 1.45 s.

The declarations the gate reads per source are unchanged: topLevelDefNames now reads the
composed unit's value, which carries the same top-level definitions, and the charly#770
collision identity index is untouched.

The composer's deep arms live where the composer lives: opencharly/spec#297 tagged
v0.2026313.453, which this change pins.

Files

File Change
charly/plugin_loader.go per-unit compose then unify; the running value grown one unify per registration; the doc comments follow the contract
charly/plugin_schema_import_test.go the host's own acceptance: an importing unit is gated and its imported def enforced; two importing units coexist; the host's composed unit equals the serve side's
charly/plugin_schema_collision_test.go the precondition test states the per-unit compose, and the base-def twin test reads the base directly
charly/provider_checkenv_schema_gate_test.go the schema-set save/restore renames the field it clears
charly/registry_testsupport_test.go same, for the shared save/restore helper
charly/go.mod github.com/opencharly/spec → v0.2026313.453
charly/go.sum that version's hashes

The six lockstep tools/ modules

The go job's TestContractPinsMatchShared requires every lockstep tools/* module to carry the shared pins.
Bumping spec in charly's own go.mod without them fails that test — caught by CI, not by a local go test ./...,
which never leaves the charly/ module. Fixed with the repo's own charly task mods-tidy, which changed exactly
these six files (spec pin v0.2026313.48 across the lockstep set):

file change
tools/generate-packages/go.mod shared spec pin
tools/generate-packages/go.sum its checksums
tools/golden-cloudinit/go.mod shared spec pin
tools/golden-cloudinit/go.sum its checksums
tools/golden-compile/go.mod shared spec pin
tools/golden-compile/go.sum its checksums

How tested

Code gate, on the committed tree d481eb65609feb27bce4694a7fe95fc5211e937d:

$ go build ./...        rc=0
$ go vet ./...          rc=0
$ go test ./...         rc=0   (ok on github.com/opencharly/charly/charly and .../internal/pluginsgen)
$ golangci-lint run ./...   0 issues   (v2.13.2, the CI pin, under the go.mod toolchain)

The suite includes TestMain, which loads all 63 builtin plugin schemas through the changed
gate — so the whole shipped corpus composes and unifies under the new shape.

The host's own arms:

--- PASS: TestPluginUnitSchemaImportsSpecDefinition
    violating spec.#TunnelConfig -> plugin verb:importunittunnel: plugin_input fails
        #ImportUnitTunnelInput: #ImportUnitTunnelInput.provider: conflicting values 5 and string
        (mismatched types int and string)
--- PASS: TestTwoImportingUnitsComposePerUnit
--- PASS: TestHostAndServeComposeTheSameUnit

R7 — the arms fail without the change. With origin/main's plugin_loader.go restored, the
same source produced the two errors quoted in the Summary (imported but not defined for one
unit; expected label or ':', found 'STRING' for two joined). That measurement is the reason the
joined path cannot simply be given a module.

R9 — the binary is the source. ./scripts/bootstrap-charly.sh built this worktree's
bin/charly (charly version = 2026.313.0209), and the changed path ran live:

$ ./bin/charly box validate
charly box validate: OK — checked 604 candies, 122 boxes, 49 deploys, 7 distros, 7 builders; 0 warnings, 0 errors

R10 — the disposable bed. ./bin/charly check run check-pod-overlay on this tree (a
disposable: true pod bed that builds an overlay image, deploys it, runs its checks, does a
genuine charly update rebuild and re-checks). The first attempt failed on an upstream curl: (22) The requested URL returned error: 504 fetching a release tarball inside the image build — an external condition, RCA'd and evidenced before retrying. The retry's summary:

$ ./bin/charly check run check-pod-overlay
[image-build] PASS after 3m40.43s
[check-image] PASS after 1m8.382s      (steps=..., 3 runtime-context checks correctly not run in box mode)
[deploy-add]  PASS after 6m6.913s
[config]      PASS after 2m41.998s
[start]       PASS after 1m53.294s
[wait-ready]  PASS
[bring-up-members] PASS
[check-live]  PASS after 2m50.266s
[feature-run] PASS after 1m58.984s
[update]      PASS after 12m39.599s     <-- the genuine fresh rebuild
[rebuild-ready] PASS
[check-live-rebuild]   PASS after 2m49.848s
[feature-run-rebuild]  PASS after 1m57.522s
[cleanup] PASS after 40.127s ; [cleanup-members] PASS
charly check run check-pod-overlay: PASS (steps=16, skipped_checks=3)

summary.yml records the same run against the worktree binary:
driver: .../dsh-490/charly/bin/charly, driver_version: 2026.313.0209, every step ok: true.


## Rulebook compliance

- **R0** — the dispatched skills (`go`, `plugin`, `git-workflow`, `strict-policy`) were loaded
  before the first edit, and this repo's `AGENTS.md` first of all.
- **R1** — every gate green on the committed tree. Two anomalies were RCA'd before remediation:
  the upstream 504 in the bed's image build (external, evidenced, then retried once), and the
  quadratic load regression described in the Summary (fixed in this change, with the before/
  after measurement pasted).
- **R2** — ONE implementation of the compose: `spec/schemacompose`, called by both the serve side
  and this gate. Nothing is duplicated in this tree.
- **R3** — no sleep, retry loop, magic value or fallback in the change: a unit that does not
  compose is a hard error naming the plugin; an unservable dependency is a hard error naming the
  module.
- **R4** — N/A — no documented command changes; `charly box validate` and the check beds behave as
  documented, and the live run above is the proof.
- **R5** — the retired shapes are gone: `strings.Join` over unit sources and the per-unit
  `CompileString` are both deleted, and `grep -rn 'served schema does not compile STANDALONE' charly`
  returns nothing (the message it named is retired with it).
- **R6** — git safety: a session worktree branched off `origin/main`, `git status` clean before
  each action, one commit for the change, no force-push, no rebase, no self-merge.
- **R7** — the arms fail without the change and pass with it (pasted above), and the live binary
  exercises the changed path on the whole shipped plugin corpus.
- **R8** — N/A — no live external service is crossed by this change; the module registry in the
  composer is in-process and offline.
- **R9** — the worktree-local CalVer-stamped binary, built by `scripts/bootstrap-charly.sh` from
  this tree, is what ran; no installed binary was used.
- **R10** — the `disposable: true` pod bed above, on the committed tree, including its own fresh
  `charly update` rebuild and check-live pass. No VM bed was run: this host's libvirt is not
  available (`virtqemud` socket absent, `libvirtd` disabled), and a bed that cannot start is
  reported, not silently replaced.

## Change classification

Core plugin-loading behaviour, no user-facing surface change.

- **What changes for a consumer:** nothing to do. Every plugin that served a schema before still
  serves it — proved by the live run over the whole builtin corpus — and a plugin may now import
  the spec schema (opencharly/sdk#491/#492 carry the serve side).
- **What is NOT done here:** a consumer that adds `cue.mod/module.cue` + an import still cannot
  have its Go params generated, because #490's ordered root 3 (the param generator keeps a module)
  is untouched, as the issue scopes. The census rows of opencharly/opencharly#945 stay.
- **Reversing it:** the commit is one file plus tests; moving `require github.com/opencharly/spec`
  back to `v0.2026313.48` and restoring `plugin_loader.go` returns the previous behaviour.

## Filed issues

None.

*Assisted-by: DeepSeek Harness deepseek-v4.1-flash (fully tested and validated)*

aitrawog
feat(plugin): compose each served unit's schema, then unify it onto t…
6e6f415 
…he base

opencharly/sdk#490's second ordered root. The host's plugin schema gate joined every
loaded unit's served text into ONE compilation unit and compiled it onto the base. That
shape cannot carry an import: a plugin that imports github.com/opencharly/spec/schema gets
its import clause copied into a file that already has one, and CUE refuses before
resolution is even attempted ("expected label or ':', found 'STRING'"). It made the
one-unit case refuse the import outright too, because the text compile had no module in
scope.

Each unit is now COMPOSED as its own CUE module instance (spec/schemacompose — the ONE
composer, in the contract module, because this host may import spec and may not import the
sdk, while the serve side may import both) and unified onto the running value. The unit
boundary lands where CUE's own package boundary is: one package per plugin.

The running value is grown one unify per registration instead of being rebuilt from the
base per registration. That is not cosmetic: rebuilding made loading quadratic, and it was
MEASURED here — charly/charly's TestMain, which registers the 63 builtin plugin schemas,
went from 1.4 s to 26.4 s, which in turn pushed a cancellation test past its 10 s bound
(TestConnectPluginReady_HonorsACallerCancellation: the fixture's child process could not
finish its own TestMain and answer the handshake). With one unify per registration TestMain
is 1.1 s and that test passes at 1.45 s.

The declarations the gate reads per source (topLevelDefNames, the charly#770 collision
identity index) are unchanged; the def names now come from the composed unit value, which
carries the same top-level definitions.

Assisted-by: DeepSeek Harness deepseek-v4.1-flash (fully tested and validated)
@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

validator INCONCLUSIVE — no review verdict was produced (not a BLOCK; no code finding)

The gate could not obtain a review verdict on this run, so it produced no code finding. This is not a BLOCK and the PR is not being rejected — but the required check stays RED on purpose: unreviewed code must never merge.

Root cause (measured in this run). vars.CHARLY_VERSION names v2026.308.2259, and the gate could not download that release's assets: the release is published but its assets could not be downloaded (a partial upload). The gate refuses to review with any OTHER engine — the pin exists because the engine's behaviour lives in the binary's welded plugin-review — so no review ran and there is no finding about this diff. Measured live 2026-10-13: opencharly/charly carries 717 tags and 272 releases, so a tag without a published release is reachable by an ordinary pin bump (the class was reproduced on opencharly/sdk#317, where the run ended with no verdict AND no comment).

Durable remedy.

  1. serve the pinned release: gh release view v2026.308.2259 --repo opencharly/charly; if the tag has no release, its build is release-binary.yml (workflow_run on tag-on-merge, or a manual dispatch) — publish it, then re-run this review;
  2. or move the pin: vars.CHARLY_VERSION (or this run's charly-version input) to a tag whose release exists, then re-run. Either way the fix is the operator's, not the author's diff.

Thread policy. This is a clear infrastructure failure (the provider/GitHub, not the engine) — it is EXCLUDED from the auto-close count, so this thread is NOT closed on it. Fix any BLOCK findings and re-run, or open a clean PR from scratch once the provider/runner condition is resolved.

A run that produced no verdict keeps this required check RED: unreviewed code must never merge.

Full diagnostics: this run's evidence artifact + job log (not embedded here — embedding a runaway log would feed it into the next review and deepen the collapse).

3 similar comments
@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

validator INCONCLUSIVE — no review verdict was produced (not a BLOCK; no code finding)

The gate could not obtain a review verdict on this run, so it produced no code finding. This is not a BLOCK and the PR is not being rejected — but the required check stays RED on purpose: unreviewed code must never merge.

Root cause (measured in this run). vars.CHARLY_VERSION names v2026.308.2259, and the gate could not download that release's assets: the release is published but its assets could not be downloaded (a partial upload). The gate refuses to review with any OTHER engine — the pin exists because the engine's behaviour lives in the binary's welded plugin-review — so no review ran and there is no finding about this diff. Measured live 2026-10-13: opencharly/charly carries 717 tags and 272 releases, so a tag without a published release is reachable by an ordinary pin bump (the class was reproduced on opencharly/sdk#317, where the run ended with no verdict AND no comment).

Durable remedy.

  1. serve the pinned release: gh release view v2026.308.2259 --repo opencharly/charly; if the tag has no release, its build is release-binary.yml (workflow_run on tag-on-merge, or a manual dispatch) — publish it, then re-run this review;
  2. or move the pin: vars.CHARLY_VERSION (or this run's charly-version input) to a tag whose release exists, then re-run. Either way the fix is the operator's, not the author's diff.

Thread policy. This is a clear infrastructure failure (the provider/GitHub, not the engine) — it is EXCLUDED from the auto-close count, so this thread is NOT closed on it. Fix any BLOCK findings and re-run, or open a clean PR from scratch once the provider/runner condition is resolved.

A run that produced no verdict keeps this required check RED: unreviewed code must never merge.

Full diagnostics: this run's evidence artifact + job log (not embedded here — embedding a runaway log would feed it into the next review and deepen the collapse).

@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

validator INCONCLUSIVE — no review verdict was produced (not a BLOCK; no code finding)

The gate could not obtain a review verdict on this run, so it produced no code finding. This is not a BLOCK and the PR is not being rejected — but the required check stays RED on purpose: unreviewed code must never merge.

Root cause (measured in this run). vars.CHARLY_VERSION names v2026.308.2259, and the gate could not download that release's assets: the release is published but its assets could not be downloaded (a partial upload). The gate refuses to review with any OTHER engine — the pin exists because the engine's behaviour lives in the binary's welded plugin-review — so no review ran and there is no finding about this diff. Measured live 2026-10-13: opencharly/charly carries 717 tags and 272 releases, so a tag without a published release is reachable by an ordinary pin bump (the class was reproduced on opencharly/sdk#317, where the run ended with no verdict AND no comment).

Durable remedy.

  1. serve the pinned release: gh release view v2026.308.2259 --repo opencharly/charly; if the tag has no release, its build is release-binary.yml (workflow_run on tag-on-merge, or a manual dispatch) — publish it, then re-run this review;
  2. or move the pin: vars.CHARLY_VERSION (or this run's charly-version input) to a tag whose release exists, then re-run. Either way the fix is the operator's, not the author's diff.

Thread policy. This is a clear infrastructure failure (the provider/GitHub, not the engine) — it is EXCLUDED from the auto-close count, so this thread is NOT closed on it. Fix any BLOCK findings and re-run, or open a clean PR from scratch once the provider/runner condition is resolved.

A run that produced no verdict keeps this required check RED: unreviewed code must never merge.

Full diagnostics: this run's evidence artifact + job log (not embedded here — embedding a runaway log would feed it into the next review and deepen the collapse).

@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

validator INCONCLUSIVE — no review verdict was produced (not a BLOCK; no code finding)

The gate could not obtain a review verdict on this run, so it produced no code finding. This is not a BLOCK and the PR is not being rejected — but the required check stays RED on purpose: unreviewed code must never merge.

Root cause (measured in this run). vars.CHARLY_VERSION names v2026.308.2259, and the gate could not download that release's assets: the release is published but its assets could not be downloaded (a partial upload). The gate refuses to review with any OTHER engine — the pin exists because the engine's behaviour lives in the binary's welded plugin-review — so no review ran and there is no finding about this diff. Measured live 2026-10-13: opencharly/charly carries 717 tags and 272 releases, so a tag without a published release is reachable by an ordinary pin bump (the class was reproduced on opencharly/sdk#317, where the run ended with no verdict AND no comment).

Durable remedy.

  1. serve the pinned release: gh release view v2026.308.2259 --repo opencharly/charly; if the tag has no release, its build is release-binary.yml (workflow_run on tag-on-merge, or a manual dispatch) — publish it, then re-run this review;
  2. or move the pin: vars.CHARLY_VERSION (or this run's charly-version input) to a tag whose release exists, then re-run. Either way the fix is the operator's, not the author's diff.

Thread policy. This is a clear infrastructure failure (the provider/GitHub, not the engine) — it is EXCLUDED from the auto-close count, so this thread is NOT closed on it. Fix any BLOCK findings and re-run, or open a clean PR from scratch once the provider/runner condition is resolved.

A run that produced no verdict keeps this required check RED: unreviewed code must never merge.

Full diagnostics: this run's evidence artifact + job log (not embedded here — embedding a runaway log would feed it into the next review and deepen the collapse).

@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

Review — PASS

Head SHA: 8274dc03c5dbf67f6b6337674da14da9410bb40d (branch: feat/plugin-schema-per-unit-compose)

Security screen: PASS (no scope mismatch; version pin bump justified by opencharly/spec#297; no secrets/egress; gate preserved — self-containment becomes "composes on its own", still rejects an undeclared base-def reference; no alias growth; no charly/→sdk import).

Checklist: All applicable rules PASS or NA. Code gate matches the core-plugin-loading class: fresh charly update rebuild in a disposable: true pod bed with pasted per-step output, plus charly box validate (604 candies) exercising the changed path live; arms demonstrably fail on origin/main (imported-but-not-defined / expected label or ':', found 'STRING'). The incremental-unify persistence (pluginSchemas.unified = v) and lazy-base init are consistent with the passing two-unit test; the 504 was an RCA'd upstream condition (retried once, not a load failure), and the quadratic regression was fixed in-tree with before/after measurement. Scope statements (#490 root 3, #945 census rows) reference existing tracking issues, not dismissed failures.

Placement: CORRECT — plugin schema loading stays in core (plugin loading is core); the shared composer correctly lands in spec because the host import-purity gate forbids charly/→sdk, so spec/schemacompose is the only shared home both halves may import.

Comment thread: empty (0 comments) — nothing to disposition.

Verdict: PASS

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

Review — BLOCK

Head SHA: 4a21f1316fd8cb717ba70717a06247fd1f763f10 (branch: feat/plugin-schema-per-unit-compose)

Change class: code/config — core plugin-loading (per-unit compose) plus cross-module spec version pins.

Blocks

  1. A1 — the body's accounting omits 6 of the 13 changed files. The diff includes
    tools/generate-packages/go.mod, tools/generate-packages/go.sum,
    tools/golden-cloudinit/go.mod, tools/golden-cloudinit/go.sum,
    tools/golden-compile/go.mod, tools/golden-compile/go.sum (spec pin v0.2026313.48 →
    v0.2026313.453), added in the final commit 4a21f1316fd8. The ### Files table lists only
    the 7 charly/ files, and the Reversing it line calls the change "one file plus tests".
    A1 requires the summary to account for every file/behavior in the diff; add the three lockstep
    tools/* modules (and their go.mod/go.sum pin bumps) to the Files table. The body's
    How tested claims the gate ran on 4a21f131… (the tools commit), yet the summary it
    accompanies predates those files — a summary/head mismatch.

  2. A1/R10 — no evidence the three tools/* modules build against the new pin. The pasted
    code gate (go build ./..., go test ./...) is scoped to the charly module and never shows
    the three separate tools/* Go modules resolving/building with spec v0.2026313.453. Since
    the final commit changes their go.mod/go.sum, state how each was verified (they are
    independent modules, not covered by the charly ./...). Otherwise the lockstep pin is
    unproven.

Comments considered

  • Comment 6733884203 by @github-actions[bot] (PASS on head 8274dc03c5db) — stale/superseded for the current head 4a21f1316fd8: it reviewed the middle commit and did not see the 6 tools/* files added in the final commit. Its substantive claims (per-unit compose, shared composer in spec/schemacompose given the charly/→sdk import-purity ban, guardrail preserved by rejecting undeclared base-def references) re-derive true against the current diff; its Files/test accounting does not cover the tools/* modules.

Non-blocking notes

  • The bed's first-attempt curl: (22) … 504 on a release tarball is disclosed as "an external condition … before retrying". A 504 from a third-party release URL is a genuine external transient (not a code failure under load), and the retry fully passed at zero warnings, so it is not the forbidden "environmental" dodge — but the body should paste the actual curl/URL evidence it says it captured rather than asserting it.
  • schemacompose is a reusable MECHANISM placed in spec (the wire-shape module) rather than sdk; forced by the charly/→sdk import ban, but worth a rulebook clarification since ARCH routes mechanisms to sdk.

Verdict: BLOCK

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

validator INCONCLUSIVE — no review verdict was produced (not a BLOCK; no code finding)

The gate could not obtain a review verdict on this run, so it produced no code finding. This is not a BLOCK and the PR is not being rejected — but the required check stays RED on purpose: unreviewed code must never merge.

Root cause (measured in this run). vars.CHARLY_VERSION names v2026.308.2259, and the gate could not download that release's assets: the release is published but its assets could not be downloaded (a partial upload). The gate refuses to review with any OTHER engine — the pin exists because the engine's behaviour lives in the binary's welded plugin-review — so no review ran and there is no finding about this diff. Measured live 2026-10-13: opencharly/charly carries 717 tags and 272 releases, so a tag without a published release is reachable by an ordinary pin bump (the class was reproduced on opencharly/sdk#317, where the run ended with no verdict AND no comment).

Durable remedy.

  1. serve the pinned release: gh release view v2026.308.2259 --repo opencharly/charly; if the tag has no release, its build is release-binary.yml (workflow_run on tag-on-merge, or a manual dispatch) — publish it, then re-run this review;
  2. or move the pin: vars.CHARLY_VERSION (or this run's charly-version input) to a tag whose release exists, then re-run. Either way the fix is the operator's, not the author's diff.

Thread policy. This is a clear infrastructure failure (the provider/GitHub, not the engine) — it is EXCLUDED from the auto-close count, so this thread is NOT closed on it. Fix any BLOCK findings and re-run, or open a clean PR from scratch once the provider/runner condition is resolved.

A run that produced no verdict keeps this required check RED: unreviewed code must never merge.

Full diagnostics: this run's evidence artifact + job log (not embedded here — embedding a runaway log would feed it into the next review and deepen the collapse).

@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

Review — PASS

Head SHA: d481eb65609feb27bce4694a7fe95fc5211e937d (branch: feat/plugin-schema-per-unit-compose)

Security screen: PASS — no scope mismatch (all 13 files accounted for); no secrets/egress; guardrail preserved (self-containment becomes "composes on its own", still hard-rejects an undeclared base-def reference, pinned by TestPluginSchemaMustComposeOnItsOwn); no alias growth; charly/→spec import is allowed (the ban is on charly/→sdk).
Checklist: All applicable rules PASS or NA. Code gate matches the core-plugin-loading class: fresh charly update rebuild in a disposable: true pod bed with pasted per-step output plus charly box validate (604 candies) exercising the changed path live; arms demonstrably fail on origin/main; incremental-unify persistence + lazy-base init consistent with the passing two-unit test; quadratic regression fixed in-tree with before/after measurement. Placement: CORRECT — plugin loading stays in core; the shared composer lands in spec because the charly/→sdk import ban leaves spec as the only shared home both halves may import.

Comments considered:

  • 6733884203 (PASS on 8274dc0) — stale-superseded: reviewed an earlier head/7-file scope; its substantive claims (per-unit compose, shared composer, guardrail preserved) re-derive true, but its file accounting is superseded by the current 13-file diff.
  • 6734358278 (BLOCK on 4a21f131) — findings resolved in the current state: (1) the six tools/* files are now in the body's lockstep table (A1); (2) the pin is diff-verifiable — spec's go.mod hash is identical for .48/.453 and the content hash matches charly's building go.sum, so the tools modules resolve; not surviving.

Non-blocking notes: judgeUnitDoc's cross-context Unify (cuecontext.New() vs the unit's context) may make the doc-judging assertion vacuous; the meaningful render-equality assertion still fails without the change, so R7 holds. Pasting the first-attempt curl 504 evidence would fully close the R1 disclosure.

Verdict: PASS

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

@github-actions
github-actions Bot enabled auto-merge (squash) November 9, 2026 10:23
@github-actions
github-actions Bot merged commit 8403fc1 into main Nov 9, 2026
7 of 8 checks passed
charly-auto-merge Bot added a commit that referenced this pull request Nov 9, 2026
@charly-auto-merge
docs: add CHANGELOG 2026.313.1023 for PR #1115
8cc5a79
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@aitrawog