Skip to content

write down the app-vs-platform boundary: which work belongs in a metadata app and which is a platform gap — into AGENTS.md, and evaluate whether the published skills should carry it too #15420

Description

@hotlong

Maintainer-requested, 2026-09-04, verbatim: 「原则应该写入 本项目agent 记忆。哪些应该在元数据应用中开发,哪些应该完善平台能力。」 and 「包括评估是否应该更新objectstac官方skills」.

Why now

The boundary has been decided ad hoc, several times, by different seats, on the same day — and each time from scratch. Three worked rulings from 2026-09-04, all with measurements behind them:

Nothing in AGENTS.md, CLAUDE.md or skills/** states the rule. So every seat re-derives it, and the re-derivations differ.

The rule to write down

Not new policy — the rule those three rulings already followed, stated once so it stops being re-derived.

The question that decides it: could this be written by something that has only the metadata, and no knowledge of this company?

belongs in examples measured on hotcrm
No — it encodes a company's own judgement the metadata app a discount ceiling, who a case is assigned to, how won/lost is booked; the company's own objects, views, flows
Yes — it only asks whether the metadata is self-consistent the platform reference integrity, translation coverage, view rosters, sharing-rule coverage, CRUD round-trips, RLS probes per declared position
the subject is platform behaviour, the cost lands on the app the platform, and it is a gap until it does asserting what a hook does inside the platform's own sandbox (#15325)

Second question, for a capability an app wants published: if a second app needed this, would it copy the implementation? Yes ⇒ platform. That is the #15261 test, and it is why one consumer defers rather than publishes: one consumer is a use, two is a contract.

Two anti-patterns, both measured today, both worth naming

Where it goes

1. AGENTS.md. The source of truth this repo's agents read.

⚠️ Two hazards, both real:

2. CLAUDE.md gets the condensed mirror only if the rule meets that file's own stated bar ("the rules that must never be missed, because missing one wastes or corrupts other agents' work"). Argue it either way — ⛔ do not assume it qualifies.

3. The published skills/ — evaluate, do not assume. There are 11 published skills (objectstack-ai, api, automation, data, formula, i18n, platform, pm-dispatch, query, ui, upgrade). This rule is aimed at someone building an app on the platform, which is exactly that audience.

Read them and answer, with reasons:

  • Does one of them already own this question? objectstack-platform and objectstack-upgrade are the obvious candidates by name — check, don't assume.
  • Is the app-facing half ("before you hand-write it, ask whether the platform should derive it") a fit for a published skill, or is it internal contributor guidance that would just be noise to a customer?
  • ⛔ If the answer is "no published skill should carry this", say so and why — that is a perfectly good outcome and better than a paragraph nobody reads.

Acceptance

  • The rule stated once, in prose an agent can apply without a worked example — the deciding question, the second question for publication, and the two anti-patterns.
  • Every claim traceable: cite the ruling or the measurement, ⛔ never "as a rule we prefer…".
  • check:pm-skill-ratchet green, with the line count read out.
  • A stated verdict on CLAUDE.md and on each candidate published skill, including the "no" verdicts.
  • ⛔ No other edits to AGENTS.md. ⛔ Do not tidy neighbouring sections.

⛔ Not in this card

⛔ Do not change any code, any test, or os verify. ⛔ Do not act on #15418's audit — it is running in parallel and its numbers are its own deliverable. This card writes the rule; that card measures the debt.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions