engineering-memory 1.10.3 → 1.10.5

package/skill/references/lifecycle.md

@@ -83,26 +83,51 @@ 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.
+## Four-mode project onboarding
+
+Use `references/project-onboarding.md` and `engineering-core.adopting-an-existing-project` for the
+full flow. Project creation asks through a native questionnaire for `greenfield`, `adopt`, or
+`rework`; later incremental work is `refresh`. Read-only maturity analysis can recommend a mode but
+cannot select one. Adopt, rework discovery, and refresh use committed `HEAD` by default, walk an
+exhaustive cross-stack source inventory, and classify results as evidence, inference, or unknown.
+The inventory covers frontend pages, navigation, state, service classes and network layers; backend
+modules, services, data and API endpoints; project architecture; and the contracts connecting both
+sides.
+
+Greenfield applies compatible organization architecture modules and gates them with the real local
+toolchain. Adopt and refresh never modify source. Rework asks per project whether the target keeps
+behavior or redesigns it before proposing phased branches and tasks. Existing membership, active
+user, tenant scope, explicit assignments, Project-first strongest-lock-first ordering, supplied
+`EntityManager` transactions, immutable revisions and scope authority remain in force.
+
+The implemented onboarding operations are `project.inspect`, `project.initialize`, `memory.source`,
+`memory.sync_start`, `memory.sync_status`, `memory.sync_inventory`, `memory.sync_plan`,
+`memory.sync_next`, `memory.sync_submit`, `memory.sync_reopen`, `memory.sync_delta`,
+`memory.sync_verify`, `memory.catalog`, `memory.read_revisions`, and `memory.review_batch`.
+`memory.sync_start` snapshots a selected Git ref, persists its commit/tree/manifest hashes and file
+count, and uploads all manifest pages including exclusions. `memory.source` serves only bounded pages
+or exact file reads from that committed snapshot. `memory.sync_status` lists runs or paged units and
+coverage counters without exposing claim tokens.
+
+`memory.sync_plan` uploads semantic units and their paths and dependency keys. The initial plan must
+cover included and removed behavior, but analyzing may add newly discovered cross-module flow units.
+Existing unit identities and definitions remain immutable; every added unit needs the same complete
+submission, exact memory approval references and final verification before the run can complete.
+`memory.sync_next` claims a distinct unit for 15 minutes;
+the saved claim token explicitly resumes or renews that claim. `memory.sync_submit` records evidence,
+all behavior facets, gaps and exact proposal or unchanged revision references. No unit is autoapproved,
+and no historical task or motivation may be invented. Rejected or gapped unfinished units use
+`memory.sync_reopen` with the current expected version. `memory.sync_delta` compares a completed prior
+run's content hashes, memory revisions and transitive dependencies.
+
+`memory.review_batch` displays full proposal texts before a durable native questionnaire records the
+exact proposal IDs, content digests and base revisions. Pending or dismissed approval writes nothing;
+stale batches fail atomically. `memory.sync_verify` requires sealed inventory, complete semantic and
+removed-file coverage, submitted evidence, no unresolved gaps or failed unknown execution, and
+approved immutable references for changed memory. `questionnaire.ask` and `questionnaire.resume`
+support `preparation: true` for missing-folder decisions; `project.initialize` uses that native
+confirmation before preparing the folder and Git repository. Raw secrets, headers, customer payloads
+and PII are never uploaded.
 
 ## The Task Baseline
 

package/skill/references/project-onboarding.md

