makelore/.project-docs/30-worklog/tasks/20260904-project-scaffold-implementation-7e4c2a91.md

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: 336e0bb0ca
• 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.