Found while implementing #6743 (PR #6997). Out of that card's scope — #6743's ruling and its pin are scoped to .objectstack/data/, the database — so this is filed separately and unassigned.
Duplicate search: migrate plan / dry-run / FileSystemRepository / .objectstack/metadata over open issues and open PRs — 0 hits (other than #6743 / #6997 themselves).
Observation
#6743 removed the database half of the write side effect: after PR #6997, os migrate plan on a never-started project leaves no .objectstack/data/ at all. The metadata repository half is untouched and still runs — the same command, on the same fresh project, still brings a directory tree into existence:
$ ls -d .objectstack
ls: cannot access '.objectstack': No such file or directory
$ os migrate plan # succeeds, prints the plan
$ find .objectstack -maxdepth 3
.objectstack
.objectstack/metadata
.objectstack/metadata/.objectstack
.objectstack/metadata/.objectstack/.log
Source: MetadataPlugin attaches its FileSystemRepository at repoRoot=<projectRoot>/.objectstack/metadata during the boot that bootSchemaStack performs, and the attach creates the root (the boot log line [MetadataPlugin] FileSystemRepository attached names it).
Why it is the same class as #6743, and why it is nonetheless separate
Same class: a command that declares itself a dry run leaves a write side effect behind, and the existence of .objectstack/ stops being a usable signal for "this project has never been started".
Separate: it is a different subsystem (metadata repository, not the sqlite driver's open mode), the fix would live in MetadataPlugin / the standalone boot rather than in @objectstack/driver-sql, and #6743's ruling — including its "same report, byte for byte" constraint — reasons only about the database. Fixing it inside #6743 would have been scope expansion past a graded card.
Severity as observed
Low, and deliberately filed as an observation rather than a defect: what is left behind is an empty repository skeleton plus an empty .log directory. No user-visible failure has been traced to it. Recording it so the "dry run leaves nothing behind" property is either completed deliberately or closed with a reason, rather than left half-done by accident — #6743 exists precisely because the #3917 deferral looked complete and was not.
Note the boot is genuinely read-only in the sense #3917 established (no DDL, no seed rows); the question is only whether attaching a metadata repository should create its root during a command that will never write metadata.
Related
Found while implementing #6743 (PR #6997). Out of that card's scope — #6743's ruling and its pin are scoped to
.objectstack/data/, the database — so this is filed separately and unassigned.Duplicate search:
migrate plan/ dry-run /FileSystemRepository/.objectstack/metadataover open issues and open PRs — 0 hits (other than #6743 / #6997 themselves).Observation
#6743 removed the database half of the write side effect: after PR #6997,
os migrate planon a never-started project leaves no.objectstack/data/at all. The metadata repository half is untouched and still runs — the same command, on the same fresh project, still brings a directory tree into existence:Source:
MetadataPluginattaches itsFileSystemRepositoryatrepoRoot=<projectRoot>/.objectstack/metadataduring the boot thatbootSchemaStackperforms, and the attach creates the root (the boot log line[MetadataPlugin] FileSystemRepository attachednames it).Why it is the same class as #6743, and why it is nonetheless separate
Same class: a command that declares itself a dry run leaves a write side effect behind, and the existence of
.objectstack/stops being a usable signal for "this project has never been started".Separate: it is a different subsystem (metadata repository, not the sqlite driver's open mode), the fix would live in
MetadataPlugin/ the standalone boot rather than in@objectstack/driver-sql, and #6743's ruling — including its "same report, byte for byte" constraint — reasons only about the database. Fixing it inside #6743 would have been scope expansion past a graded card.Severity as observed
Low, and deliberately filed as an observation rather than a defect: what is left behind is an empty repository skeleton plus an empty
.logdirectory. No user-visible failure has been traced to it. Recording it so the "dry run leaves nothing behind" property is either completed deliberately or closed with a reason, rather than left half-done by accident — #6743 exists precisely because the #3917 deferral looked complete and was not.Note the boot is genuinely read-only in the sense #3917 established (no DDL, no seed rows); the question is only whether attaching a metadata repository should create its root during a command that will never write metadata.
Related
os migrate plan自称 dry-run,却仍会在全新项目上创建空数据库文件(#6469 的残余写副作用) #6743 / PR fix(cli,driver-sql):os migrate planstops creating a database on a fresh project (#6743) #6997 — the database half, fixed