Pin the shipped Piccolo to the vetted 1.19 series by jack-champagne · Pull Request #223 · harmoniqs/amicode

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne · 2026-07-29T00:28:52Z

packages/extension/julia/Project.toml — the environment julia_setup.ts copies to ~/.amico/julia and instantiates — has no [compat] section at all. The shipped Manifest.toml pins Piccolo 1.19.0 by exact tree-sha, which covers a fresh provision, but nothing covers a re-resolve.

Piccolo 1.20.0 released today, and it is deliberately breaking.

Measured, not assumed

Against the real registry, on a copy of the shipped Project.toml + Manifest.toml pair:

	`Pkg.update("Piccolo")`
as shipped today (no compat)	`1.19.0` → `1.20.0`
with `Piccolo = "~1.19"`	holds at `1.19.0`

So one Pkg.update — or any event that makes Pkg re-resolve — silently moves a user onto a Piccolo nobody vetted the shipped content against.

Why 1.20 is not a drop-in

integrator_type = :spline now errors instead of silently returning the piecewise-constant BilinearIntegrator.
fidelity(qcp) became free-phase-aware, so it returns a different number for every free_phase = true problem.
sync_trajectory! now emits a divergence @warn by default, which lands in run-dir output that the extension parses and users read.

Every shipped score and template — including the vetted P(MIS) = 0.9947 figure on the Pasqal golden path — was measured against 1.19.0. Moving minors is a decision to make deliberately, alongside re-vetting, not something a resolver does on someone's machine mid-session.

~1.19 admits 1.19.x patches (non-breaking under SemVer) and refuses 1.20.

Verification

Pkg.instantiate() still resolves Piccolo 1.19.0.
using Piccolo loads.
Manifest.toml is byte-identical afterwards — the bound needs no manifest churn, so this PR is one file.
With the bound in place, Pkg.update("Piccolo") holds at 1.19.0.

Note on convention

packages/schema/julia/Project.toml already carries a [compat] (JSONSchema = "1", julia = "1.10"). The extension env — the one users actually run solves in — was the outlier with none.

Deliberately out of scope

CairoMakie / JLD2 / TOML carry the same class of exposure, but they are third-party, the risk is undemonstrated, and a tight bound on Makie in particular risks resolution failures I could not test tonight. Worth a follow-up bounding them at the minor they are already pinned to.

Raising this to ~1.20 should happen in the same PR that re-vets the templates against the new minor.

`packages/extension/julia/Project.toml` had no [compat] section at all, so the only thing holding the shipped environment at the vetted Piccolo was the Manifest. That is enough for a fresh provision — julia_setup.ts copies both files verbatim and instantiates — but not for anything that re-resolves. Measured against the registry: no compat: Pkg.update("Piccolo") -> 1.19.0 becomes 1.20.0 ~1.19: Pkg.update("Piccolo") -> holds at 1.19.0 Piccolo 1.20.0 was released today and is deliberately breaking: `integrator_type = :spline` now errors instead of silently returning the piecewise-constant integrator, `fidelity(qcp)` became free-phase-aware and returns a different number for every `free_phase = true` problem, and `sync_trajectory!` now warns on optimizer-vs-rollout divergence. Every shipped score and template was vetted against 1.19.0. So the move to 1.20 is a decision to make deliberately, alongside re-vetting the templates, rather than something a resolver does on a user's machine mid-session. `~1.19` admits 1.19.x patches and refuses 1.20. Verified: instantiate still resolves 1.19.0, `using Piccolo` loads, and the Manifest is byte-identical afterwards — no manifest churn. Deliberately not in scope: CairoMakie / JLD2 / TOML carry the same class of exposure but are third-party, undemonstrated, and a tight bound on Makie in particular risks resolution failures I cannot test tonight. Worth a follow-up that bounds them at the minor they are pinned to.

jack-champagne merged commit 5b48949 into mainJul 29, 2026
5 checks passed

This was referenced Aug 22, 2026
fix: un-red main — dead import + app-bundle manifest re-pin (release 0.2.4 blocker) #504
Closed
fix: un-red main — dead import + app-bundle manifest re-pin (#504) #505
Merged