1. 0.2.0 — planned
These notes describe the intended 0.2.0 release line relative to
v0.1.0b6, the latest beta tag at the time this draft was written.
0.2.0 is still early-stage, pre-1.0 software. The release is not a promise
of long-term API or YAML stability. If cut from this line, however, it is no
longer positioned as a pure beta prototype: the core architecture, public
documentation entry points, and release process are now stable enough for
careful early adopters who are willing to follow the documented migration
notes.
1.1. Highlights
-
Repeated export/reimport/promote cycles are stable: the orchestrator now projects the runtime
_metaonto a persistable contract before any backend writes, so runtime-produced FK-helper v2 relations no longer leak into persisted sidecars and replay as stale policy on the next run. This closes theFrame 'groups' must have flat columnsfailure that the worldbuilding adoption surfaced. The boundary is intentionally narrow and post-pipeline: it prevents new contamination on every successful run, but a_meta.yamlalready promoted from a pre-fix run may still need a one-time cleanup of itshelper_policies.fk.relationsentries before the next export can succeed. A complete_metalifecycle inventory and load-time sanitizer are deferred to post-release follow-ups (FTR-FK-HELPER-POLICY-LIFECYCLE-P4A,FTR-META-LIFECYCLE-INVENTORY-P5). -
ODS reimport is robust against sheet-wide formatting fillers. Workbooks edited with whole-sheet selections (e.g. Ctrl+A + format change in LibreOffice Calc) no longer trigger uncontrolled allocation in the ODS parser, and a typed
SpreadsheetTooLargeErrorsurfaces before unbounded growth when an input declares implausible dimensions. -
FK-helper behavior has moved from convention-driven primitive inference to explicit relation policy. Pipelines should now configure or infer FK relation policy before running FK-helper primitives.
-
Public documentation entry points were clarified: the README, Pages root, release notes, user guide, and demo walkthrough paths now form an intent-based user journey rather than a collection of repository paths.
-
Release-readiness tooling was tightened with read-only checks for release branch state, README link versioning, Pages publication structure, and cross-repo release status.
-
The semantic model documentation now gives maintainers and agents a shared vocabulary for metadata meaning, lifecycle state, registry authority, and FK-helper contract review.
1.2. User-facing changes
-
Ctrl+Cduringsheets-runnow exits cleanly withInterrupted by user.on stderr and a non-zero exit code (130, the POSIX SIGINT convention), in place of a raw Python traceback.--debugor-vvstill shows the full traceback for debugging. The installed entry point is now routed through the existingrun_cliwrapper, so the previously silentError: …short-message path also reaches real users; reinstall withmake setuporpip install -e .to regenerate.venv/bin/sheets-run. -
The core README now directs readers to the maintained demo, the latest user guide, and the version archive with clearer intent labels.
-
The Pages root now acts as a version archive with links to core release notes, the user guide, and the maintained demo walkthrough.
-
Release-bound README links are guarded so PyPI and other frozen release contexts use
/versions/<tag>/…documentation links instead of drifting to/latest/…. -
The user-guide transformation catalog was updated for the current FK-helper model, including the
infer_fk_relationsconfiguration step and policy-driven FK-helper primitives. -
Canonical workbook reimport pipelines that declare helper cleanup now remove visible FK helper columns again after the persistence boundary strips transient
_meta.derivedprovenance.
1.3. Transformation and pipeline changes
-
Added
infer_fk_relationsas an explicit configuration step. It can inspect current frames using a bounded naming-convention mode and write resolved FK relation policy to_meta.helper_policies.fk. -
configure_fk_helpersremains the explicit/manual FK policy path.targets: "auto"was removed from this step; useinfer_fk_relationswhen heuristic relation discovery is wanted. -
FK-helper primitives now consume v2 relation policy under
_meta.helper_policies.fk(schema_version: 2) instead of inferring relation identity from frame, table, or column names. -
add_fk_helperswrites derived helper provenance that includestarget_key, so later validation and cleanup can use the declared target primary-key column. -
remove_fk_helpers,reorder_fk_helpers, and FK-helper validation now use policy and/or derived provenance. Missing required policy or provenance is a clear error rather than a silent prefix-based fallback. -
apply_derived_column_policy … policy: dropnow falls back to durable workbook-view helper metadata (_meta.sheets.<frame>.helper_columns) when transient_meta.derived.sheets.<frame>.helper_columnsis absent after a fresh workbook reimport. -
validate_referencesgained ano_helper_columnsassertion rule. Use it after cleanup in reimport pipelines to report helper columns that would otherwise reach canonical output.
1.4. Spreadsheet backends and roundtrip behavior
-
The FK column wire format, such as
id_(<target>), remains valid for spreadsheet roundtrips. The change is where relation meaning is resolved: configuration steps may use the convention, but primitive FK-helper steps do not infer relation identity from it. -
No broad new spreadsheet backend capability is introduced in this release draft. XLSX remains the primary spreadsheet backend, and ODS/Calc remains the second backend used to prove the spreadsheet contract.
-
Roundtrip-sensitive helper behavior is now more explicit because helper cleanup and validation rely on declared policy/provenance rather than hidden name-pattern recovery.
-
The orchestrator now owns a narrow persistence boundary that projects runtime
metaonto a carrier-neutral persistable contract before save. Top-levelderivedand_*-prefixed keys are dropped, and FK-helper v2 relation entries underhelper_policies.fk.relationsare removed when theirproduced_by.stepisconfigure_fk_helpers. The boundary applies to every output kind (JSON/YAML/XML/CSV directories and XLSX/ODS); the projection is the same for all carriers, with spreadsheet backends layering rendering on top. Thepipeline.runner.run_appentry point is a thin adapter overorchestrateand inherits the same boundary, so there is exactly one load/step/save path in the project. Seedocs/semantic_model/08_lifecycle_and_update_semantics.adocfor the boundary contract, the post-pipeline / write-side scope, and the explicitly deferred follow-ups (FTR-FK-HELPER-POLICY-LIFECYCLE-P4A,FTR-META-LIFECYCLE-INVENTORY-P5). -
The ODS parser no longer materializes empty cells declared via
number-columns-repeated/number-rows-repeated. This neutralizes the common LibreOffice "select all + apply style" carrier pattern, which previously expanded a single empty styled cell into millions of dict entries and could exhaust process memory on real-world inputs. -
parse_workbookaccepts a new keyword argumentlimits=ParserLimits(…)for defense-in-depth caps on parsed rows, columns, and materialized cells. Exceeding a limit raises the typedSpreadsheetTooLargeError(re-exported fromspreadsheet_handling.io_backends.parser_limits) instead of a rawMemoryError. Defaults align with the spreadsheet maxima (1,048,576 rows × 16,384 columns) with a 10,000,000 cell ceiling per sheet.
1.5. Documentation and demo
-
Public documentation entry points were realigned around the README, Pages root, user guide, release notes, and demo walkthroughs.
-
The maintained demo/tutorial path was realigned with explicit FK-helper policy semantics.
-
The semantic model documentation was added under
docs/semantic_model/, including the problem statement, semantic sets and lifecycle model, registry role, adoption strategy, and FK-helper contract matrix. -
The project evolution narrative was updated so future maintainers and agents can understand the release, FK-helper, registry, and semantic-model phases without reading every historical FTR.
1.6. Migration notes
-
Pipelines that relied on
configure_fk_helperswithtargets: "auto"must switch to an explicitinfer_fk_relationsstep before FK-helper primitives, or provide explicit/manual relation policy throughconfigure_fk_helpers. -
Pipelines that previously expected
add_fk_helpersto discover FK relations implicitly from column names must run a configuration step first. -
Pipelines that relied on prefix fallback during
remove_fk_helpersshould preserve the derived helper provenance written byadd_fk_helpersor provide explicit policy. Recovery from externally edited workbooks without provenance is not part of the normal primitive behavior. -
FK relation policy now uses the v2 relation-oriented shape under the existing
_meta.helper_policies.fkroot. The relation shape includesschema_version: 2,relations,source_frame,source_column,target_frame, mandatorytarget_key, helper fields/columns, andproduced_bymetadata. -
The old
id_(<target>)FK column convention is not removed. It is still the cell-level wire format and may be used byinfer_fk_relations; it is no longer the hidden authority inside primitive FK-helper execution.
1.7. Internal architecture and maintainability
-
Registry contract lifecycle guidance now distinguishes current state, target state, and transition bridges so registry entries can describe migrations without overstating runtime truth.
-
Registry artifacts were relocated to root-level
registries/paths while documentation keeps the reviewed registry contract context. -
Release tooling now includes read-only helpers for release branch validation, Pages publication checks, cross-repo release status, and README link versioning.
-
GitHub Actions workflow permissions were tightened to minimal defaults with job-level overrides where required.
-
The FK-helper semantic contract matrix and guards reduce the chance that future refactors reintroduce primitive inference or stale registry wording.
1.8. Known limitations
-
0.2.0remains pre-1.0. Public behavior is more coherent than the beta prototype line, but compatibility promises are intentionally limited. -
Historical beta-by-beta release notes are not reconstructed here. This page focuses on changes since
v0.1.0b6. -
Some semantic-model adoption work is intentionally documentation-first. Future transformation families still need their own adoption slices.
-
REVIEW-002 residual maintainability items remain tracked outside these release notes. They are not treated as release blockers unless later review promotes them to 0.2.0 scope.
-
The FK-helper policy model does not yet claim to cover composite keys, generic relation modeling, or every possible recovery flow for externally edited workbooks.