@@ -0,0 +1,159 @@
+# Project onboarding and memory refresh
+
+## Choose the journey before changing the repository
+
+Call `project.inspect` for the selected directory, including a missing directory. Its maturity
+classification is `missing`, `empty`, `scaffold` or `established`, supported by manifests and
+architecture/state/service/network/data/screen evidence. These are observations, not a mode choice.
+Explain the appropriate options to the user and use `project.onboard` (or `project.initialize` for
+initial Git preparation). The tool opens native forms for the actual mode and profile; do not write
+an answer in chat or infer a choice from the directory classification.
+
+The modes are `greenfield`, `adopt`, `rework` and `refresh`. Initial onboarding offers the first three;
+refresh is available for a selected existing project at any later time. Recognize the user's intent
+semantically in their own phrasing, with no keyword trigger table. Rework asks preserve or redesign
+explicitly. Choosing another mode than the proposed input returns that choice without changing files;
+repeat with the same requestKey and the user's selected mode.
+
+Use a stable requestKey per onboarding occurrence. Profile answers must be collected with native
+forms; each independent field is reviewed separately with its current value visible. The user may
+keep it, explicitly defer it, or request an edit in the same bounded native text field. An edited value
+is persisted as part of the exact decision and reaches the final profile digest; it cannot be silently
+replaced by a later chat value. The onboarding forms confirm the exact
+stack/runtime/architecture, service/API/auth/storage/environment choices and existing backend project
+IDs. For Flutter/React they additionally confirm Figma, color palette, font families and text styles,
+design system, navigation, platforms and languages; for Nest/Spring they confirm migration strategy.
+An explicit absence or deferral is acceptable; a made-up answer is not.
+The local machine's installed runtime is validation capability, not an architecture preference.
+
+`project.initialize` only prepares Git for the approved greenfield mode. It supports missing, empty
+and barely-started non-Git directories without overwriting existing files; parent repositories and
+symbolic links are protected. Choices persist in user-local Engineering Memory state outside the
+repository and installed package. After creating/selecting the backend project, pass projectId to
+`project.onboard` to store its exact choice in the project onboarding history. Include the confirmed
+profile in the normal project/profile proposal; onboarding choices do not independently activate
+engineering rules. `project.onboarding_status` reads those choices and any rework plans. Old projects
+remain uninspected until they opt in.
+
+If a native form is pending, preserve its identifier and resume it. A wizard can return the next
+pending form after one answer is accepted; complete that form and call the originating onboarding
+operation again to advance. Restart reuses answered questions and exact choice data. It never assumes
+approval after a cancellation, empty response or timeout.
+
+## Greenfield architecture and links
+
+Prepare and bind the repository through the existing project.setup flow, then use architecture.plan
+and architecture.module with the approved project profile. Apply the matching Flutter, React, NestJS
+or Spring templates through the scaffold task lifecycle. Replace technical demonstration inputs with
+approved application profile values; a compile fixture is not a user product or a ready live API.
+Flutter exposes injected service/transport, state lifecycle and cancellation, storage boundary,
+navigation and profile-controlled palette/typography. Validate the actual selected toolchain.
+
+List authorized backend/frontend projects when services may already exist. Offer the actual selected
+project IDs in the native profile form. Create approved links with project.link; a selection alone
+never changes a link, and fullstack discipline never replaces membership or link authority. Keep
+unavailable service contracts explicit rather than inventing endpoint behavior.
+
+## Durable deep learning
+
+Adopt, refresh and the learning stage of rework do not modify application source. They inventory and
+learn the whole architecture: modules, service classes, network and API contracts, state management,
+persistence/data models/migrations, navigation, screens/components, localization, deployment,
+authentication, runtime/toolchain and cross-module/end-to-end flows. Record source facts, tested
+behavior, inference and unknown historical reasons separately. Never fabricate historical tasks,
+prior developer decisions or reasons the code cannot establish.
+
+1. `memory.sync_start` opens a durable native confirmation bound to the mode, committed source hash
+   and previousRunId/rework behavior. Only acceptance starts the run. It snapshots the selected HEAD
+   or explicit ref, uploads every manifest page with exclusion reasons and seals the inventory.
+   Dirty worktree changes never silently enter shared memory. Repeating an occurrence reuses its key;
+   another commit requires a new occurrence and its own exact confirmation.
+2. `memory.source` pages the committed manifest or bounded chunks of one exact-commit file. Follow
+   nextCursor/nextOffset until null. Exclusions are reviewable evidence; inspect suspicious exclusions
+   and correct the classifier rather than declaring an incomplete project fully learned. Large owned
+   files remain in scope; bounded Git reads at the same commit can supplement the tool.
+3. `memory.sync_plan` creates meaningful semantic units with module keys, knowledge kinds, source
+   paths and dependency unit keys. Declare applicable architecture/state/services/network/data/UI/flow
+   areas and justify absence with source evidence. File coverage is necessary but does not certify
+   semantic understanding. Do not collapse an application into a generic all-files summary.
+4. `memory.sync_next` leases one unit for fifteen minutes. Save claimToken and use distinct requestKeys
+   for parallel workers; retry the same key after response loss. `memory.sync_status` exposes progress
+   and missing units without exposing another worker's token. No database transaction spans analysis.
+5. `memory.sync_submit` attaches per-path source or actual execution evidence and explicit findings
+   for entry, exit, authority, effects, errors, cancellation, retry, persistence and dependencies.
+   Link concrete witnesses; lack of applicability needs evidence and a reason. A source read and a
+   successful test are separate claims. Automated structural checks cannot prove the prose is true;
+   review the complete module package against actual code and tests before approval.
+6. Reuse the normal KnowledgeResource → pending Proposal → immutable Revision model. Present complete
+   module records, source evidence, uncertainty, deviations and archival actions. `memory.review_batch`
+   binds native approval to exact IDs, content hashes and base revisions, and reviews atomically under
+   existing authority. Deferring makes no change; when the user wants to reconsider, use its returned
+   nextReviewAttempt. Retrying the old attempt preserves the deferral, not an invented approval.
+7. `memory.sync_reopen` uses expectedVersion to repair an unfinished unit. `memory.sync_verify` requires
+   sealed inventory, source/removed-path and declared-area coverage, valid evidence, resolved gaps and
+   approved exact memory references. It cannot replace the Git diff gate for any source-writing task.
+
+## Incremental refresh and Git evidence
+
+Use a completed previousRunId. `memory.sync_delta` refuses an unsealed new inventory and pages changed
+units and dependent flows. With repoRoot on the first page it adds bounded Git history/rename evidence;
+`memory.source` with previousCommit and commit can read further source change pages. Commit IDs and
+source trees establish provenance; commit messages do not establish developer intent. Squash or
+rewritten/missing history falls back explicitly to the persisted file/blob comparison. A missing
+commit is not proof of zero changes.
+
+Review renames against existing resource identities and propose selector relocation rather than
+unnecessarily creating duplicate records. Removed behavior requires reviewed archival with the old
+identity; revision history is retained. Code deviating from a rule does not silently change that rule.
+Known changed memory invalidates its units/dependants. New records are compared against selectors;
+unscoped records may require conservative review because there is no defensible narrow scope.
+A source/memory no-op reuses approved evidence with provenance and creates no gratuitous revisions.
+
+At module boundaries read memory.sync_status with repoRoot. If newer commits exist, keep the pinned
+inspection unchanged and start a new `memory.sync_start` refresh occurrence with the follow-up commit
+and previousRunId; never silently move its baseline or call old coverage current. Read-only completion
+is a coverage decision, not an implementation verification. Long-running analysis must checkpoint its
+remaining units and decisions durably.
+
+The core pack is intentionally bounded. Linked contracts remain inline while they fit the budget; when
+the response reports `additionalMemory`, read the full authorized catalogue with
+`memory.catalog({projectId, includeLinked: true, afterId, limit})`, then use the current session with
+`memory.read_revisions` for the exact revision IDs needed by the task. Do not assume the core pack is
+exhaustive. `memory.catalog` is the paging surface for linked project memory; it does not grant access
+or change project links.
+
+For source orientation, prefer the bounded summary returned by `project.inspect` and its nested stack
+signals. Its `totalFiles`, `omittedFiles`, `prunedDirectories` and `historyTruncated` fields are part
+of the evidence: a nonzero omission or truncated history requires bounded follow-up, not a claim that
+the tree or history was fully read. Use the existing paged `memory.source` pages only for the committed
+paths and symbols required by the chosen unit; do not request or serialize an unbounded full tree.
+
+## Rework target and execution
+
+Complete deep learning first. Propose and approve target architecture in existing immutable knowledge;
+redesign also requires the intended screens, flows and API/service contracts. Build a dependency-ordered
+phase plan with acceptance criteria and branch names, covering every inspected unit by key. Present it
+in full. `project.rework_plan` opens a native form for that exact source/target/phase digest and persists
+real WorkItems and their dependencies; stale targets, incomplete learning or changed idempotency inputs
+must refuse before partial creation. Deferred plans can be submitted under a new explicit requestKey
+when the user requests review again.
+
+Each phase opens an ordinary implementation task on its recorded branch in a separate worktree where
+needed. Preserve all lease, history, reconciliation, self-review, validation, verify, close and delivery
+gates. Cross-project phases use existing work_item.plan/confirm_plan with explicit scope authorization
+and independent per-repository runs. Planning tasks does not perform their implementation.
+
+A deferred individual field or final profile saves no onboarding choice. Retrying that request preserves its deferral. When the user explicitly resumes, use the returned `nextRequestKey` for fresh native decisions; never infer approval from a previous defer.
+
+## Inspection confirmation language
+
+For memory.sync_start, pass language: tr in a Turkish conversation and language: en in an English
+conversation. Use the conversation language, never the computer locale. Legacy calls without language
+use English. The form shows a short source reference, scope, the treatment of uncommitted changes and
+the separate approval needed for permanent memory. Full commit and request hashes stay in the durable
+approval binding, not in the visible question. Generic questionnaire.ask messages and option labels
+are written by the agent in the same language; pass language for the native help and field labels.
+
+An existing exact-request questionnaire retains its original wording and answer across updates and
+restart, including an older English form. Resume that question rather than silently replacing or
+withdrawing it. Language changes never broaden the approved source, mode or previous-run scope.

