engineering-memory 1.5.0 → 1.6.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "engineering-memory",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.6.1",
|
|
4
4
|
"description": "Installs the Engineering Memory skill and its local MCP bridge. Sign in after installing; your organization and project are resolved from your account.",
|
|
5
5
|
"license": "UNLICENSED",
|
|
6
6
|
"type": "module",
|
|
@@ -312,13 +312,19 @@ export class BridgeService {
|
|
|
312
312
|
resumeIdentityMatches &&
|
|
313
313
|
conflicts.every(isOfflineDevelopmentWarning) &&
|
|
314
314
|
isOfflineLeaseUsable(resumedLease, sessionId, pointer?.changeBaseline?.leasePaths ?? [], pointer?.changeBaseline?.diffHash);
|
|
315
|
-
const
|
|
316
|
-
pointer.sessionId === sessionId &&
|
|
317
|
-
pointer.changeBaseline &&
|
|
318
|
-
(resumedLease?.baselineDiffHash === pointer.changeBaseline.diffHash ||
|
|
319
|
-
objectValue(backend.verificationRecovery)?.diffHash === repository.git.diffHash)
|
|
315
|
+
const localBaseline = pointer?.taskId === backendTask.id && pointer.sessionId === sessionId
|
|
320
316
|
? pointer.changeBaseline
|
|
321
317
|
: undefined;
|
|
318
|
+
const recordedBaselineDiffHash = typeof backend.changeBaselineDiffHash === 'string'
|
|
319
|
+
? backend.changeBaselineDiffHash
|
|
320
|
+
: undefined;
|
|
321
|
+
const repairedBaseline = repairChangeBaseline(localBaseline, recordedBaselineDiffHash, repository.git.head);
|
|
322
|
+
const resumedBaseline = repairedBaseline ?? localBaseline;
|
|
323
|
+
if (recordedBaselineDiffHash &&
|
|
324
|
+
resumedBaseline &&
|
|
325
|
+
resumedBaseline.diffHash !== recordedBaselineDiffHash) {
|
|
326
|
+
conflicts.push('task_change_baseline_recaptured');
|
|
327
|
+
}
|
|
322
328
|
const resumedLastSequence = responseSource === 'stale_cache' && pointer
|
|
323
329
|
? Math.max(pointer.lastSequence, numericSequence(backendTask.lastSequence), localJournal.projection?.appliedEventIds.length ?? 0)
|
|
324
330
|
: numericSequence(backendTask.lastSequence);
|
|
@@ -2372,6 +2378,20 @@ function isOfflineLeaseUsable(lease, sessionId, changedPaths, baselineDiffHash)
|
|
|
2372
2378
|
return false;
|
|
2373
2379
|
}
|
|
2374
2380
|
}
|
|
2381
|
+
function repairChangeBaseline(local, recordedDiffHash, head) {
|
|
2382
|
+
if (!recordedDiffHash || local?.diffHash === recordedDiffHash)
|
|
2383
|
+
return undefined;
|
|
2384
|
+
if (sha256(`${head ?? '<unborn>'}
|
|
2385
|
+
${stableStringify([])}
|
|
2386
|
+
`) !== recordedDiffHash) {
|
|
2387
|
+
return undefined;
|
|
2388
|
+
}
|
|
2389
|
+
return {
|
|
2390
|
+
diffHash: recordedDiffHash,
|
|
2391
|
+
changedPaths: [],
|
|
2392
|
+
leasePaths: local?.leasePaths ?? [],
|
|
2393
|
+
};
|
|
2394
|
+
}
|
|
2375
2395
|
function isOfflineDevelopmentWarning(value) {
|
|
2376
2396
|
return (value === 'backend_resume_is_stale' ||
|
|
2377
2397
|
value === 'pending_outbox_delivery' ||
|
|
@@ -74,6 +74,43 @@ Temporary code written to reach or force a path — a pinned state, a fixed serv
|
|
|
74
74
|
|
|
75
75
|
Do not write task Markdown files directly. The bridge owns event IDs, expected task versions, atomic projections, outbox state, and synchronization.
|
|
76
76
|
|
|
77
|
+
## Adopting a Project That Already Exists
|
|
78
|
+
|
|
79
|
+
A repository bound with a working system in it can be surveyed at any time, not only at the moment
|
|
80
|
+
it is bound. When the user asks for its architecture to be learned, read, recorded or understood,
|
|
81
|
+
that is a survey: open it as a read-only task and follow `engineering-core.adopting-an-existing-project`,
|
|
82
|
+
which says what a survey records and what it must never do.
|
|
83
|
+
|
|
84
|
+
Four things come out of it and nothing else: the discovery policy that matches the repository's
|
|
85
|
+
actual layout, the architecture already in place recorded on the project profile under
|
|
86
|
+
`architecture.adopted` with the pressure each structure relieves — or `inherited, reason not
|
|
87
|
+
recorded` where nobody knows — one module record per module saying what it owns, and one current
|
|
88
|
+
deviation per divergence, each carrying what the rule says, what the project does, both costs, and
|
|
89
|
+
a decision or an explicit deferral. Everything else is written as later tasks reach it.
|
|
90
|
+
|
|
91
|
+
The survey changes nothing in the tree. No formatting, no renames, no tidying of dead code it
|
|
92
|
+
finds; leftovers are recorded as observations and decided like any other divergence.
|
|
93
|
+
|
|
94
|
+
Where the same product has a client and a backend, they are two projects. Adopt them separately,
|
|
95
|
+
then link them with `project.link` once both exist, and ask before linking rather than inferring it
|
|
96
|
+
from the names.
|
|
97
|
+
|
|
98
|
+
## The Task Baseline
|
|
99
|
+
|
|
100
|
+
A write task's baseline is the tree it started from, and every changed path it reports is the
|
|
101
|
+
difference between that tree and the current one. It is captured once, at the first change
|
|
102
|
+
preparation, and it is never re-captured — a baseline taken again halfway through a task equals the
|
|
103
|
+
finished work, and from then on the task reports the two or three files touched since instead of
|
|
104
|
+
everything it did. Verification then refuses the true path list, and reporting the short one would
|
|
105
|
+
record a task that did something it did not do.
|
|
106
|
+
|
|
107
|
+
`session.resume` therefore carries the baseline through a lease going stale, expiring, or being
|
|
108
|
+
replaced, and repairs one that has already drifted when the backend's record of the original can be
|
|
109
|
+
proved against the current commit. When it cannot prove it, resume reports
|
|
110
|
+
`task_change_baseline_recaptured`. Do not work around that conflict by reporting a shorter path
|
|
111
|
+
list, and do not edit the pointer file: say what happened, and let the user decide between
|
|
112
|
+
reopening the task and abandoning it.
|
|
113
|
+
|
|
77
114
|
## Change Preparation
|
|
78
115
|
|
|
79
116
|
Skip change preparation for a read-only task. Do not request an edit lease, send changed paths, record `pre_edit`, or reconcile code resources in that mode. If the user later authorizes a change, call `context.prepare_change` with `transitionToWrite: true`, the bridge-owned current task version, intended paths, and current baseline diff. Continue only after the bridge returns the updated write task and lease.
|
|
@@ -48,9 +48,9 @@ A task that is still open blocks the switch, and says so plainly. Its lease, its
|
|
|
48
48
|
|
|
49
49
|
Ask whether the current repository belongs to an existing accessible project, should become a new project, or should skip Engineering Memory for this task. When an existing project is chosen, present only projects returned for the authenticated user. Confirm before writing the marker.
|
|
50
50
|
|
|
51
|
-
For a
|
|
51
|
+
For a repository the backend has not seen before, ask whether this is an existing codebase import or a greenfield project. Before a marker or backend task exists, an existing-codebase import may perform one bounded local read-only structural and Figma discovery pass. It must not edit code. Use the findings in a native questionnaire to confirm the initial project profile and the repository-relative patterns that identify new memory resources. Send them as `discoveryUnits`, one unit per kind the project actually has: a client project declares `screen_logic` and `component_mapping`, and a server-side project declares `module_logic`, `data_model` and `api_endpoint` against its own layout. Never ask a server-side project for screen patterns, and never invent a unit for a kind the repository does not contain. Then call `project.setup`; the backend creates the project, owner membership, active profile revision, and pinned discovery policy atomically. Write the returned marker only after that succeeds, then start the normal `session.bootstrap` lifecycle. Later discoveries are reviewable memory proposals.
|
|
52
52
|
|
|
53
|
-
Greenfield setup asks for project name, framework, Figma library and screen links if available, design token sources, page architecture
|
|
53
|
+
Greenfield setup asks for project name, framework, the response envelope, the exception model, authentication needs, localization languages, storage policy, and the initial discovery patterns. A client project is also asked for the Figma library and screen links if available, the design token sources, the page architecture and the navigation pattern; a server-side project is asked instead for the data layer, the migration tool and how configuration and secrets arrive. Ask what the project is before deciding which list applies. Never invent missing answers. Do not write a marker unless the setup response contains the active initial profile and discovery policy.
|
|
54
54
|
|
|
55
55
|
After setup, ask whether to build the project from the organization architecture templates. If the user accepts, follow `scaffolding.md`: confirm the optional modules, then confirm the package name and the concrete class name behind every rename placeholder in one questionnaire, then ask for each required asset role and each tenant-specific value the templates deliberately leave open.
|
|
56
56
|
|