docs(adr): ADR-0072 — reference scope & resolvability (the data-picker model) (#1934)#1985
Closed
os-zhuang wants to merge 1 commit into
Closed
docs(adr): ADR-0072 — reference scope & resolvability (the data-picker model) (#1934)#1985os-zhuang wants to merge 1 commit into
os-zhuang wants to merge 1 commit into
Conversation
…r model) (#1934) Capture the model behind the flow data-picker (#1973–#1981) and the contract for extending it. Core invariant: the picker + its inline validator surface only references that actually RESOLVE at runtime. From that: - scope is per-surface + graph-aware, and the inserted token follows the surface (flow flattens the record so bare `status` is valid; elsewhere it is `record.status`; templates use `{var}`); - object-typed references are drillable one level, lazily, from the producing node's object (`config.objectName` now, `outputSchema.objectName` long-term); - relationships are a guided "add a Get Records step" fetch, NEVER a lookup dot-walk — `record.account.name` never resolves because the engine injects the raw record and does not expand lookups (engine.ts:946-964); - validation reuses the engine's canonical CEL scope roots (cel-engine.ts:52-62). Builds on ADR-0032 (unified expression layer) / ADR-0058 (expression & predicate surface). Research evidence (engine record-seeding, per-surface eval scopes, current `outputSchema` shape) cited inline. Status: Proposed — for architect review (esp. D4 lookup stance, D6 outputSchema.objectName spec change). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
github-actions
Bot
added
the
documentation
Contributor
Author
|
Moving ADR-0072 to the framework repo, alongside the expression-layer ADRs 0032/0058 (the decision is grounded in framework engine + spec semantics). New PR: objectstack-ai/framework#2306 |
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
1 participant
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.
Status: Proposed — for architect review (do not auto-merge).
Drafts the architecture decision behind the flow variable data-picker (#1973 → #1981) and the contract for extending it across the ~50 authored-expression surfaces. Written after a research sweep of the framework engine, prompted by the #1934 follow-up ask "expand
record.account.name" — which the investigation showed would be a footgun.The decision in one line
The picker + its inline validator surface only references that actually resolve at runtime. Everything else (per-surface scope, drillable object outputs, the relational story, validation) follows from that invariant.
Why it needed an ADR (not another PR)
service-automation), the designer (objectui), and the spec (FlowNode.outputSchema).record.account.namemust NOT be offered — the engine injects the raw trigger record and never expands lookups (engine.ts:946-964), so a lookup dot-walk resolves toundefined. Without writing this down, the next contributor re-introduces the footgun (I nearly did).record.xonly). See the per-surface evidence table in the ADR.Key decisions
config.objectName) · D4 relationships = guided "add Get Records", never lookup dot-walk · D5 validator reuses the engine's canonical CEL roots (cel-engine.ts:52-62) · D6 evolveoutputSchemawithobjectName(spec change) · D7 degrade gracefully.Review asks
outputSchema.objectName) — this is a@objectstack/specchange; needs framework coordination.objectui/docs/adr(picker code lives here); move to the framework repo if architects prefer the expression-layer ADRs stay co-located with 0032/0058.Docs-only; no changeset (the changeset check validates the fixed-group config, not per-PR changesets).
🤖 Generated with Claude Code