package/skill/references/questionnaires.md

@@ -60,7 +60,7 @@ Switching off records the decision and ends the subject. Switching back on clear
 
 Changing the organization always means asking for the project again afterwards, because a project belongs to exactly one organization and the old answer cannot survive the change. Run the organization questionnaire, then the project one, then bind the repository to the chosen project with `project.resolve` so the local binding matches what the user just said.
 
-When the repository being bound already has a working system in it — code somebody else wrote, a shape nobody here decided — say so and offer the survey rather than starting as though the project began now. Ask whether to adopt it: read what is there, record its modules, its architecture and the discovery policy that matches its actual layout, and list where it diverges from the rules with what changing and keeping each one would cost. Do not offer a single choice between reworking the project and leaving it alone; that question is asked once per divergence, after the survey, and the adoption rule says why. The survey is a read-only task and changes nothing.
+When the repository being bound already has a working system in it — code somebody else wrote, a shape nobody here decided — present the three project creation modes. Adopt and rework both begin with the exhaustive cross-stack inventory described below; rework then asks per project whether the target preserves behavior or redesigns it. Do not offer a single choice between reworking the project and leaving it alone before the evidence exists. The inventory is read-only and changes nothing.
 
 A task that is still open blocks the switch, and says so plainly. Its lease, its journal and its checkpoints all belong to the project it was opened against, and carrying them into another one records work under a project it did not happen in. Close the open task first, or abandon it with `task.abandon` once the user has said that is what they want, and only then switch. This is about this session's own task and nothing else: another person's unfinished task in the same repository never blocks anything.
 
