Repository navigation
feat: persist provided artefacts and condition facts per model - #46
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@codex security review |
f88ffd4 to
eb90b8e
Compare
|
@codex security review |
eb90b8e to
5c89e09
Compare
|
@codex security review |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
FactRecord is the plain-data shape of what is known from outside a run: artefacts known provided or not, and named facts with their trilean values, each unknown when absent. factsFrom answers the Facts port from it, and layeredFacts lets an earlier port override a later one only where it knows.
Adds facts.read, facts.set and facts.clear to the v1 router and returns the record from models.load, so which artefacts are provided and the values conditions read persist beside the overlay. A facts write takes a revision and is published as a facts change. Saving a model drops facts about artefacts it no longer declares; a fact about an undeclared artefact is rejected as an unknown reference. The fake implements it and the conformance kit covers it, including the reasoning over the stored record.
Adds the artefact_facts and named_facts tables with a committed drizzle-kit migration, and implements facts.read, facts.set and facts.clear over them. Saves, upserts and deletes keep the record consistent in the same transaction as the model's rows, and a facts write takes a revision and publishes a facts change. Facts survive the database file being opened again.
factNamesIn walks a trilean condition and returns the string key of each reference node, so a consumer can offer controls for the facts that decide a transition.
set artefact <id> <provided|absent|unknown> and set fact <name> <value> write the model's fact record in the store, and facts lists it. ready, blocked, impact, path and why read the stored record ahead of the host's facts, so a consumer of an input is ready once it is set provided and a stored fact decides a branch. add activity gains --consumes and --produces so artefacts can be wired from the command line.
and and or are binary in trilean; allOf and anyOf take operand lists.
The workspace reasons over the stored fact record, and the details of the selected element gain buttons that record each artefact it consumes or produces as provided, absent or unknown, and each named fact the conditions around it read as true, false or unknown. The model follows the store, so the statuses update as soon as a change commits.
5c89e09 to
b7e1aea
Compare
|
@codex security review |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
Closes #35
The store now keeps a fact record per model beside the overlay: graph-domain's new
FactRecord, withartefacts(artefact id totrueprovided orfalseknown absent) andvalues(fact name to a trileanComputedValue). Anything the record does not name is unknown, so an artefact has three states and a named fact stays indeterminate until set.factsFrom(record)in graph-domain adapts it to theFactsport, answering string keys as named facts andartefactKey(id)keys fromartefacts;layeredFactsputs the stored record ahead of facts a host injects, andfactNamesInlists the names a condition reads.The v1 store contract gains
facts.read,facts.set(merge by name) andfacts.clear(named entries, or{ all: true }), andmodels.loadreturnsfactsbesideoverlay. A facts write takes a revision and publishes afactschange. Saving a model drops facts about artefacts it no longer declares and keeps named facts; a fact about an undeclared artefact is rejected asunknown-reference; deleting a model drops its facts. The fake and the SQLite store implement it (artefact_factsandnamed_factstables, committed drizzle-kit migration), and the conformance kit covers it, including two subscribers hearing each facts write and the stored record drivingderiveStatuses. The SQLite test checks facts survive reopening the file.The CLI gains
set artefact <id> <provided|absent|unknown>,set fact <name> <value> [--text](true/falsebooleans, a JSON number, otherwise text;unknownclears) andfacts;set <id> <state>is unchanged.ready,blocked,impact,pathandwhyreason over the stored record ahead of the host's facts.add activitygains--consumesand--producesso an input artefact can be wired from the command line at all.showdraws structure only, so facts do not change it.The web app reasons over the stored record, and the details panel gains Provided/Absent/Unknown buttons for each artefact the selected element consumes or produces, and True/False/Unknown buttons for each named fact the conditions around it read; the view's statuses follow through the existing model subscription.
I broke each capability once (domain artefact and named lookups, the fake's merge, save narrowing and clear, the SQLite write and feed, the CLI and web reading the record) and each was caught by the new tests.