engineering-memory 1.5.0 → 1.6.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "engineering-memory",
-  "version": "1.5.0",
+  "version": "1.6.0",
   "description": "Installs the Engineering Memory skill and its local MCP bridge. Sign in after installing; your organization and project are resolved from your account.",
   "license": "UNLICENSED",
   "type": "module",

package/skill/references/lifecycle.md

@@ -74,6 +74,27 @@ Temporary code written to reach or force a path — a pinned state, a fixed serv
 
 Do not write task Markdown files directly. The bridge owns event IDs, expected task versions, atomic projections, outbox state, and synchronization.
 
+## Adopting a Project That Already Exists
+
+A repository bound with a working system in it can be surveyed at any time, not only at the moment
+it is bound. When the user asks for its architecture to be learned, read, recorded or understood,
+that is a survey: open it as a read-only task and follow `engineering-core.adopting-an-existing-project`,
+which says what a survey records and what it must never do.
+
+Four things come out of it and nothing else: the discovery policy that matches the repository's
+actual layout, the architecture already in place recorded on the project profile under
+`architecture.adopted` with the pressure each structure relieves — or `inherited, reason not
+recorded` where nobody knows — one module record per module saying what it owns, and one current
+deviation per divergence, each carrying what the rule says, what the project does, both costs, and
+a decision or an explicit deferral. Everything else is written as later tasks reach it.
+
+The survey changes nothing in the tree. No formatting, no renames, no tidying of dead code it
+finds; leftovers are recorded as observations and decided like any other divergence.
+
+Where the same product has a client and a backend, they are two projects. Adopt them separately,
+then link them with `project.link` once both exist, and ask before linking rather than inferring it
+from the names.
+
 ## Change Preparation
 
 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.

package/skill/references/questionnaires.md

@@ -48,9 +48,9 @@ A task that is still open blocks the switch, and says so plainly. Its lease, its
 
 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.
 
-For a new backend project, 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 `screenPathPatterns` and `componentPathPatterns` that identify new memory resources. 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.
+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.
 
-Greenfield setup asks for project name, framework, Figma library and screen links if available, design token sources, page architecture, backend response envelope, exception model, authentication needs, localization languages, storage policy, navigation pattern, and the initial screen and component path patterns. Never invent missing answers. Do not write a marker unless the setup response contains the active initial profile and discovery policy.
+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.
 
 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.