@@ -68,11 +68,34 @@ 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 the project selection before saving its user-local binding; no repository file is written.
 
-For a repository the backend has not seen before, ask whether this is an existing codebase import or a greenfield project. Before a local binding 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. Persist the user-local binding only after that succeeds, then start the normal `session.bootstrap` lifecycle. Later discoveries are reviewable memory proposals.
-
-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. A Spring project must also name Maven or Gradle, its Java release, its exact Spring Boot version and its `javax` or `jakarta` namespace before any architecture template is offered; `Spring Boot` alone is not enough information to select compatible source. Record those confirmed values in `initialProjectProfile.metadata.runtimeContract` as `language: "java"`, `languageVersion`, `framework: "spring-boot"`, `frameworkVersion`, `buildTool` and `namespace`. Never infer or invent this object. The backend compares it with each source module and returns no incompatible module; an absent contract means broad Spring rules still apply but no constrained source template is offered. Ask what the project is before deciding which list applies. Do not save a binding 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.
+For a repository the backend has not seen before, ask for the project mode through a native
+questionnaire: `greenfield`, `adopt`, or `rework`. Maturity inspection is read-only evidence and may
+recommend a mode, but it never selects one. Adopt and rework perform an exhaustive cross-stack source
+inventory from committed `HEAD` by default, covering frontend pages/navigation/state/service classes/
+network layers, backend modules/services/data/API, project architecture and connecting contracts.
+The agent labels evidence, inference and unknown while the backend
+persists coverage. There is no bounded survey and no source mutation. Use `project.onboard` with the confirmed mode and profile; only greenfield calls `project.initialize`
+to prepare Git. Send repository-relative discovery units through the existing project.setup/profile
+contract, not as extra initialize fields. A client declares
+`screen_logic` and `component_mapping`; a server declares `module_logic`, `data_model` and
+`api_endpoint`. Never invent a unit the repository does not contain.
+
+Greenfield setup asks for project name, framework, runtime/toolchain contract, response envelope,
+exception model, authentication, localization, storage policy and discovery patterns. A client is
+also asked for Figma and navigation context; a server is asked for its data layer and configuration
+source. Spring still requires Maven or Gradle, Java release, exact Spring Boot version and
+`javax`/`jakarta` namespace before compatible templates are offered. Never infer these values.
+Rework asks per project whether the approved target preserves behavior or redesigns it. Existing
+project membership, active user, tenant scope, explicit code/privacy assignments and scope authority
+remain in force.
+
+After setup, greenfield asks whether to build from organization architecture templates. If accepted,
+follow `scaffolding.md`. For Flutter, the template's real SDK gate must run against the local PATH
+or configured command; missing Flutter is a red result and never triggers a download. Existing
+projects may later use `refresh`, which requires confirmed natural intent and native confirmation,
+uses committed `HEAD` by default, persists resumable units, and never triggers from keywords.
+Module-batched proposal approval binds exact hashes and source revision; incomplete or stale batches
+fail, and raw secrets, headers, customer payloads and PII are excluded.
 
 ## Project Membership
 
