feat(projects): add interactive AI app scaffold skill

This commit is contained in:
2026-09-04 20:36:28 +08:00
parent 336e0bb0ca
commit 959b6333b5
40 changed files with 2647 additions and 65 deletions

View File

@@ -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.