feat(manifest): close sidecar storage set — drop json, validate up front (V-L2-F2)#145
Closed
hyperpolymath wants to merge 1 commit into
Closed
feat(manifest): close sidecar storage set — drop json, validate up front (V-L2-F2)#145hyperpolymath wants to merge 1 commit into
hyperpolymath wants to merge 1 commit into
Conversation
V-L2-F2 (#112): the manifest advertised `[sidecar].storage = sqlite | json` but only sqlite (and the postgres DDL dialect) had code; #45 stopped silently emitting SQLite DDL for a json store and rejected it at generate time with a "tracked by #112" pointer. This resolves that follow-up by *dropping* the JSON store rather than implementing it. Decision rationale (issue's acceptance criterion #1 — implement vs drop): there is no storage-abstraction layer to host a second runtime backend (provenance, temporal, drift, and gc are all SQLite-specific), postgres itself is generate-only, and a JSON store appears in neither the ROADMAP nor the README's envisioned backend set. A parity JSON runtime store would be disproportionate to the codebase and would re-introduce the very "advertised-but-broken" surface this issue exists to remove. Changes: - codegen::overlay::SqlDialect::from_storage — remove the json special case; json now falls through to the generic unsupported-value error (no "coming soon" / #112 pointer). Documented as the single source of truth for the closed storage set. - manifest::validate_manifest — new `sidecar-storage-supported` check reusing from_storage, so validate/doctor/generate agree and an unsupported store is caught up front rather than only at generate. - SidecarConfig docs (manifest + abi), the generate comment, and the manifest template no longer advertise json; the template documents the closed set instead. - gc test now exercises the realistic non-sqlite case (postgres) instead of the removed json value. - tests: json fails validation; postgres passes; from_storage rejects json as unsupported without a #112 pointer. Closes #112. https://claude.ai/code/session_01Ux144vBDdySvLUqUrCgkT4
Owner
Author
|
Closing as a duplicate of #144, which landed on The only material difference this PR had over #144 was two test-only improvements — a positive Generated by Claude Code |
🔍 Hypatia Security ScanFindings: 80 issues detected
View findings[
{
"reason": "Action perpolymath/standards/.github/workflows/governance-reusable.yml@main\n needs attention",
"type": "unpinned_action",
"file": "governance.yml",
"action": "pin_sha",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Action actions/checkout@v4 needs attention",
"type": "unpinned_action",
"file": "rust-ci.yml",
"action": "pin_sha",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Action dtolnay/rust-toolchain@stable needs attention",
"type": "unpinned_action",
"file": "rust-ci.yml",
"action": "pin_sha",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Action Swatinem/rust-cache@v2 needs attention",
"type": "unpinned_action",
"file": "rust-ci.yml",
"action": "pin_sha",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Action actions/checkout@v4 needs attention",
"type": "unpinned_action",
"file": "rust-ci.yml",
"action": "pin_sha",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Action dtolnay/rust-toolchain@master needs attention",
"type": "unpinned_action",
"file": "rust-ci.yml",
"action": "pin_sha",
"rule_module": "workflow_audit",
"severity": "high"
},
{
"reason": "Action Swatinem/rust-cache@v2 needs attention",
"type": "unpinned_action",
"file": "rust-ci.yml",
"action": "pin_sha",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Issue in boj-build.yml",
"type": "missing_timeout_minutes",
"file": "boj-build.yml",
"action": "flag",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Issue in casket-pages.yml",
"type": "missing_timeout_minutes",
"file": "casket-pages.yml",
"action": "flag",
"rule_module": "workflow_audit",
"severity": "medium"
},
{
"reason": "Issue in casket-pages.yml",
"type": "missing_timeout_minutes",
"file": "casket-pages.yml",
"action": "flag",
"rule_module": "workflow_audit",
"severity": "medium"
}
]Powered by Hypatia Neurosymbolic CI/CD Intelligence |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #112.
Decision: drop the JSON sidecar store (not implement)
#112's first acceptance criterion is the decision itself — implement a JSON store vs. drop the option. This PR drops it. Rationale:
gcare all hardwired to SQLite viarusqlite. A JSON store "with the same octad-dimension coverage as the sqlite path" would mean re-encoding every storage-layer invariant SQL gives us for free (closed-enum CHECKs, the partial-unique "one current version" index, self-edge prevention,valid_to >= valid_from) in hand-written Rust.postgresis already generate-only. Even the existing second backend isn't runtime-supported bydrift/gc, so a runtime JSON store would be out of step with the codebase's maturity.jsonis in neither the ROADMAP nor the README's vision. The README describes the envisioned alternative backends assqlite | file | verisim—jsonisn't among them.If a flat-file store is wanted later, it should be designed against a real storage trait and re-added — the code documents this path.
What changed
The supported
[sidecar].storageset is now closed and validated:sqlite(default, full runtime support) andpostgres/postgresql(PostgreSQL DDL dialect forgenerate). Everything else — includingjson— is rejected uniformly and up front, with no "coming soon / #112" promise.codegen::overlay::SqlDialect::from_storagejsonspecial-case arm + its#112pointer;jsonnow falls through to the generic unsupported value error. Documented as the single source of truth for the closed set.manifest::validate_manifestsidecar-storage-supportedcheck (reusesfrom_storage), sovalidate/doctor/generatecan't disagree — an unsupported store fails atvalidatetime, not only atgenerate.SidecarConfig(manifest + abi) docs, thegeneratecomment, and the manifest template no longer advertisejson; the template now documents the closed set.gctestpostgres) rather than the removedjsonvalue.Testing
cargo test— 120 lib unit tests + 21 integration/e2e tests pass (new:unsupported_storage_fails_storage_check,postgres_storage_passes_storage_check; updated:test_storage_to_dialect_mapping,gc_rejects_non_sqlite_backend).cargo fmt --checkclean.cargo clippy --all-targets -- -D warningsclean.Reversibility
No working config depends on
json(it was already rejected atgenerate). Re-adding a real store later is a localized change to thefrom_storagematch. If you'd actually prefer this issue resolved by implementing a JSON backend instead, say so on this draft and I'll switch approach.Generated by Claude Code