@@ -179,3 +202,53 @@ When installing enforcement and an existing pre-commit hook is present, offer:
 - Cancel hook installation
 
 Never overwrite or delete an unknown hook.
+
+### Exact onboarding decisions
+
+Use project.onboard/project.initialize for the four-mode choice and stack-specific profile. Their
+native forms review each independent profile field with its current value visible. Keep and explicit
+deferral are durable answers; an edit uses the bounded native text field in that same question and is
+stored in the exact profile decision. Client profiles
+include Figma, palette, typography/font families/text styles, design system, navigation, platforms and
+languages. Backend profiles include API, auth, storage, migration and environments. Empty knowledge is
+an explicit absence or deferral, never a guessed preference. project.inspect returns a maturity
+classification; it does not select a mode. Choices persist locally before Git and project-wide after
+selecting a project.
+
+memory.sync_start confirms the exact committed source and mode before starting adopt/refresh/rework.
+project.rework_plan confirms an exact approved target and phase digest after learning. memory.review_batch
+reviewAttempt distinguishes a new requested review from a retry of a previously deferred batch. Do not
+turn defer into approve or loop new attempts without the user's intent to reconsider.
+
+The initial context pack may be budgeted. If it reports `additionalMemory`, use
+`memory.catalog({projectId, includeLinked: true, afterId, limit})` to page all authorized linked
+resource headers, then call `memory.read_revisions` with the current session for the exact revisions
+needed. Never assume that the core pack contains every linked record. Source inspection should begin
+with the bounded orientation summary from `project.inspect`; use paged committed-source reads for the
+units being learned.
+
+### Explicit withdrawal and initialization continuation
+
+When the user explicitly cancels the owning work, call `questionnaire.withdraw` with its exact
+identifier and repository/preparation scope. Withdrawal is durable, creates no approval, rejects late
+answers and removes only that pending question from entry/resume. A timeout or dismissed form is not
+cancellation of the work; unanswered decisions remain pending without automatic expiry. Other tasks
+can continue independently. A withdrawn workflow needs a new request key only if the user starts it
+again.
+
+`project.onboard` can save the profile before initialization. Calling `project.initialize` with the
+same request key reuses the profile answers and asks a separate exact Git-initialization confirmation.
+Saving a profile does not authorize filesystem initialization.
+
+## Inspection confirmation language
+
+For memory.sync_start, pass language: tr in a Turkish conversation and language: en in an English
+conversation. Use the conversation language, never the computer locale. Legacy calls without language
+use English. The form shows a short source reference, scope, the treatment of uncommitted changes and
+the separate approval needed for permanent memory. Full commit and request hashes stay in the durable
+approval binding, not in the visible question. Generic questionnaire.ask messages and option labels
+are written by the agent in the same language; pass language for the native help and field labels.
+
+An existing exact-request questionnaire retains its original wording and answer across updates and
+restart, including an older English form. Resume that question rather than silently replacing or
+withdrawing it. Language changes never broaden the approved source, mode or previous-run scope.

