makelore/.project-docs/30-worklog/tasks/20260905-project-plugin-scope-7c4e9a21.md

Task: Make project-scoped Plugins active without partner assignment

Identity

• Task ID: 20260905-project-plugin-scope-7c4e9a21
• Mode: Feature
• Branch: codex/20260905-project-plugin-scope-7c4e9a21-project-plugin-scope
• Worktree: D:\Datas\OthersProjects.codex-worktrees\makelore\20260905-project-plugin-scope-7c4e9a21
• Base commit: d642d7607c
• Owner: codex-root
• Status: Ready for Integration

Scope

• Reproduce whether the code-owned bundled makelore.project-scaffold Skill is currently excluded from a parent Agent when the Plugin is acquired and enabled for the project but not explicitly assigned to that Agent.
• Change only Project Scaffold activation semantics so project enablement is sufficient for parent-Agent materialization; preserve Account Library acquisition, child-worker emptiness, frozen worker generations, and every other Plugin's assignment behavior.
• Remove Project Scaffold's partner-assignment action/status from the unified Plugins workspace and add focused runtime plus Renderer regressions.
• Record the accepted user decision as an Integration promotion candidate; this Feature task does not edit canonical architecture, domain, or ADR files.

Intent And Constraints

• Concurrent Task Gate: Passed. The exact owner/worktree/branch/base identity was verified through task_context.py status --json; related Plugin download/status tasks are Ready for Integration and have no active writer overlapping this scope.
• Planning Gate: Passed after loading the project entry docs, current state, decision index, ADR-008, architecture/data flow/module map, business rules, success criteria, glossary, evidence, reflection, commitments, stale items, and relevant peer records.
• Project Context Loaded:
  • Positioning: MakeLore Code is a Main-owned Pi runtime whose Plugin state is projected through existing Marketplace/project/Agent authorities rather than Renderer-owned lifecycle state.
  • Current focus: official bundled Project Scaffold delivery and unified /plugins presentation are already integrated; the remaining question is activation scope.
  • Applicable decision: ADR-008 previously required acquisition, project enablement, and Agent assignment. The user's explicit 2026-09-05 decision supersedes only the assignment requirement for Project Scaffold.
  • Architecture boundaries: effective resolution remains Main-owned; Renderer only projects actions. Parent workers may receive the Skill, child workers remain empty, and active workers keep frozen resources until replacement/settlement.
  • Current state: makelore.project-scaffold ships in the signed client and has no device download path; Account acquisition and project enablement remain distinct.
  • Known risk: hiding the UI assignment action without changing the effective resolver would leave the Skill unusable; broadening all Plugin Skills would silently alter unrelated assignment semantics.
  • Relevant commitment: final packaged Project Scaffold activation still requires a rebuilt client and installed-client smoke; workspace tests do not prove that step.
  • Relevant peers: the bundled-status integration and device-action-gap tasks only correct delivery presentation/package evidence; neither changes activation scope.
• TDD boundary: first assert the public effective-resolver and Plugins-page behavior at acquired + project-enabled + unassigned state, then implement the narrowest shared activation-scope rule that makes those assertions pass.
• Do not modify the occupied client root, Server, Marketplace contracts, Package Store, billing, hosted execution, local Device Packages, or unrelated Plugin assignments.

Outcome

• Confirmed the defect at the Main-owned effective-resolver seam: an acquired, project-enabled Project Scaffold Plugin with no Agent assignment was rejected as skill_unassigned, so removing only the Renderer action would not have activated it.
• Added one narrow code-owned project-wide activation invariant for makelore.project-scaffold. Its full Skill set now materializes for every parent Agent after Account acquisition and project enablement; disabled projects remain blocked and child Agents remain empty.
• Updated the unified Plugins workspace so Project Scaffold no longer offers partner assignment. Cards and details now describe its scope as 随项目启用 / 生效范围.
• Preserved existing assignment behavior for Game Resource, Data Service, Marketplace, and local Plugins. No manifest schema, server contract, Package Store, billing, or worker-lifecycle authority was added.

Verification

• TDD RED: the focused resolver/model/page slice produced 3 expected failures and 42 passes: Project Scaffold returned skill_unassigned, the assignment command remained, and the project-wide scope copy was absent.
• Focused GREEN: 3 files / 45 tests passed.
• Adjacent Plugin/runtime regression: 12 files / 87 tests passed, including effective resolution, composition, lifecycle, manifest/routes, Pi resource/worker opening, Project Scaffold, and unified Plugins projection/controller/query/page behavior.
• corepack pnpm run typecheck: passed.
• Scoped ESLint: passed. Full corepack pnpm run lint:check: 0 errors and 5 unchanged warnings in untouched Home/Makelore files.
• Full regular unit suite: 225 files passed and 1 unrelated real-process timing test failed (pi-agent-server-process-real, 2630 ms against a 2000 ms threshold); 1888 tests passed and 2 skipped. The exact failed file then passed in isolation, 6/6.
• Isolated pressure suite: 1/1 passed.
• corepack pnpm run build:vite: Renderer, Main, Preload, and utility builds passed with existing Browserslist/import/chunk warnings.
• git diff --check: passed.

Follow-ups

• The Integration task must promote the Project Scaffold activation rule into ADR-008, module map, data flow, and business rules, then rebuild/install the client and smoke-test an acquired + project-enabled + unassigned parent Agent. Workspace tests do not prove the installed-client generation was replaced.

Promotion Candidates

• Update ADR-008, module map, data flow, and business rules during Integration so makelore.project-scaffold is documented as account-acquired + project-enabled and automatically available to parent Agents, with no partner-assignment state.
  • Evidence: focused resolver RED reproduced skill_unassigned; the corrected focused and adjacent suites pass while Game Resource retains open_agent_assignment.
  • Future impact: Plugin activation-scope changes must update the code-owned scope predicate and both Main/Renderer regressions; Project Scaffold assignments already stored in project data become inert but may remain preserved.
  • Semantic conflict: supersedes only ADR-008's assignment requirement for Project Scaffold, not the general assignment model for other Plugins.
  • Human confirmation required: No; the user explicitly chose project-level activation on 2026-09-05.