allwright 1.99.0 → 1.99.1

package/bin/allwright.js

@@ -1270,6 +1270,7 @@ ${r.slice(0,4e4)}
 `:"Produce FIRST a fenced block with the UI DIRECTION document:\n```direction\n# UI direction\n- Palette (hex values, light/dark stance), typography (real font stacks), spacing/density, component inventory (tables, forms, nav shape), and the 3-5 design decisions that make THIS product's daily work faster. Under 700 words.\n```\n")+'Then a fenced block listing EVERY screen the finished product needs - enumerate the legacy frontend\'s routes/pages/menus AND the SPEC completely (a real product usually has 15-40; list them ALL), as JSON:\n```inventory\n[{"name":"Dashboard","note":"one line on what it is for"}, \u2026]\n```\nNames are identifiers - short, stable, unique. Do NOT write any screen HTML in this answer; screens are drawn separately, one at a time.',bR=`Each screen: ONE self-contained HTML file - all CSS inline in a <style> tag, realistic data from the product's own domain (never lorem), desktop layout that degrades sanely, NO external requests (no CDNs, no fonts, no images - use CSS shapes and unicode). NO <script> tags and NO on* attributes - they are stripped before display. The mockups are CLICKABLE like a Figma prototype, with two devices only:
 - Navigation: any element that would take the user to another screen gets data-screen="<exact inventory name>" (nav items, buttons, table rows, links - href="#" is fine, the attribute does the work). Use them everywhere navigation is implied.
 - Popups/modals/menus: draw them in the same file, hidden, opened with CSS :target - <a href="#new-invoice">New invoice</a> opens <div id="new-invoice" class="modal"> via .modal{display:none} .modal:target{display:flex}, with a close link href="#".
+SCOPE DISCIPLINE: draw ONLY what the screen's job needs. A simple screen stays simple - a login or forgot-password screen is its fields and a button, not a dashboard; do not invent panels, stats, tips or widgets the legacy code or the details document never had. A list screen gets its real table and filters; a form gets its real fields. Density should match the REAL screen's job - when in doubt, less.
 These are design artifacts the build will consume - clean, consistent, on the direction.`,wR=(t,e,n,r)=>`You are documenting ONE screen of a legacy product being rebuilt. The legacy frontend code may be in your working directory - READ it and write facts from the code, not guesses; where the code answers nothing, say "not found in the legacy code" rather than inventing.
 
 THE SCREEN: "${t}"${e?` - ${e}`:""}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "allwright",
-  "version": "1.99.0",
+  "version": "1.99.1",
   "description": "Allwright \u2014 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",