feat(projects): add interactive AI app scaffold skill
This commit is contained in:
@@ -0,0 +1,45 @@
|
||||
# 交互式 AI 应用统一类型提案
|
||||
|
||||
## 文档信息
|
||||
|
||||
- 状态:Proposed,等待 Integration Gate 提升
|
||||
- 所有者:`20260904-project-scaffold-implementation-7e4c2a91`
|
||||
- 日期:2026-09-04
|
||||
- 影响范围:项目创建、项目配置读取、脚手架、发布打包与作品元数据
|
||||
|
||||
## 决策
|
||||
|
||||
新建项目的唯一可发布类型改为:
|
||||
|
||||
- 稳定标识:`interactive_ai_app`
|
||||
- 展示名称:`交互式 AI 应用`
|
||||
|
||||
`mini_game` 与 `mini_program` 不再出现在新建入口,也不再由新客户端写入。两者作为历史只读别名,在项目配置读取边界统一归一化为 `interactive_ai_app`,不批量改写用户已有的 `.makelore/project.json`。归一化后的打包清单和后续提交元数据只输出规范值。
|
||||
|
||||
`custom` 仍是独立的工作空间类型,并继续禁止进入平台的一键发布流程。
|
||||
|
||||
## 脚手架与发布合同
|
||||
|
||||
- 脚手架只维护一套通用 Vite 静态应用模板,不再按小游戏/小程序维护两套业务模板。
|
||||
- 历史项目调用脚手架时使用相同的统一模板,脚本返回规范类型,但保留原始项目元数据。
|
||||
- 固定 npm/Vite 构建、静态产物合同、浏览器预检、上传和审批要求不因类型合并而放宽。
|
||||
- 平台服务应先兼容接收三个值并统一输出 `interactive_ai_app`,再发布只写规范值的新客户端,以支持滚动升级。
|
||||
|
||||
## 兼容与迁移边界
|
||||
|
||||
- 不执行数据库或本地配置的批量历史迁移。
|
||||
- 不增加版本开关、双写、模板迁移框架或类型特有构建分支。
|
||||
- 旧客户端上传 `mini_game` / `mini_program` 时,服务端在校验边界接受并归一化;`custom`、未知值仍拒绝。
|
||||
- 历史发布记录保持不可变;公开读取和信息流投影使用规范类型。
|
||||
|
||||
## 被取代的语义
|
||||
|
||||
本提案在集成后取代既有文档中“小游戏与小程序是两个可发布项目类型”以及“二者分别生成不同模板”的部分。既有关于静态 Vite 发布、安全预检、制品不可变与审批流程的约束继续有效。
|
||||
|
||||
## 验收
|
||||
|
||||
- 新建界面只显示“交互式 AI 应用”和“自定义项目”。
|
||||
- 新建可发布项目落盘 `interactive_ai_app`,脚手架生成统一模板。
|
||||
- 两种历史配置均可打开和发布,原配置文件不会仅因读取而被改写。
|
||||
- 客户端清单、上传元数据和平台公开投影均使用 `interactive_ai_app`。
|
||||
- `custom` 与未知类型仍被拒绝发布。
|
||||
@@ -0,0 +1,105 @@
|
||||
# Task: Implement project scaffold Skill plugin
|
||||
|
||||
## Identity
|
||||
|
||||
- Task ID: 20260904-project-scaffold-implementation-7e4c2a91
|
||||
- Mode: Feature
|
||||
- Branch: codex/20260904-diagnose-design-stream-6a4e9c21-diagnose-design-stream
|
||||
- Worktree: D:\Datas\OthersProjects\.codex-worktrees\makelore\20260904-diagnose-design-stream-6a4e9c21
|
||||
- Base commit: 336e0bb0caf24537b7b0f350aba3e04a37f5544c
|
||||
- Owner: codex
|
||||
- Status: Ready for Integration
|
||||
|
||||
## Scope
|
||||
|
||||
- Preserve the current project-creation boundary and add regression coverage proving that no mini-game, mini-program, or custom business scaffold is created.
|
||||
- Correct the new-project product copy so users are directed to the explicit project-scaffold Skill after creation.
|
||||
- Expose the application-owned Node executable to direct Pi workers and the shared Agent Server.
|
||||
- Treat non-empty standard Skill `scripts/` directories as executable code in Device Package preview, confirmation, and details copy.
|
||||
- Add an independently installable `plugins/makelore-project-scaffold/` package containing one Skill, deterministic scaffold script, fixed templates, submission requirements, and tests.
|
||||
- Make the Skill itself route publication/readiness requests and carry the current platform contract as four distinct classes: required input, direct blocker, source-package exclusion, and runtime/platform-only confirmation.
|
||||
- Add regression coverage that keeps the documented source-package exclusion set aligned with the current packager without introducing a second build or publication implementation.
|
||||
- Verify the unified generated project through the current project packager and local npm/Vite release seam, plus both historical input aliases at the compatibility boundary.
|
||||
- Replace the two publishable project types with canonical `interactive_ai_app` / “交互式 AI 应用” across creation, configuration, packaging, the scaffold Skill, and Works Square-facing metadata while retaining read compatibility for existing `mini_game` and `mini_program` projects.
|
||||
|
||||
## Intent And Constraints
|
||||
|
||||
- Implement accepted proposal `ML-PROJECT-SCAFFOLD-001` without restoring project-creation side effects.
|
||||
- Keep immutable `.makelore/project.json.projectType` as the only scaffold selector; do not add scaffold state, a template migration layer, `--force`, or a dedicated Pi extension/tool.
|
||||
- Execute scaffolding only through the existing Pi `bash` project write lease and `MAKELORE_NODE_EXECUTABLE`; do not fall back to system Node or Python.
|
||||
- Never overwrite target files. Preflight the full fixed target set and roll back only files/directories created by the current handled invocation.
|
||||
- Preserve Main-owned fixed npm/Vite build, source/built artifact contract, browser preflight, and Works Square operational review as the release authority.
|
||||
- Keep feature-task writes within product code, tests, this task record, and task-prefixed supporting records; canonical project memory changes remain promotion candidates for Integration Gate.
|
||||
- Stage the plugin source under `plugins/makelore-project-scaffold/` for local Device Package installation. Immutable Git tagging, publication, and cross-platform packaged smoke remain release follow-ups and are not claimed by this task.
|
||||
|
||||
## Outcome
|
||||
|
||||
- Confirmed the request's original deletion premise was already true on base `336e0bb`: Project Service creates only `.makelore/project.json` and `knowledge/`. Added creation regressions for the canonical interactive type and `custom`, and removed the Sidebar promise that project creation itself makes a publishable scaffold.
|
||||
- Added the non-overridable `MAKELORE_NODE_EXECUTABLE` host contract to both direct Pi workers and the shared Agent Server process. A worker overlay cannot spoof the application-selected executable path.
|
||||
- Extended Device Package inspection so a declared Skill with a non-empty standard `scripts/` subtree is executable code. Skill-only script packages retain `kind: skill-only`, require the existing cross-turn executable confirmation, and show Skill-specific file/network/process authority copy in preview and plugin details. Existing Pi-extension and mixed packages retain executable warnings.
|
||||
- Added `plugins/makelore-project-scaffold/` as a standard, independently versioned `0.1.0` plugin with one Skill and no Pi extension. Its package and plugin manifests are same-name/same-version and have no install lifecycle scripts.
|
||||
- Added a deterministic Node-only `scaffold.mjs` selected exclusively by `.makelore/project.json.projectType`. It accepts only `--project-root`, creates one fixed six-file interactive AI application target set, reads all templates and preflights every target before writing, uses exclusive creation, preserves unrelated files, returns the flat version-1 JSON protocol, and rolls back only current-invocation files/directories on handled write failure. It provides no `--force`, type override, migration state, dependency install, network request, or publisher replacement.
|
||||
- Regenerated the Vite 7.3.1 lockfile with the repository's fixed npm 11.6.2 and verified the unified template through source packaging and a real locked npm/Vite build. Added an approval-readiness reference that distinguishes static preparation from authoritative Main build/preflight/upload and Works Square operational review.
|
||||
- Expanded the Skill's model-invocation routing and package-facing copy so requests about publishing, one-click submission, forbidden content, failure causes, or release readiness enter an explicit read-only readiness workflow. Project-specific reports now separate confirmed blockers, excluded-package impact, runtime/platform checks, and statically proven requirements, cite project-relative evidence, and use bounded conclusions that never claim approval.
|
||||
- Reconciled the bundled publication reference against the current project packager, fixed npm/Vite release builder, static-artifact browser preflight, and Works submission route. It now records the full schema-v2 project prerequisite, root build inputs, exact size/count limits, direct path/link/output blockers, root `release.json` prohibition, both viewports and runtime failures, first-submit metadata/cover contract, and the exact case-insensitive excluded directory/file/suffix sets plus dynamic `.env`, credential JSON, Terraform, and `works-` patterns.
|
||||
- Kept exclusion semantics explicit: excluded paths may remain in a project and are not blockers by existence; the Skill reports their effect only when required source or assets depend on them. The reference also states that an HTTP(S) literal is only a risk until the authoritative preflight makes an actual cross-origin request.
|
||||
- Did not add a release-check script, duplicate packager, local dependency install, Vite invocation, browser launch, upload, or submission path to the plugin. Main and Works Square remain the only execution and approval authorities.
|
||||
- Verified the real plugin through Device Package prepare, later-turn confirmation, commit, enabled-resource resolution, and installed script/template/reference reads.
|
||||
- Replaced the two new-project values with canonical `interactive_ai_app` / “交互式 AI 应用”. New creation, generated `niancode.yml`, submission metadata, and publish UI use only the canonical value. Existing `mini_game` and `mini_program` configs normalize at the read boundary; a read or scaffold invocation does not rewrite the original config, while a later ordinary config mutation may persist the normalized value.
|
||||
- Replaced the two business-specific starter trees with one generic interactive Vite starter. The scaffold continues to accept both historical values solely as compatibility aliases and reports the canonical type.
|
||||
- Added the task-owned interactive-type proposal instead of modifying accepted ADRs or canonical project memory in feature mode.
|
||||
- No existing user project files were removed or migrated. No plugin tag was published and the plugin was not silently installed into the running application.
|
||||
|
||||
## Verification
|
||||
|
||||
- `node --test plugins/makelore-project-scaffold/tests/scaffold.test.mjs`: 12 passed. Covers the canonical value, both historical aliases, exact unified output tree, metadata preservation, conflicts, invalid/missing/custom configs, invalid CLI, missing template, Chinese/space paths, and handled-write rollback.
|
||||
- Focused type/scaffold/release/UI regressions: 7 Vitest files and 107 tests passed.
|
||||
- `pnpm typecheck` and scoped ESLint over the changed type, configuration, packaging, UI, route, and test files passed.
|
||||
- Desktop project-configuration Playwright E2E: 1 passed; the new-project dialog exposed only “交互式 AI 应用” and `custom`, and the publish action remained available for the canonical type.
|
||||
- Real unified-template smoke: the actual scaffold ran in a verified temporary directory, fixed npm 11.6.2 completed `ci --ignore-scripts`, Vite 7.3.1 built successfully, and non-empty `dist/index.html` was produced; the temporary directory was removed.
|
||||
- Plugin creator validation passed; Skill creator `quick_validate.py` returned `Skill is valid!` under explicit Python UTF-8 mode.
|
||||
- `pnpm run build:vite` passed for Renderer, Main, Preload, and utility worker. Only existing Browserslist, mixed-import, and large-chunk warnings remained.
|
||||
- Full serial main suite: 225/226 files passed; 1886 tests passed and 2 skipped. The only failure was the existing Pi Agent Server two-Bash-call wall-clock assertion (`2657ms < 2000ms`). An immediate isolated rerun again exceeded the fixed threshold (`2170ms`) while its other 5 tests passed; no project-type/scaffold path is involved and this task did not relax the threshold. The separately excluded pressure suite passed 1/1.
|
||||
- Earlier focused Device Package, Pi environment, Plugin Details, release-builder, and browser-preflight suites recorded by this same task remained green; the type follow-up did not modify those implementations.
|
||||
- Final `git diff --check` and task-aware project-doc drift check passed; only the task record and task-prefixed proposal changed under `.project-docs/`.
|
||||
- Merge handoff re-ran `git diff --check` and the task-aware drift check after the explicit integration request; both remained green and no product files changed during handoff.
|
||||
|
||||
## Follow-ups
|
||||
|
||||
- Release `SCF-060`: move or mirror the staged plugin source to the chosen independent distribution repository, create an immutable SemVer tag, document the Device Package install source, and complete a small real-user prepare → confirm → install → initialize trial. Distribution location remains a product/release decision; this task does not invent it.
|
||||
- Before claiming packaged support, run the Skill through an installed MakeLore build with the actual packaged executable and Git Bash on Windows. Run equivalent packaged smoke on macOS and native Linux; only then claim three-platform support.
|
||||
- Verify enable/disable, upgrade to a second immutable version, downgrade/reinstall of a known version, and uninstall semantics. Uninstall must not delete files already created in user projects.
|
||||
- Official Marketplace Skill artifacts currently reject executable `.mjs` assets. Continue using Device Package/Git distribution unless a separately approved Marketplace artifact policy adds executable Skill support.
|
||||
- Track the existing `pi-agent-server-process-real` `<2000ms` assertion as a separate performance-test stability issue; it currently exceeds the threshold both under the full serial suite and in one isolated rerun, while its functional assertions pass.
|
||||
- After code/plugin integration and release acceptance, run an Integration Gate task to promote the canonical project-creation and Device Package facts listed below.
|
||||
|
||||
## Promotion Candidates
|
||||
|
||||
- **Canonical interactive AI application type**
|
||||
- Target canonical documents: `.project-docs/10-decisions/`, `.project-docs/30-worklog/current-state.md`, `.project-docs/40-domain/glossary.md`, `.project-docs/40-domain/business-rules.md`, and relevant architecture/data-flow summaries.
|
||||
- Proposal: replace the distinct new-project `mini_game` / `mini_program` values and templates with `interactive_ai_app` / “交互式 AI 应用” and one generic interactive Vite scaffold; retain both old values only as historical read aliases.
|
||||
- Evidence: shared/config normalizer and regressions, new-project E2E, canonical package/submission tests, all three scaffold input tests, real unified-template build, and task proposal `20260904-project-scaffold-implementation-7e4c2a91__interactive-ai-app-type.md`.
|
||||
- Future impact: future templates and publishing rules evolve against one stable product type while existing local projects continue to open and publish without a batch rewrite.
|
||||
- Semantic conflicts: supersedes the canonical two-publishable-type classification and any separate mini-game/mini-program template promises; it preserves fixed npm/Vite build, approval, and immutable release rules.
|
||||
- Human confirmation required: no additional product decision is required because the user explicitly requested the merge; Integration Gate review is still required before canonical writes.
|
||||
- **Project creation / scaffold ownership**
|
||||
- Target canonical documents: `.project-docs/30-worklog/current-state.md`, `20-architecture/system-overview.md`, `20-architecture/data-flow.md`, `40-domain/glossary.md`, `40-domain/business-rules.md`; add a new integration entry to `30-worklog/task-history.md` rather than rewriting historical task rows.
|
||||
- Proposal: replace current-state claims that mini-game/program creation atomically generates Vite templates with the accepted three-boundary model: Project Service owns only project metadata and `knowledge/`; explicit `makelore-project-scaffold` Skill owns starter files; Main/Works release code owns build, preflight, packaging, upload, and review state.
|
||||
- Evidence: `electron/coding-projects/project-config.ts`, the canonical/custom creation regression, plugin script/tests, unified-template build smoke, and accepted proposal `ML-PROJECT-SCAFFOLD-001`.
|
||||
- Future impact: prevents UI/docs/agents from assuming a newly created project is immediately publishable and keeps template evolution independent from project identity.
|
||||
- Semantic conflicts: supersedes the integrated 2026-08-09 current-state claim; old task records remain historical evidence and must not be edited.
|
||||
- Human confirmation required: no for factual promotion after the implementation commit is integrated; yes if product wants automatic/bundled initialization instead of the accepted explicit Skill boundary.
|
||||
- **Executable Skill scripts and host runtime**
|
||||
- Target canonical documents: `.project-docs/30-worklog/current-state.md`, `20-architecture/system-overview.md`, `20-architecture/module-map.md`, `20-architecture/data-flow.md`, and `40-domain/business-rules.md`.
|
||||
- Proposal: state that a Device Package Skill with a non-empty standard `scripts/` subtree is executable code requiring preview disclosure and later-turn confirmation even when `kind` remains `skill-only`; parent worker/Agent Server environments expose the non-overridable application Node path through `MAKELORE_NODE_EXECUTABLE`.
|
||||
- Evidence: `device-package-format.ts`, `device-package-manager.ts`, Plugin Details UI/tests, both Pi process tests, real package prepare/commit test, and Windows Git Bash quoting smoke.
|
||||
- Future impact: keeps permission messaging accurate for script-backed Skills and gives portable Skills an application-owned runtime without PATH fallback.
|
||||
- Semantic conflicts: current canonical wording mentions executable Pi extensions only. Existing rule that child workers receive no Device Package resources remains unchanged.
|
||||
- Human confirmation required: no for promotion after integration; actual packaged platform claims still require the release smokes in Follow-ups.
|
||||
- **Release obligation**
|
||||
- Target canonical document: `.project-docs/80-commitments/commitments.md`.
|
||||
- Proposal: fold this plugin's actual packaged Windows/macOS/Linux execution and Device Package lifecycle trial into the existing client release commitment instead of creating a parallel release gate.
|
||||
- Evidence: workspace Windows Git Bash and real release-builder smokes are green; immutable tag, installed-app execution, macOS, and Linux evidence are absent.
|
||||
- Future impact: prevents workspace-only evidence from being mistaken for a distributable cross-platform release.
|
||||
- Semantic conflicts: the existing commitment already warns that workspace prepare tests do not replace final packaged proof; preserve that stricter rule.
|
||||
- Human confirmation required: release owner confirmation is required before marking the commitment complete or choosing the public distribution location.
|
||||
Reference in New Issue
Block a user