Skip to content

[WIP] Create a new release version#9

Closed
huangyiirene with Copilot wants to merge 1 commit into
mainfrom
copilot/create-new-release-version
Closed

[WIP] Create a new release version#9
huangyiirene with Copilot wants to merge 1 commit into
mainfrom
copilot/create-new-release-version

Conversation

Copilot AI commented Jan 18, 2026

Copy link
Copy Markdown
Contributor

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

发一个版本


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Copilot AI requested a review from huangyiirene January 18, 2026 14:59
Copilot stopped work on behalf of huangyiirene due to an error January 18, 2026 14:59
os-zhuang added a commit that referenced this pull request Jun 15, 2026
…ure-function pattern, #1870) (#1926)

Long-term design for flow functions (per the templates evaluation): a flow
`function` is a PURE compute step — inputs → return value — and ALL data I/O
stays declarative on the flow graph. This keeps the data layer visible, governed
(RLS/tenancy/transactions via the engine's data path), and build-checkable
(create/update_record nodes the build already validates) — rather than giving
functions a raw data API that hides writes and bypasses governance. (Data-
lifecycle side effects remain L2 hooks, which legitimately get ctx.api.)

Two enablers:
- `config.outputVariable` exposes the function's return value as a flow variable
  → a later update_record persists it (`fields: { ai_category: '{ai.ai_category}' }`).
- `config.inputs` are now interpolated against live flow variables, so a function
  can consume a prior node's output (`inputs: { ticketId: '{record.id}' }`).

Skill: automation pitfall #9 now teaches the pure-function pattern (function
returns → outputVariable → update_record; hooks for data side effects).
+1 end-to-end test (compute → outputVariable → downstream node interpolates it);
service-automation 202; check:skill-docs passes.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
xuyushun441-sys added a commit that referenced this pull request Jun 23, 2026
…mation) (#2240)

- spec: FieldSchema.requiredPermissions: string[] (passes through Field.* builders).
- plugin-security: a field whose requiredPermissions aren't all held by the caller's
  systemPermissions is masked on read and denied on write (AND-gate, strictest-wins
  over permission-set field grants). getObjectSecurityMeta now reads per-field
  requiredPermissions; foldFieldRequiredPermissions folds unmet ones into the
  FieldMasker map as {readable:false,editable:false}, reusing maskResults +
  detectForbiddenWrites — no masker signature change.
- liveness: classify field.requiredPermissions (live). api-surface unchanged.
- Tests: spec field (+3) + middleware read-mask/write-deny (+4).

D5 (package-seeded admin-maintainable per-object secure defaults) needs no new
code: stack.permissions already seeds sys_permission_set (incl. per-object +
per-field grants), admin-editable in Setup — it composes with D2 (private) + D1
(capability seeding). cloud sys_license is the worked example. Delegated admin (#9)
remains future per the ADR.

Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
os-zhuang added a commit that referenced this pull request Jun 30, 2026
Prime Directive #9 only mandated the `OS_` prefix; the *shape* was
undocumented, so new vars drifted (e.g. a bare `OS_PINYIN_SEARCH` for a
boolean flag). Codify the structure observed across the existing vars:

- `OS_{DOMAIN}_{FEATURE}[_QUALIFIER]` — domain-grouped (AUTH/CORS/SSO/…)
- boolean flags → `_ENABLED` suffix (OS_SSO_ENABLED, OS_SEARCH_PINYIN_ENABLED)
- config values → `OS_{DOMAIN}_{NAME}` (OS_CLOUD_URL, OS_LOG_LEVEL)
- escape hatches → `OS_ALLOW_{X}`; opt-outs → `OS_SKIP_/OS_DISABLE_`
- test-only → `OS_TEST_*`/`OS_EXPECT_*`

Pre-existing non-conforming vars (OS_METADATA_WRITABLE, OS_EAGER_SCHEMAS,
OS_SERVER_TIMING) flagged as debt, not precedent.

Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants