allwright 1.108.0 → 1.109.0

package/bin/allwright.js

@@ -1298,6 +1298,7 @@ Target architecture & stack: concrete choices, with one line of why each.
 Scope: what is IN the rebuild; what is deliberately OUT (with why).
 Modules & behaviour: EVERY module/area in scope, with the concrete behaviour the rebuild must honour - fields with their validations and conditional visibility, status transitions (each status field separately when there are several), permission/role gates per action, every flag that branches behaviour with BOTH branches spelled out, naming/suffix conventions, single-vs-bulk differences, import/export rules. Carry these forward from the understanding and requirements documents - list the rules themselves, never a heading that gestures at them. This is the SPEC's longest section by design.
 Data: how the legacy data maps on - what carries over, what dies.
+Testing strategy: how the rebuild proves itself and keeps proving itself - CHARACTERISATION tests pinning the legacy behaviour BEFORE any port (same fixtures against old and new); unit tests for the logic the new architecture makes testable; API/integration tests carrying the acceptance criteria; a SMALL end-to-end suite for the few costliest flows, named here - never blanket coverage; all of it run on every change (CI). Say what the schema now enforces and therefore needs no test. The ticket breakdown must honour this: characterisation tests are their own ticket sequenced BEFORE the port work, and every build ticket carries its own tests.
 Risks: what could sink this, from evidence in the study.
 `+(e.length?`Open gaps: these inputs were NOT available - name what the plan assumes because of each, so the reader knows what to provide next:
 ${e.map(r=>`- ${r}`).join(`
@@ -1407,6 +1408,8 @@ Answer with exactly one fenced block:
 # Tech stack
 ## Recommendation
 - one line per layer: frontend, backend, database, hosting/infra, integrations - the concrete choice, version-current
+## What stays, what changes
+- per layer: KEPT, upgraded, rewritten or replaced - in plain words the person deciding can follow without being an engineer: what happens to the working domain logic, how building a feature changes day to day after the move, and THE one choice that moves cost the most, named as such
 ## Why this fits THIS product
 - reasoning anchored in the spec/legacy evidence (team realities, data shapes, integrations, migration path) - never generic praise
 ## Alternatives considered
@@ -1416,7 +1419,7 @@ Answer with exactly one fenced block:
 ## Open questions
 - what the person confirming should decide or verify
 \`\`\`
-Under 1200 words. Concrete names and versions, honest trade-offs.`,sv=(t,e,n,r,s,i)=>`You are designing ONE screen of a product whose UI direction is already decided. Follow the direction exactly - same palette, same type, same components - so this screen sits beside the existing set seamlessly. The legacy frontend code may be in your working directory for reference.
+Under 1400 words. Concrete names and versions, honest trade-offs.`,sv=(t,e,n,r,s,i)=>`You are designing ONE screen of a product whose UI direction is already decided. Follow the direction exactly - same palette, same type, same components - so this screen sits beside the existing set seamlessly. The legacy frontend code may be in your working directory for reference.
 
 `+(i?"A FINISHED screen of this product is below. Its SHELL - the sidebar/menu (same items, same order, same markup), header, fonts, colors, spacing tokens - is the product's shell: COPY it verbatim, mark this screen's own nav item active, and design ONLY the content area. Two screens of one product never get two different menus.\n\n```html\n"+i.slice(0,12e4)+"\n```\n\n":"")+`THE DIRECTION:
 ${n.slice(0,4e4)}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "allwright",
-  "version": "1.108.0",
+  "version": "1.109.0",
   "description": "Allwright — the AI teammate that runs on YOUR machine. Polls your Jira, runs jailed agents in your local checkouts, opens PRs, executes approved deploys, and audits security/testing/architecture. Credentials and code never leave your host.",
   "bin": {
     "allwright": "bin/allwright.js",