package/skill/references/scaffolding.md

@@ -6,12 +6,21 @@ Architecture templates are source modules stored as approved engineering memory.
 
 Engineering rules, quality gates and architecture templates all live on the organization. A project created in a fresh organization inherits none of them.
 
-Call `organization.list` and ask the user which organization the project belongs to before `project.setup`. Creating a new organization is a separate, explicit choice: state plainly that the project will start with no engineering core and no architecture templates, and pass the acknowledgement only after the user confirms that.
+Call `organization.list` and ask the user which organization the project belongs to before
+`project.setup`. If the repository folder is missing, use `questionnaire.ask` or
+`questionnaire.resume` with `preparation: true`; `project.initialize` asks the native confirmation
+before creating the folder and Git repository. Each initialization occurrence carries a unique
+`requestKey`; retries reuse that key, while a new occurrence cannot be authorized by an old answer.
+Preparation question wording omits personal absolute paths from the stored question. Creating a new organization is a separate, explicit
+choice: state plainly that the project will start with no engineering core and no architecture
+templates, and pass the acknowledgement only after the user confirms that.
 
 ## Apply sequence
 
 1. Open the task in `scaffold` mode and complete the normal bootstrap, discovery and `context.prepare_change` steps. Prepare the full set of intended paths before the first write.
