engineering-memory 1.11.26 → 1.11.28

package/skill/references/lifecycle.md

@@ -254,7 +254,7 @@ A project-specific correction is offered as task-only or permanent for this proj
 
 Before validation, read the changed code back against the rules that govern it. Not from memory: reread the returned records for the paths that changed, including anything the context pack deferred, and read the diff as the next person to open the file would. The restraint document is the first thing to hold it against.
 
-`context.prepare_change` returns `governingRules`: for each changed path, the rules its role in the project profile binds it to. Record `task.self_review` with one entry per changed file (deleted files excepted) that names every one of those rules, and for a file the profile maps to no role, the engineering rules you actually read it against. Each rule gets one outcome:
+`context.prepare_change` returns `governingRules`: for each changed path, the rules its role in the project profile binds it to. Record `task.self_review` with one entry per changed file (deleted files excepted) that names every one of those rules, and for a file the profile maps to no role, the engineering rules you actually read it against. It also returns `selfReviewRequired`: every record the change lease is taken against — the records of the leased paths, deferred ones included, and the project profile — each with the leased paths it covers. The review names each of them too, on a changed file it covers, or on any changed file when it covers no single path; `task.self_review` refuses a review that leaves one out and records nothing, and `task.verify` would refuse it as well. Each rule gets one outcome:
 
 - `follows`: the file does what the rule says.
 - `fixed`: it did not, and you changed it; record what was wrong and what you changed.
@@ -286,6 +286,8 @@ Record `handoff_before`, then call `task.verify`. For a write task, verify the e
 
 A verified task is not frozen. When a change is needed after verification — a product manager's update, a fix the user asks for, a correction — call `context.prepare_change` for the paths it touches: that reopens the task and keeps everything recorded so far. A correction, a checkpoint or a self review reopens it as well. `task.reconcile` and `memory.propose_revision` on a verified task refuse with `Task already verified` and recovery `context.prepare_change`; call it, then repeat the refused call. Make the change, review it with `task.self_review`, run the validations again with `validation_before`, `validation_after` and `handoff_before` recorded around them, and verify again before `task.close`.
 
+A closed task whose changes are not delivered yet is not frozen either. When the user asks for a further change before the delivery — after trying the branch, or a new request before the push — call `context.prepare_change` in the task's session with the paths the change touches; in a new chat, `session.resume` shows that session. It reopens the task (`reopenedFromClose: true`), keeps everything recorded so far and clears the delivery answer, so the next `task.close` asks the delivery question again for the new content. Until then a checkpoint, correction, self review or reconciliation on the closed task refuses with `Task closed before delivery` and recovery `context.prepare_change`. Once its delivery is recorded as delivered or concluded, the task stays closed: start the next change as new work with `task.branch`, which can continue on the same branch.
+
 When a task adds a structure the system did not have — a cache, a broker, a read replica, a second deployable, a projection, an event store — name it in `introducedStructures` at verification. The backend refuses any the project profile has not recorded under `architecture.adopted`, with the pressure it relieves, and refuses with the stated reason any the project recorded as deliberately declined. Recording it is a project profile revision like any other: propose, have the user approve, reconcile. Do not reach for the structure first and record it afterwards — the point of the record is that somebody decided.
 
 A new screen or component fails verification until its memory exists, which takes four steps in order: `memory.propose_revision` for each new path, the user's explicit approval, `memory.review_proposal`, then `task.reconcile`. The error names the paths. Walk the chain rather than retrying the same verification.
@@ -294,7 +296,9 @@ Call `task.close` only after verification and only when the current diff still m
 
 After memory approval, finish any required reconciliation and verification, then call `task.close` in the same turn; do not stop at publishing memory or at a successful verify result. Closing is not the end of the turn either. The MCP `task.close` call closes the verified task and opens its durable, mode-governed delivery selector itself: commit, commit and push, commit and push with a draft PR/MR, commit and push with a PR/MR, or keep it for now. Do not open a duplicate delivery questionnaire. Follow its pending/delegated/native result and retry the same call until a real decision is recorded. Cancellation and feedback preserve the closed worktree and pending delivery. PR/MR target selection is a second question when the target is not already explicitly supplied; merging is separate and never implied. An explicit Git delivery instruction already present in the user's own message can be passed as `deliveryInstruction` with its exact relevant `userRequestExcerpt`, choice and any explicit baseBranch. It is reported as an agent-reported user instruction, not a native answer; never use memory approval or an agent preference as that instruction. Read-only tasks have no Git delivery form. Perform only the selected and authorized Git action; the tool itself commits, pushes and merges nothing. When the host has to approve a push, follow the Delivery section of `questionnaires.md`; an Engineering Memory form is never the way past a host's denial.
 
-When a pull request has been opened, keep going: check whether it merges cleanly, report the result with the link, and if it conflicts, name the files and ask whether to resolve them. Never end the turn on a pull request whose mergeability was never checked, and never resolve a conflict without being told to.
+When the delivery chose a pull request and the branch is pushed to a GitLab, open it with `task.open_review_request` in the task's clone: it opens the merge request from this computer — a GitLab reachable only from the company network included — reuses one the branch already has, and records it in the same call. When it says no GitLab token is saved, call `gitlab.token` and give the user the link it returns: they type their own token on that page, on their own computer. Never open or fill in that page, never ask for the token, and never use a token pasted into the chat — ask the user to revoke it and use the page. For any other provider, or when the tool refuses, open the pull request with the tools you have and record it with `task.review_request` — its link as the provider shows it, and `draft` or `ready` as it was opened. Either way, keep going: check whether it merges cleanly, report the result with the link, and if it conflicts, name the files and ask whether to resolve them. Never end the turn on a pull request whose mergeability was never checked, and never resolve a conflict without being told to. `session.entry` lists as `awaitingReviewRequests` the delivered tasks still waiting for their pull request; mention them in one line.
+
+When the user later says a pull request became ready, was merged or was closed, record that state with `task.review_request` too; it works from any chat, also for a delivery `session.entry` lists. Engineering Memory then moves the task's work item as the project's workflow rules say: to the `pr_opened` target once every pull request of the work item is ready, to the `all_prs_merged` target (READY FOR QA by default) once they are all merged, and to the draft target when one is still a draft and the project names one. It waits while another task of the work item is still open, or closed with a delivery that has no pull request yet. Relay the returned `nextAction` in one line. A record is what was reported, unless a member's computer read it from GitLab: where someone has saved a GitLab token, the bridge reads the project's merge requests in the background when a chat opens or work items are listed, and records a merge, a close or a draft turning ready by itself, also for a merge request someone opened by hand. Never report a merge the user has not confirmed. A merge is final, and a delivery keeps the first pull request recorded for it. GitHub pull request and GitLab merge request links are recorded; for another provider, move the work item with `work_item.update`.
 
 ## Code source and memory applicability