Repository navigation
docs(adr): ADR-0072 — reference scope & resolvability (the data-picker model) (objectui#1934) - #2306
Merged
Merged
Conversation
…r model) (objectui#1934) Capture the model behind the flow data-picker (objectui #1973–#1981) and the contract for extending it across the ~50 authored-expression surfaces. Filed in the framework repo alongside the expression-layer ADRs (0032, 0058) because the invariant is grounded in framework engine + spec semantics; the UI lives in objectui. 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 (service-automation engine.ts:946-964); - validation reuses the engine's canonical CEL scope roots (formula cel-engine.ts:52-62). Builds on ADR-0032 / ADR-0058. Per-surface evaluation-scope evidence 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.
|
os-zhuang
added a commit
that referenced
this pull request
Jul 6, 2026
feat(app-shell): embed the build-agent copilot in Studio's aiSlot (ADR-0080 slice-1) (#2306) objectui@883ec287e63a820ea5c49069226747d429c9a9a5
This branch was successfully deployed
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.
Status: Proposed — for architect review (do not auto-merge).
Filed here (with the expression-layer ADRs 0032 / 0058) because the decision is grounded in framework engine + spec semantics. The implementation surface — the flow variable data-picker — lives in objectui (#1973 → #1981, already shipped as Slice 0/1).
Written after a research sweep of this repo's engine, prompted by the objectui #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. Per-surface scope, drillable object outputs, the relational story, and validation all follow from that invariant.
Why an ADR (not just an objectui PR)
service-automation), the spec (FlowNode.outputSchema), and the designer (objectui).record.account.namemust NOT be offered — the engine injects the raw trigger record and never expands lookups (packages/services/service-automation/src/engine.ts:946-964), so a lookup dot-walk resolves toundefined. Without writing this down, the next contributor re-introduces the footgun.record.xonly). Per-surface evidence table is in the ADR.Key decisions
D1 resolvability invariant · D2 per-surface graph-aware scope + surface-specific token shape · D3 lazy one-level drilling of object outputs (from
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 evolveFlowNode.outputSchemawithobjectName(spec change in this repo) · D7 degrade gracefully.Review asks
outputSchema.objectNameis a@objectstack/specchange owned here; needs sign-off + a populating change in the CRUD executors.Docs-only; no changeset.
🤖 Generated with Claude Code