feat: 收录应用开发发布技能与双语示例 (#214)

## 中文

新增按需调用的内置技能 `app-developer`(应用开发与发布):中英正文、sidecar、MIT 许可、静态与服务两个通用工作台示例,以及作者接口与分发参考,并登记进 `builtin-skills.json`。作者管理优先使用 AppManage 的有限动作,执行前须通过 `authoring_capabilities` 确认 `app-authoring-v1`,能力不可用时停止受影响的操作;外部 Node/Docker 运行时、托管、Git 服务与数据库的条款和可能费用已在发现文案、compatibility 与正文披露。另将 dev-environment-setup 探测参考中的三处用户 home 示例改为通用路径。

与 #220、#212 合入后的 main 解决 manifest 冲突:技能总数 144,市场版本 1.5.13。验证:catalog 与 i18n 校验 0 errors / 106 warnings(含新技能尚未 ref-bound review 的治理提醒),translate --check 与 git diff --check 通过;远端 validate、translate、CodeQL 通过。Copilot 因额度用尽未能审查。

## English

Add the on-demand builtin `app-developer` skill (application development and publishing): English/Chinese bodies, sidecar, MIT license, static and service workbench examples, plus authoring-interface and distribution references, registered in `builtin-skills.json`. Authoring prefers AppManage's finite actions and must confirm `app-authoring-v1` through `authoring_capabilities` first, stopping affected operations when the capability is unavailable. External Node/Docker runtime, hosting, Git service and database terms and possible costs are disclosed. Three user-home examples in the dev-environment-setup probe reference are neutralized.

The manifest conflict with main after #220 and #212 is resolved: 144 skills, market version 1.5.13. Catalog and i18n validation report 0 errors with 106 warnings (including the new skill's pending ref-bound review notice); translate --check and git diff --check pass; remote validate, translate and CodeQL passed. Copilot could not review because of its quota limit.
This commit is contained in:
2026-10-18 17:53:37 +08:00
committed by GitHub
parent 1da7a32ae1
commit a514b55b68
30 changed files with 1308 additions and 5 deletions

View File

@@ -0,0 +1,108 @@
---
{
"name": "app-developer",
"description": "用户要求开发、修改或发布自己的工作台应用,或把固定应用版本分发到 GitHub/Gitea 与 Registry 时使用。按所选技术栈使用的外部 Node/Docker 运行时、托管、Git 服务和数据库须有真实环境或连接及适用条款,可能另行部署或收费;缺能力时说明原因。",
"license": "MIT",
"compatibility": "Requires DesireCore app-authoring-v1 capability handshake. Depending on the chosen stack, Node/Docker runtimes, hosting, GitHub/Gitea and databases require actual authorized environments or connections and applicable licensing/deployment terms; separate costs may apply. Unavailable capabilities stop the affected operation.",
"version": "1.0.0",
"requiredClientVersion": "10.0.180",
"type": "procedural",
"risk_level": "high",
"status": "enabled",
"disable-model-invocation": true,
"provides": {
"tools": [
"AppManage"
]
},
"tags": [
"application",
"workbench",
"development",
"publishing"
],
"metadata": {
"author": "desirecore",
"updated_at": "2026-10-13",
"i18n": {
"default_locale": "en-US",
"source_locale": "zh-CN",
"locales": [
"zh-CN",
"en-US"
],
"zh-CN": {
"name": "应用开发与发布",
"short_desc": "开发个人工作台并发布到我的应用,按需分发固定版本",
"description": "用户要求开发、修改或发布自己的工作台应用,或把固定应用版本分发到 GitHub/Gitea 与 Registry 时使用。按所选技术栈使用的外部 Node/Docker 运行时、托管、Git 服务和数据库须有真实环境或连接及适用条款,可能另行部署或收费;缺能力时说明原因。",
"body": "./SKILL.zh-CN.md",
"source_hash": "sha256:b12f9f3a566f3195",
"translated_by": "ai:gpt-6",
"translated_at": "2026-10-13"
},
"en-US": {
"name": "Application Development and Publishing",
"short_desc": "Develop a personal workbench, publish it to My Apps, and distribute fixed releases on request",
"description": "Use when the user asks to develop, modify or publish a personal workbench application, or distribute a fixed release through GitHub/Gitea and Registry. Node/Docker runtimes, hosting, Git services and databases used by the chosen stack need actual environments or connections and applicable terms; separate deployment or costs may apply. Report unavailable capabilities.",
"body": "./SKILL.md",
"source_hash": "sha256:b12f9f3a566f3195",
"translated_by": "ai:gpt-6",
"translated_at": "2026-10-13"
}
}
},
"market": {
"icon": "<svg xmlns=\"http://www.w3.org/2000/svg\" width=\"24\" height=\"24\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"white\" stroke-width=\"1.6\"><rect x=\"3\" y=\"3\" width=\"18\" height=\"18\" rx=\"3\"/><path d=\"M3 8h18M8 8v13M12 13h5M12 17h5\"/></svg>",
"category": "development",
"maintainer": {
"name": "DesireCore Official",
"verified": true
},
"channel": "latest"
}
}
---
# Application Development and Publishing
## L0: Responsibility
The Agent chooses the implementation, framework and working method. The platform verifies material identity, scope, publication, runtime and collaboration facts. Reuse file and execution tools, Task/Run and the existing installation writer. Do not create a fixed business workflow or execute commands extracted from installation prose.
## L1: Read Capabilities and Context
1. Read or create the task's single file-based Plan, preserving the actual Agent/session, device, authorized work directory and development Task. Continue within the user's existing requirements and authorization.
2. Use the original `AppManage` action `authoring_capabilities`. Require `capabilities.protocol: app-authoring-v1` and inspect supported, authorized, available and reason independently. Its `fileRoots` are real readable roots for the current Agent, and `registryTargetIds` are registered catalog targets. These read facts grant neither upload nor filesystem write authority. The minimum version is a code baseline, not proof that a shipped client supports this protocol. Authoring actions enter the original domain owners without passing platform credentials to the model.
3. Natural-language development needs no additional handoff protocol. Installation, registration, update or uninstall continues through ApplicationManagement-v2 and the single writer. Read `app-install-manager` when available; never edit installed-entries.json directly.
4. Read [authoring interfaces](references/authoring-api.zh-CN.md) and [distribution](references/distribution.zh-CN.md) on demand. The candidate main-repository authority is `docs/功能/市场系统/API/应用开发发布接口.md`; an external PR does not establish a shipped client or official seed. `examples/static-workbench/` and `examples/service-workbench/` are editable teaching materials, not evidence of autonomous Agent development or production acceptance.
## L2: Development, Preview and Personal Publication
- Establish the user's actual work, data ownership and collaboration needs. Choose suitable languages and frameworks; examples do not prescribe a stack. Reuse the actual Task, Plan and originating context.
- Separate program material, business data and secrets. The portable `application.json` contains no sourceId, installation identity, host path, builtin route or credential. Its product identity, version and entrypoints are the single source for release and catalog views.
- Create fixed `app-release.json` from an explicit file whitelist, actual byte hashes, entrypoint mappings, data contract and truthful platform evidence. Exclude the manifest itself from files. `scripts/create-release.mjs` builds the example manifest; the service independently verifies actual bytes.
- Deliver `app-draft.json` with real fileRef, Plan, Agent/session, stable draftId and target installationId. Its workdir points to the actual release material directory; do not guess a release/ subdirectory or fabricate a fileRef. Read the actual authorized file using `AppManage.read_draft` with `file_ref`, preserving the returned draft. Return a clickable absolute path so the user can read and continue it in the application development workspace.
- Call `AppManage.preview_prepare` with the original draft/mode/expectedRevision in `owner_request`, including release for snapshot. Use preview_read to read and preview_end to end it. Snapshot preview and formal installation use separate identities and data. Freeze a snapshot before publishing a live preview. Replacement uses the actual revision. Ending preview revokes its bridge and disposes only its owned temporary runtime while preserving data and development material. Closing a page does not stop a formal application or accepted Task. Never convert a temporary URL/token into a formal entrypoint.
- Enroll a real authorized source development server using `AppManage.development_enroll` with the original prepareRef/draft/terminalId/endpoint in `owner_request` for live preview. Its development-only contract cannot become formal startup; mutable source and fixed releases remain separate. The original command must respect owner-injected PORT and APP_DATA_DIR, using shell `${VAR:-default}` only for initial defaults rather than overriding preview ports or formal data roots.
- Use `AppManage.prepare_release` with the complete `release_request` to freeze real material. Construct materialRoot as a FileResourceRef from the returned readable roots. Inspect the candidate, then call commit_release with the complete original AppReleaseCommitRequest in `release_request`, retaining prepareRef, installationId, expectedRevision and submissionId. Do not reduce its installation material to a name or digest. Continue authorized publication without repeated per-command questions; new targets or additional data/external effects follow existing governance.
- Saving a release and making it runnable are separate facts. Static files use fixed mappings; services use `AppManage.runtime_enroll` to bind original-owner spawn, generation and handshake. Use runtime_read/start/stop for formal operation; startupPolicy is not permanent execution authority. Docker releases declare complete registry/repository@sha256 imageRefs, then use `AppManage.docker_prepare` to receive owned CID/env paths and the actual command. Execute it through original TaskHost approval, then use docker_enroll with the original enrollmentRef/terminalId and verify daemon/CID/RepoDigest/mount/port facts. Normal create/start/stop repeats current approval; internal transient preview disposal compensates only its originally approved owned CID; candidate, formal and preview roots/nonces differ. Reconcile unknown outcomes against the original CID before another effect. Missing adapters or supported environments keep the original Agent-managed lifecycle with an honest reason. A CLI exit, format check, port, PID or historical observation does not prove availability.
- For timeout, lost response or disconnection, preserve the original mutation/submission/clientRequest ID and body. Query publication using `AppManage.lookup_release_submission` with the original installation_id/submission_id, and read actual runtime/preview state separately. Do not blindly replay unknown writes with a new ID. Check current material and data compatibility before an update. Investigate interrupted migrations; code rollback is not data recovery.
## L3: Webpage and Agent Collaboration
The webpage uses the finite `window.desirecoreApp.call(method,payload)` and `onEvent` API; Web uses a MessagePort from an independent origin. There is no Conveyor, arbitrary invoke, platform administrator token, arbitrary file proxy or general fetch tool. Disable unavailable or unauthorized actions with the actual reason.
- Formal `connect.application` supplies only the application's source/app/instance prefix. Object namespace, ID and revision need an actual owner. The examples reference the declared notes source file with namespace data-files, objectId notes and the actual readData ETag; they do not invent an owner for individual JSON note objects. The selected note's ID, record version and visible fields remain in the summary. Preview discusses the summary without borrowing a formal instance identity.
- Persist only declared data keys through readData/saveData with expectedAbsent or expectedETag. Recover unknown writes using the original mutationId. A native backend needs a separately authorized data root and must not write business databases into a fixed release directory.
- Publish selections if needed and call prepareWork to propose work. The platform owns final acceptance: native uses real input proof and one-use intent, while Web uses the original trusted chat admission transport. A webpage cannot sign native physical input proof. A proposalRef is not a Task receipt. Only actual reserved/committed work-accepted results establish acceptance; queued does not mean completed.
- Reconnect and lookup preserve the original `{agentId,clientRequestId}`. A reset_required gap needs a fresh snapshot and valid cursor. controlWork uses only actual availableActions, currently abort, without general resume. readWork.resources contains original Task-owned task-binding locators; `openResource({locator})` returning navigation-requested requests platform navigation and does not prove file content loaded. data-files objects use exact authorized references in a read-only inspector. Never fabricate FileRefs/URLs or treat unsupported navigate as a grant.
- Business content stays with its data owner. View state defaults to memory. Device persistence needs an explicit user choice, a declared viewStateContract with finite keys/bytes/format, and saveViewState permission. connect returns actual device readiness and per-key revisions. Keep the original mutationId, expectedRevision and body for unknown CAS writes. Store necessary filter/selection/position only, without business content or credentials.
- Web hosting needs owner-configured TLS, domain, DNS and actual public port. The trusted shell obtains its ticket and explicitly requests SDK bootstrap. Missing host/SDK configuration remains unavailable; never disable TLS verification or allow an application-selected upstream URL/management port.
## L4: Distribution and Evidence
Personal publication is private and local by default. When the user requests distribution, call `AppManage.export_release` with the fixed complete whitelist in `owner_request`, and review the exact files and actual target. Exclude databases, .env, credentials, chats, Task/Plan, logs, machine paths and installation identity. Environment templates can describe names without real secret values.
To deliver ZIP bytes to an upload tool, also pass top-level `export_file_ref`, a destination FileResourceRef under the original tool's actual write authority, with exactly one of `expected_absent:true` or the original `expected_etag`. The returned `archiveFile` contains the actual fileRef/sha256/size/etag/replayed. Verify sha256 equals archiveDigest before handing the file to an already authorized GitHub/Gitea upload tool and inspecting immutable source/artifact results. For a lost response, preserve the same destination, condition and complete body; never overwrite an unknown file. Readable fileRoots do not grant write authority. Then call `AppManage.distribution_prepare` with `owner_request` containing the same exportRef, a registryTargetIds target, the actual immutable source and metadata to generate Registry manifest.json, catalog-metadata.v1.json and install.md. The draft is still neither uploaded nor submitted; report missing targets and upload channels separately. Ordinary HttpRequest does not automatically inject platform credentials; never extract instance tokens or change Origin to bypass 401. The target Provider injects catalog identity; the personal installation remains unchanged. Verify archiveDigest, releaseDigest and source-materialized descriptorDigest independently. A different payload under the same version requires a new revision, not overwriting fixed material.
Report code/functional verification, preview, personal saving, runtime availability, upload, catalog PR/admission and second-user installation independently. A candidate 4.3 Schema, external PR or generated ZIP does not establish official-market availability, client capability release or another device's runtime acceptance. External hosting, databases and Git services require actual connections and applicable licensing/deployment terms and can carry separate costs; when unavailable, stop the affected external operation.