engineering-memory 1.11.15 → 1.11.17

package/runtime/dist/src/runtime/worktree-readiness-types.js

@@ -0,0 +1,18 @@
+export var WorktreeFileStatus;
+(function (WorktreeFileStatus) {
+    WorktreeFileStatus["Prepared"] = "prepared";
+    WorktreeFileStatus["Attention"] = "attention";
+    WorktreeFileStatus["NotNeeded"] = "not_needed";
+    WorktreeFileStatus["Skipped"] = "skipped";
+})(WorktreeFileStatus || (WorktreeFileStatus = {}));
+export var WorktreeFileIssue;
+(function (WorktreeFileIssue) {
+    WorktreeFileIssue["Missing"] = "missing";
+    WorktreeFileIssue["Conflict"] = "conflict";
+    WorktreeFileIssue["Stale"] = "stale";
+    WorktreeFileIssue["Unsafe"] = "unsafe";
+    WorktreeFileIssue["Unsupported"] = "unsupported";
+    WorktreeFileIssue["SourceChanged"] = "source_changed";
+    WorktreeFileIssue["Failed"] = "failed";
+})(WorktreeFileIssue || (WorktreeFileIssue = {}));
+//# sourceMappingURL=worktree-readiness-types.js.map

package/skill/references/lifecycle.md

@@ -24,6 +24,8 @@ Start new write or scaffold work with `task.branch`, before `session.bootstrap`,
 
 Use the returned `repoRoot` for **every** file read/write, terminal, context, validation and Git/delivery operation. The user-local pool is shared by Codex and Claude. Managed directories live under `engineering_memory/worktrees/<stable-project-folder>/<folder>_worktreeN`, at the root of the system drive on Windows (`C:\engineering_memory\worktrees\...`) and in the home directory elsewhere, or under the absolute directory named by `worktree-root.json` in the user-level API state directory when that file exists; `worktree.list` reports the effective root, and worktrees created by earlier clients under the Documents folder keep working where they are. Do not supply arbitrary `worktreePath` values or create ad-hoc siblings. Independent clones cannot reuse each other's worktrees. `worktree.list` explains which slots are active, inactive but protected, or safely reusable. The versioned backend policy defaults to 50 directories per project/computer, 30-second heartbeats and 10-minute inactivity. Protected inactive directories still count toward the limit. Only a global admin changes `worktree.set_policy`; it is not an environment setting.
 
+After managed allocation, inspect `readiness.files` and `readiness.editor`. The bridge prepares supported ignored runtime files from pinned same-clone sources, preserving existing files and reporting missing, conflicting, stale or unsupported configuration. A signing key outside the source checkout remains external. File contents stay local. Repair the reported issue with the user's existing authority, then retry `task.branch` or `session.resume`; never overwrite a conflict merely to make preparation pass. The editor status `requested` records a VS Code CLI request, not verified window visibility. The CLI reuses a matching single-folder window and preserves unrelated windows; an existing multi-root membership is not verified. Headless sessions, unavailable editors and launch failures leave the task allocated. Do not repeatedly open windows yourself after a recorded request.
+
 Renew `task.heartbeat` using the exact returned task, path and ownership generation during actual work and at approximately the cached heartbeat interval during long local commands. The bridge renews while its own task operation is running. Never run a perpetual heartbeat for an idle chat or MCP process. Inactivity never authorizes takeover of a live owner or deletion of files. Before writing after interruption, use `session.resume`; follow any returned worktree redirect and resume there. A stale generation cannot renew, release, verify or commit another owner's work.
 
 Use `task.pause` when work stops or is handed to another client. It preserves task state and files, invalidates the old owner, and allows safe clean directories to be reused. It is not `task.abandon`. Resume reacquires the original directory when possible or uses the retained task branch in another safe directory. `worktree.reconcile` recovers interrupted allocation and validated local ownership records against Git. Never edit the registry, force checkout, stash/reset/clean, remove branches, kill a client or delete a worktree to bypass a refusal.
@@ -71,6 +73,14 @@ One WorkItem UUID coordinates independent EngineeringTask runs, one per selected
 
 Open each side with the same workItemId and its own repository binding when work reaches that side. Each side has its own lease, reconciliation, verify, close and commit gate. Check `work_item.runs` and sibling checkpoints when handing off; one side completing does not prove all selected projects are complete. A plan's scope and branch cannot change while an implementation run is active. Read-only analysis does not acquire application write rights; its later write transition must satisfy discipline and the confirmed plan.
 
+### Work item statuses
+
+Read `work_item.statuses` before choosing a status for `work_item.update` or filtering `work_item.list`. The catalogue belongs to the project: follow its user-defined `meaning`, `entryRule` and flags. Never infer workflow from a name or translate statuses into the old six-value set. Send the actual catalogue slug. A work item's `status` is that slug, or null when its status link is invalid.
+
+The catalogue returns `items`, `total`, `offset` and `limit`. Page with `offset` (default 0) and `limit` (default 50, maximum 100); use `includeArchived: true` to inspect retained archived statuses. Each row includes `id`, `slug`, `name`, `category`, `isInitial`, `isActionable`, `isParked`, `isTerminal`, `archivedAt`, `meaning`, `entryRule`, `position` and `lockVersion`. The work item's nested `projectStatus` remains its compact nine-field summary. `work_item.list` also accepts `offset` and `limit`; a status filter matches the actual slug, including retained archived statuses, and an unknown slug returns an empty page. Its `includeArchived` option concerns work items.
+
+Session entry uses the backend's actionable selection. An empty page remains empty, and a failed lookup offers no work items; never retry an unfiltered list to classify statuses locally. Reuse existing user choices. Any unresolved workflow choice must use the native questionnaire.
+
 ### Administration, product management and QA
 
 Administrative authority and work discipline are independent. Organization admins can manage projects, assignments, repository URLs and work items in their organization. A global admin has those rights only in organizations they actively belong to. Ordinary users need a live explicit project assignment. Active organization administrators, including a global admin with live membership in that organization, inherit contributor access to its projects without a separate project grant. Fullstack/backend/web/mobile/frontend disciplines still govern implementation, while project overrides do not grant administration.