-2. Call `architecture.plan`. It returns each module's manifest in apply order with its dependencies, rename map, string replacements, pubspec dependencies, asset contract and tenant-specific points. It carries no file bodies.
+2. Call `architecture.plan`. It returns each module's manifest in apply order with its dependencies,
+   rename map, string replacements, package dependencies, asset contract and tenant-specific points.
+   It carries no file bodies.
 3. Present the optional modules through the native questionnaire. A package-shaped project usually skips the application modules; an application usually takes them.
 4. Treat the modules returned by the backend as the compatibility boundary: it compares each manifest's `compatibility` object with the approved project profile `runtimeContract` before returning it. Read both contracts back and confirm them in the questionnaire; never add a module the plan withheld or substitute a conversational guess. For Spring, the comparison covers Java release, exact Spring Boot release line, build tool and `javax` or `jakarta` namespace. If the plan is empty, say that no compatible starter exists and continue without scaffolding; never upgrade or downgrade the project to make a template fit.
 5. Confirm the naming decisions in one questionnaire: package name and the concrete class name behind every rename placeholder. Never invent a name the user did not choose.
@@ -19,7 +28,7 @@ Call `organization.list` and ask the user which organization the project belongs
 7. Merge every module's `packageDependencies` into the project's dependency manifest — `pubspec.yaml`, `package.json`, whatever the stack uses. Keep the existing constraint when a dependency already exists and report the conflict.
 8. Satisfy the `assetContract`. Ask the user for each required asset role. Never invent an asset, never ship a placeholder binary, and never copy a licensed font from another project.
 9. Resolve every `tenantSpecific` point through the questionnaire: base URLs, backend header contracts, storage key prefixes, supported locales, bundle identifiers. These are deliberately absent from the template. Do not guess them.
-10. Run the stack's generator, compiler or type checker against every emitted source file before calling the scaffold complete. If the required local compiler is unavailable or below the selected template's declared release, stop with the exact tool and version needed rather than claiming the source is valid. This refusal applies only to applying that template, not to using Engineering Memory with an existing project. Then run code generation, localization generation, static analysis and tests that the project requires.
+10. Run the stack's generator, compiler or type checker against every emitted source file before calling the scaffold complete. If the required local compiler is unavailable or below the selected template's declared release, stop with the exact tool and version needed rather than claiming the source is valid. This refusal applies only to applying that template, not to using Engineering Memory with an existing project. Then run code generation, localization generation, static analysis and tests that the project requires. The shipped Flutter gate runs the local SDK's `pub get`, `analyze --no-pub` and `test --no-pub`; it accepts `ENGINEERING_MEMORY_FLUTTER_COMMAND` for a Windows `.bat` launcher and never downloads an SDK.
 11. Reconcile each applied template resource with a `scaffold_applied` reconciliation carrying a short reason, then run `task.verify`.
 
 ## What scaffold mode does and does not relax
@@ -34,6 +43,6 @@ Write the first real unit of work — a screen, a resource — as a separate `wr
 
 When a task establishes a new shared architecture structure, or changes one the templates carry, the template is now stale. Propose the template revision through `memory.propose_revision` with `scope: organization` and `kind: architecture_template`, and let the user approve it like any other permanent memory change.
 
-A template revision must keep its manifest and its content in step: every `## file:` block has a matching `files[]` entry with the same path, byte count and SHA-256, in the same order. The backend rejects a revision whose manifest and content disagree.
+A template revision must keep its manifest and its content in step: every `## file:` block has a matching `files[]` entry with the same path, byte count and SHA-256, in the same order. The backend rejects a revision whose manifest and content disagree. Product defaults are parsed from front matter into `architecture-template/v1`: `scope` is product or organization, `stack` and `moduleKey` are lowercase slugs, `applyOrder` is an integer, `dependsOn` contains lowercase module slugs, `packageDependencies` is a valid `name@constraint` list, and every fenced file block is represented exactly once. `assetContract` and `tenantSpecific` default to empty arrays; they must not be simulated with placeholder assets or hidden template tokens. Validate defaults with the backend product-default loader/parser as well as a compiler.
 
 Templates carry source, not secrets. Never place a real base URL, token, customer payload, licensed binary or personal path in a template revision.