command-code 0.40.16 → 0.41.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "command-code",
-  "version": "0.40.16",
+  "version": "0.41.0",
   "description": "Command Code, coding agent that continuously learns your coding taste",
   "type": "module",
   "main": "dist/index.mjs",

package/skills/design/SKILL.md

@@ -324,6 +324,8 @@ You're not making it "work on mobile." You're orchestrating the same story on di
 - **Container queries are the next decade.** Components should respond to their container, not the page. The same `<Card>` adapts in a sidebar (narrow), in main content (medium), and in a wide split-view (full).
 - **Adapt the interface, never amputate the feature.** "Not available on mobile" is a bug.
 - **Notch handling via `env(safe-area-inset-*)` and `viewport-fit=cover`.**
+- **Direction is a layout input, not a CSS afterthought.** Build with logical properties (`start`/`end`, not `left`/`right`) so `dir="rtl"` renders Arabic, Hebrew, Farsi, and Urdu correctly. Mirror icons that encode reading direction (back arrows, chevrons); leave universal icons (play, checkmark, brand mark) alone. Full guidance: [references/responsive.md](references/responsive.md#text-direction).
+- **iOS Safari input zoom:** Any `input`, `select`, or `textarea` with font-size below 16px triggers automatic viewport zoom on focus, breaking layout. Form elements need at least `1rem` on screens under 640px. Never use `maximum-scale=1` to suppress it — that disables pinch-to-zoom for all users. Full guidance: [references/responsive.md](references/responsive.md#ios-safari-input-zoom).
 
 ### Copy is Voice
 

package/skills/design/references/checkup.md

@@ -58,7 +58,7 @@ I look at six vital signs.
 
 **Usability**: Can the primary task be completed with the available controls?
 
-**Responsiveness**: Does the surface adapt across width, input mode, zoom, and safe areas?
+**Responsiveness**: Does the surface adapt across width, input mode, zoom, safe areas, and text direction (RTL renders correctly where the product supports it)? On narrow screens, do all `input`, `select`, and `textarea` elements use at least 16px font-size (sub-16px triggers iOS Safari auto-zoom on focus)? Fix guidance: [responsive.md](responsive.md#ios-safari-input-zoom).
 
 **Speed**: Does it load and respond without visible hesitation, shift, or jank?
 

package/skills/design/references/create.md

@@ -116,7 +116,7 @@ I don't ask about these. I just decide:
 - Micro-timing on every interaction
 - Empty state copy, error message tone, loading indicator choice
 - Which reference files to pull
-- How to handle edge cases — long strings, zero items, overflow, RTL
+- How to handle edge cases — long strings, zero items, overflow, RTL (see [responsive.md](responsive.md#text-direction) if the brief names a right-to-left locale)
 - Whether a motion adds clarity or just noise
 
 If I'm unsure on a style call, I pick the stronger option and move forward.

package/skills/design/references/finish.md

@@ -76,6 +76,8 @@ I do not polish the happy path while the edge states rot.
 
 **Mobile behavior** that does not crush, hide, or overflow.
 
+**iOS Safari input zoom**: every `input`, `select`, and `textarea` uses at least `1rem` (16px) font-size on narrow screens, a sub-16px form element triggers iOS Safari auto-zoom on focus, breaking layout. Fix guidance: [responsive.md](responsive.md#ios-safari-input-zoom).
+
 **Performance feel**: no obvious shift, lag, oversized media, or janky motion.
 
 **Copy** that is specific, calm, and consistent.
@@ -146,6 +148,7 @@ The report does not decide for me. It points to places I should verify.
 - Performance feels stable
 - Nothing obvious makes me wince
 - The remaining issues, if any, are explicit tradeoffs, not neglected details
+- Form inputs use at least 16px font-size on mobile — iOS Safari auto-zoom does not fire on focus
 
 STRICT RULE — NEVER BREAK THIS
 Do not create report.md, any kind of report, summary, analysis file,

package/skills/design/references/interaction.md

@@ -87,6 +87,14 @@ If a feature only exists on hover, it does not exist for touch users.
 
 ---
 
+## Direction-Aware Controls
+
+On a product that supports RTL languages, controls that encode reading direction must mirror: back/forward navigation, chevrons, breadcrumbs, carousels, swipe-to-dismiss, and drag handles aligned to text flow. Controls with universal meaning do not: play/pause, checkmarks, the brand mark, media scrubbers.
+
+I check this with the actual `dir="rtl"` rendering, not by eyeballing the LTR version. Logical sizing and spacing belong in layout; see [responsive.md](responsive.md#text-direction).
+
+---
+
 ## Keyboard Path
 
 A complete keyboard path is a product feature.
@@ -105,6 +113,8 @@ Labels stay visible. Placeholders show examples, not identity. Required fields a
 
 Every error answers what happened and how to recover. Blame is forbidden.
 
+On mobile, I verify every `input`, `select`, and `textarea` uses a font-size of at least 16px. A sub-16px form element triggers iOS Safari auto-zoom on focus, shifting layout and forcing the user to pinch back — it breaks the interaction, not just the visuals. Fix guidance and the specificity gotcha: [responsive.md](responsive.md#ios-safari-input-zoom).
+
 ---
 
 ## Overlays
@@ -161,6 +171,7 @@ Failure keeps the user's work. Recovery is visible. Retry is available when retr
 - Overlays close and return focus correctly
 - Form errors help without punishing
 - The interface feels responsive even during waits
+- Form inputs on mobile use at least 16px font-size — no iOS Safari auto-zoom on focus
 
 STRICT RULE — NEVER BREAK THIS
 Do not create report.md, any kind of report, summary, analysis file,

package/skills/design/references/layout.md

@@ -138,6 +138,7 @@ Viewport rules still matter for page shell decisions. Component composition belo
 - Important content placed where the eye only finds it by accident
 - Testimonials, proof, or calls to action dropped in by formula
 - Horizontal overflow treated as a mobile detail
+- Composition built only for left-to-right reading when the product needs to support RTL languages — see [responsive.md](responsive.md#text-direction)
 
 ---
 

package/skills/design/references/refine.md

@@ -118,7 +118,7 @@ I know it worked when the path is faster and the remaining elements feel inevita
 
 Proofing means the interface survives reality.
 
-I test long names, empty content, huge lists, extreme numbers, slow networks, offline states, permissions, rate limits, validation failures, concurrent actions, RTL, CJK, accents, emoji, and translated strings.
+I test long names, empty content, huge lists, extreme numbers, slow networks, offline states, permissions, rate limits, validation failures, concurrent actions, RTL (see [responsive.md](responsive.md#text-direction)), CJK, accents, emoji, and translated strings.
 
 I expect German to expand. I expect a user to click twice. I expect the API to fail. I expect a tiny screen and a huge one. I expect data to be missing.
 

package/skills/design/references/responsive.md

@@ -98,6 +98,42 @@ Stylus and hybrid devices need both touch generosity and pointer precision.
 
 ---
 
+## iOS Safari Input Zoom
+
+On iOS Safari, focusing any `input`, `select`, or `textarea` with a font-size below 16px triggers an automatic viewport zoom. The page widens, horizontal scroll appears, and the user must pinch back to normal. This is a silent layout break.
+
+I check all form elements at the narrow breakpoint. If font-size is below `1rem` (16px) on screens under 640px, I flag it and correct it.
+
+**Specificity warning:** A bare type-selector rule like `input { font-size: 1rem }` loses to any utility class (e.g. Tailwind's `text-sm`). A class selector has higher specificity (0,1,0) than a type selector (0,0,1), so the computed font size remains 14px and iOS Safari still auto-zooms. A rule that does not win the cascade is not a fix.
+
+**Fix — replace the utility with a responsive variant:**
+
+In Tailwind, swap `text-sm` for `text-base sm:text-sm` on every affected form element. The mobile breakpoint stays at 16px; desktop keeps 14px. No global CSS needed, no specificity fight.
+
+```html
+<!-- before -->
+<input class="text-sm" />
+
+<!-- after -->
+<input class="text-base sm:text-sm" />
+```
+
+In vanilla CSS projects with no utility classes, a plain media query works because nothing is fighting the type selector:
+
+```css
+@media (max-width: 639px) {
+  input, select, textarea {
+    font-size: 1rem;
+  }
+}
+```
+
+For third-party or generated components where the class cannot be changed, flag it as a component-level issue to address at the source. Do not reach for `!important` — it breaks the cascade and creates a specificity arms race.
+
+Never use `maximum-scale=1` in the viewport meta tag — it disables pinch-to-zoom for all users, which is an accessibility failure.
+
+---
+
 ## Thumb Reach
 
 On phones, the bottom of the screen is easier to reach than the top. Primary actions belong where hands naturally operate. Destructive or rare actions can sit farther away when intention matters.
@@ -126,6 +162,18 @@ Safe areas matter. Fixed controls cannot sit under notches, rounded corners, bro
 
 ---
 
+## Text Direction
+
+A product that ships Arabic, Hebrew, Farsi, or Urdu is not "the same layout, flipped by the browser." Direction is a layout input, the same as viewport or input mode.
+
+I set `dir="rtl"` (or `dir="auto"` per field) at the right scope and build with logical CSS, not physical sides: `margin-inline-start/end`, `padding-inline-start/end`, `border-inline-start/end`, `inset-inline-start/end`, `text-align: start/end`. In Tailwind, that is `ms-/me-`, `ps-/pe-`, `border-s/border-e`, `start-/end-`, `text-start/text-end` instead of `ml-/mr-`, `pl-/pr-`, `border-l/border-r`, `left-/right-`, `text-left/text-right`. Flex and grid order, `justify-start/end`, and `divide-x` (paired with `rtl:divide-x-reverse`) follow direction automatically once the ancestor has `dir` set — I don't hand-mirror markup for these.
+
+Not everything flips. Icons that encode reading direction — back/forward chevrons, reply/forward arrows, progress and breadcrumb arrows, drag handles aligned to text flow — mirror in RTL. Icons that encode a universal meaning — play, pause, checkmarks, the brand mark, a clock face, a video timeline scrubber, charts and graphs — stay fixed. Numerals, phone numbers, and embedded LTR content (code, URLs, Latin brand names) stay LTR even inside an RTL paragraph; that's what `dir="auto"` or a `<bdi>` wrapper is for, not a layout hack.
+
+I test the actual rendered RTL surface, not just the LTR one with a mental flip. Mixed-direction text (an English product name inside an Arabic sentence), numerals in dates and prices, and long Arabic/Hebrew words at narrow widths are where this breaks first.
+
+---
+
 ## Responsive Type
 
 Product UI keeps predictable type scales. Brand display can be fluid. Body text remains readable, not theatrical.
@@ -157,6 +205,10 @@ I do not mix strategies randomly on the same table.
 - Safe-area ignorance on fixed bars
 - Device detection when feature detection is the real need
 - Fluid type in dense product UI because it seems modern
+- Hardcoded `left`/`right`, `ml-`/`mr-`, `pl-`/`pr-` instead of logical start/end on a product that supports RTL languages
+- Mirroring an icon that carries universal meaning (play, checkmark, brand mark) just because the page is RTL
+- Input, select, or textarea elements with font-size below 16px on narrow screens — iOS Safari zooms the viewport on focus, breaking layout
+- Using `maximum-scale=1` in the viewport meta tag to suppress iOS zoom — it disables pinch-to-zoom for all users
 
 ---
 
@@ -172,6 +224,8 @@ I do not mix strategies randomly on the same table.
 - Safe areas protect fixed controls
 - Dark, reduced-motion, high-contrast, and zoom states remain usable
 - Tables keep their data meaning
+- RTL locales render mirrored where direction carries meaning and fixed where it doesn't, with logical CSS doing the work
+- All input, select, and textarea elements use at least 16px font-size on narrow screens — no iOS Safari viewport zoom on focus
 
 STRICT RULE — NEVER BREAK THIS
 Do not create report.md, any kind of report, summary, analysis file,