@mmerterden/multi-agent-pipeline 13.5.0 → 14.0.0

package/pipeline/skills/shared/external/ios-coding-standard/references/rules.yml

@@ -1,9 +1,33 @@
-version: 1.0.0
-updated: 2026-07-26
+version: 1.1.0
+updated: 2026-07-29
 owner: iOS platform
 description: >
-  The rule registry. STANDARD.md teaches these to a newcomer with examples; SKILL.md audits
-  against them. IDs are stable and never renumbered  -  a rule is retired by status, not deletion.
+  The rule registry. STANDARD.md teaches these to a newcomer with examples; EXAMPLES.md carries a
+  worked ✗/✓ pair per judgement rule; SKILL.md audits against them. IDs are stable and never
+  renumbered  -  a rule is retired by status, not deletion.
+
+# What these rules may be applied to. A consumer resolves this BEFORE selecting rules,
+# and records how many it dropped and why. Without it every rule below would be applied
+# to every changed file, which on an Objective-C or UIKit diff manufactures findings and
+# buries the real ones  -  worse than declaring no coverage at all.
+#
+# Per-rule `scope:` narrows this further and never widens it. A rule with no `scope:`
+# inherits the block below.
+scope:
+  languages: [swift]
+  paths:
+    - "**/*.swift"
+  excludePaths:
+    - "**/*.generated.swift"
+    - "**/Generated/**"
+    - "**/*.pb.swift"
+  # Named so a consumer can report the gap rather than silently covering nothing:
+  # these languages appear in iOS repos and this registry does NOT speak for them.
+  notCovered:
+    objective-c: "*.m / *.mm / *.h  -  no ObjC rules exist here; report as a coverage gap, never apply Swift rules to them"
+    uikit: "UIKit view controllers are Swift, so file-level rules apply, but the UI-* family assumes SwiftUI view construction and is scoped out below"
+    c-cpp: "*.c / *.cc / *.hpp  -  out of scope"
+
 severity_levels: [blocking, important, suggestion]
 enforcement_kinds:
   format: the formatter owns it; not reviewed by humans
@@ -12,6 +36,44 @@ enforcement_kinds:
   judgement: requires a human or an audit run
 exception_marker: "// standard:exception(<RULE-ID>) <reason> <expiry:YYYY-MM-DD>"
 
+module_overlay_slots:
+  description: >
+    Some rules govern a CHOICE rather than a defect: two shapes are each internally coherent, the
+    cost is only in mixing them, and picking one is the module's call. Writing one of them into the
+    shared registry turns every module that chose the other into a hundred findings  -  which is a
+    migration proposal wearing a standards pass. Those rules bind to a slot here instead. The
+    module's `modules/<Module>.yml` overlay binds it; an UNBOUND slot disables its rules, and the
+    audit says so in the plan rather than defaulting to one dialect silently.
+    A slot is only legitimate when both values are genuinely defensible. `UI-04` is the
+    counter-example: a module with no copy surface has not chosen a different dialect, it is
+    missing the surface, so that rule is not slotted.
+  slots:
+    - id: ServiceNamingScheme
+      governs: [SVC-07]
+      values:
+        send-path: >
+          a method wrapping one service call is named after the endpoint path, prefixed to say a
+          request leaves the device. One spelling on both sides of the wire; a grep from the
+          endpoint reaches every layer.
+        domain-verb: >
+          the method is named after what the domain asks for. Reads more naturally at the call site
+          and survives an endpoint being renamed, at the cost of the endpoint-to-code grep.
+      note: >
+        Module-wide, never per screen. Changing the bound value is a rename migration with its own
+        ticket, not a review comment.
+    - id: NavExitShape
+      governs: [NAME-01]
+      values:
+        coordinator-event: a typed event enum per screen plus a handler alias the coordinator applies.
+        output-closure: an output enum per screen delivered through a closure the factory injects.
+      note: Both enumerate every exit in one place, which is the property NAME-01 actually protects.
+    - id: ComponentsDir
+      governs: [READ-04b]
+      values:
+        Presentation/Components: the conventional spelling.
+        Presentation/Subviews: an equally clear alternative in use.
+      note: The name is free; using two of them in one module is not.
+
 persistence_decision:
   description: >
     Answer this BEFORE reaching for storage. Keychain is the answer to "where does a persisted
@@ -171,8 +233,11 @@ rules:
     check: >
       A `private var x: some View` inside a scene is a component in disguise. If it renders a
       THING  -  a switcher, a chip row, a banner, a bar, a legend, a card  -  extract it to its own
-      file under the screen's `Presentation/Components/`, as a `struct` that takes DATA and
+      file under the screen's component directory (the overlay's `ComponentsDir`, conventionally
+      `Presentation/Components/`), as a `struct` that takes DATA and
       CALLBACKS, never the view model, and give it a `#Preview`.
+      The directory's NAME is a dialect choice and not a finding on its own; using two names for
+      it within one module is.
       Taking data instead of the view model is what makes the preview possible at all: a
       component holding a view model needs the DI container a canvas preview never configures,
       and the workaround (a preview-only fixture type shipped in production sources) is itself
@@ -201,6 +266,12 @@ rules:
       Not this rule: building a design-system `Configuration` value. Moving those to the view
       model drags UI types across the boundary; they belong inside the component that renders
       them (READ-04b), which is where they disappear once the component takes data.
+      The view model is where such a rule GOES BY DEFAULT, and for a single-screen rule that is
+      the end of it. When the same question turns out to be several screens', SVC-08's ladder
+      decides between the entity and a named rule namespace (RULE-01); moving it out of the view
+      layer is this rule, choosing its final home is that one.
+      Also not this rule: reading the load state's own shape (NAME-06). `state.isLoading` decides
+      nothing  -  it reports what the enum already says.
 
   - id: READ-04d
     title: A pure transform is a shared helper, not a method on the view
@@ -321,11 +392,24 @@ rules:
 
   # ── NAME ──────────────────────────────────────────────────────────────────
   - id: NAME-01
-    title: One name per role  -  the navigation handler is never called something else
+    title: One name per role  -  a screen's navigation exit has one spelling module-wide
     severity: blocking
     enforcement: lint
-    mechanism: 'custom regex scoped to Scene/ViewModel: \boutput\b as a handler property or parameter'
+    mechanism: >
+      custom regex scoped to Scene/ViewModel, generated from the module's bound `NavExitShape`:
+      any navigation-exit property or parameter whose name does not match the bound spelling.
     rationale: readability
+    applies_when: >
+      the module's overlay binds `NavExitShape`. Unbound, this rule is DISABLED  -  a regex for one
+      spelling would report every module that chose the other one, which is a dialect difference,
+      not a defect.
+    check: >
+      What this rule protects is that a reader finds a screen's exits under ONE name across the
+      module, not that a particular name wins. Both shapes in use are legitimate: a typed
+      `CoordinatorEvent` enum with a handler alias, or an `Output` enum with a closure. Each
+      enumerates every navigation exit in one place, which is the property that matters.
+      The finding is a module that uses both, or a screen whose exits are spread across an enum
+      and loose ad-hoc callbacks. Report the spelling per screen and the count of each.
 
   - id: NAME-02
     title: Our models use RequestModel/ResponseModel; transport suffixes stop at the data layer
@@ -349,6 +433,16 @@ rules:
     check: >
       An unrecognised server value must land on a known-unknown case rather than failing or
       silently carrying an arbitrary string into the UI.
+      **When the generator declares the same value set several times**  -  one inline enum per
+      response payload, because that is what the schema says  -  do not pick one of them as the
+      domain type and do not add a `switch` per mapper. Declare the domain enum once and bridge
+      through the shared raw code, in an extension on the domain type
+      (`extension X { init?(wireCode: String) }`) that lives beside it. Every mapper then maps
+      through one initialiser, the unknown value lands in one place, and adding a case is one edit
+      rather than one per payload. The bridge is a lowering, so it stays a mapper concern and does
+      not put the generated types in front of the view model (SVC-04).
+      Report per value set: how many generated declarations exist, how many hand-written mappings
+      of it the module has, and whether the unknown value is handled the same way in each.
 
   - id: NAME-05
     title: Screen behaviour is driven by an enum state, not by a spread of booleans
@@ -372,6 +466,36 @@ rules:
       keeps a single source of truth, whereas a stored copy drifts from the inputs it mirrors.
       Two independent booleans that never interact are fine; do not enum-ify for its own sake.
 
+  - id: NAME-06
+    title: The screen's load state is one enum with its payload attached, and the absent case is explained
+    severity: important
+    enforcement: judgement
+    rationale: readability
+    check: >
+      NAME-05 says a screen's behaviour is an enum rather than a spread of booleans. This rule is
+      about the LOAD state specifically  -  the one every screen with a service call has  -  and about
+      the shape, because the shape is what stops the booleans growing back.
+      - **The payload hangs off the case, not beside it.** `case loaded(Content)` where `Content`
+        is its own struct. The alternative  -  an `isLoading` flag next to an optional `data` next to
+        an optional `errorMessage`  -  permits `isLoading == true` with data present and an error
+        set, a combination nothing in the type rejects and every reader has to reason about.
+      - **The enum answers questions; the view does not destructure it.** Accessors on the enum
+        (`var isLoading`, `var <entity>`) keep `if case let` out of the view body. These are not
+        business rules (READ-04c)  -  they are reads of the state's own shape.
+      - **A case deliberately NOT modelled is stated in the file, with its reason.** "There is no
+        `empty` case: a successful response always represents a populated record; an empty payload
+        arrives as a not-found error." Without that line the next reader cannot tell a considered
+        omission from an oversight, and adds the case defensively.
+      - **A secondary source that may fail is an optional slot inside the payload, not a second
+        state.** When a screen's primary data loads but a supporting fetch fails, the failure
+        belongs in `Content` as an optional the view simply does not render  -  not as a screen-level
+        error that discards the data that did arrive. Say so at the property: what nil means and
+        why it is non-fatal. Promoting a non-critical failure to a screen error is the finding, and
+        so is silently defaulting it to an empty value, which makes "absent" and "empty" the same.
+      **The measurement:** count the mutually-dependent state properties the view reads to decide
+      what to render. Three or more that must be read together, or any pair whose illegal
+      combination the type permits, is the finding.
+
   - id: STRUCT-07
     title: A scene is one type  -  no inner view struct wrapping it
     severity: important
@@ -394,6 +518,17 @@ rules:
       `XUseCase.swift` holds the protocol; `XUseCaseLive.swift` sits next to it. Same for a
       repository. A reader opening the protocol sees the contract without scrolling past an
       implementation, and the implementation file is where the collaborators are declared.
+      **The split earns its keep when there is an implementation to scroll past.** A repository, or
+      any implementation with a body  -  request construction, mapping, cache reads, error
+      projection  -  is split: that is the case the rule is for. A use case that is a pure
+      pass-through, whose whole body forwards one call to one collaborator, may keep the protocol,
+      the live type and its null object (TEST-08) in one file: there is no contract to scroll past,
+      and splitting a dozen of those produces three dozen files whose names differ by a suffix.
+      Decide by whether the implementation has anything a reader must skip, never by the layer's
+      name  -  and apply one answer across the module, because the cost of this rule is a reader
+      guessing which file a type is in.
+      A pass-through use case is worth a second look for a different reason: SVC-01 asks what it
+      adds over calling the repository directly. That is a separate finding from this one.
 
   - id: STRUCT-06
     title: A validation rule is a shared type until measurement says otherwise
@@ -450,10 +585,29 @@ rules:
     rationale: flexibility
 
   - id: SVC-05
-    title: One result and error family per module, built through one factory
+    title: One failure vocabulary per module, built through one factory  -  outcomes may be screen-scoped
     severity: blocking
     enforcement: judgement
     rationale: testability
+    check: >
+      Two things used to be one rule here, and conflating them pushed modules toward the wrong fix
+      in both directions. Separate them:
+      **The failure vocabulary is module-scoped.** The set of ways a call can fail  -  offline,
+      timeout, unauthorised, not-found, conflict, server, unknown  -  is one type the whole module
+      shares, produced by one factory that projects the transport error onto it. This is the
+      blocking half. The tell that it was skipped: the same offline / timeout / server triple
+      hand-written into a dozen screen-local types, each classifying the transport error again, so
+      a new failure kind means a dozen edits and the classifications drift apart. Count the
+      declarations of the same failure kind across the module; more than one home for the same
+      concept is the finding.
+      **The outcome type may be screen-scoped.** SVC-09 allows a screen to declare its own closed
+      outcome enum, whose success cases carry that screen's destinations. That is not a second
+      error family and does not violate this rule  -  provided the failure cases PROJECT FROM the
+      module vocabulary rather than redeclaring it. A screen-scoped outcome that reaches for the
+      transport error directly, or invents its own failure spelling, is the violation; one that
+      names the shared kinds is correct.
+      The distinction in one line: **how a call can fail is a module fact; what a screen does next
+      is a screen fact.**
 
   - id: SVC-06
     title: Spec discipline  -  nothing hand-written around the generator, no endpoint in two specs
@@ -467,6 +621,12 @@ rules:
     enforcement: lint
     mechanism: custom regex  -  non-`send` funcs in repository protocols surface for an explicit marker
     rationale: readability
+    applies_when: >
+      the module's overlay binds `ServiceNamingScheme: send-path`. Unbound, or bound to
+      `domain-verb`, this rule is DISABLED for the module  -  see module_overlay_slots. The scheme is
+      a module-wide decision because its whole value is one spelling on both sides of the wire;
+      what the rule then enforces is internal consistency with the declared scheme, never
+      conformity to a sibling module's choice.
     check: >
       `send` + the endpoint path, segments in their own order, camel-cased, path parameters
       dropped: `check-open-status` → `sendCheckOpenStatus`, `order/items/save` →
@@ -505,10 +665,12 @@ rules:
     mechanism: custom regex  -  arithmetic and conditional expressions inside Mapper paths
     rationale: testability
     check: >
-      There are exactly two homes for a business rule: the **view model** that owns the
-      behaviour, or a **computed property on the struct the rule is about** (under a
-      `// MARK: - Derived`), when more than one screen asks the same question.
-      Every other layer is transport. A mapper, a `UseCaseLive`, a repository, a DTO mirror, a
+      There are exactly three homes for a business rule, and RULE-01 carries the ladder that
+      picks between them: the **view model** that owns the behaviour; a **computed property on
+      the struct the rule is about** (under a `// MARK: - Derived`), when more than one screen
+      asks the same question of data the struct already holds; or a **named rule namespace**
+      (RULE-01), when several screens share a rule that is screen policy rather than entity
+      state. Every other layer is transport. A mapper, a `UseCaseLive`, a repository, a DTO mirror, a
       coordinator, a data source  -  each moves values between two shapes and decides nothing. A
       `UseCaseLive` in particular reads as a tempting home because it already knows the domain
       vocabulary: it does not get one. Its body is call → map → return, plus cache read/write;
@@ -556,6 +718,9 @@ rules:
         produce, because the state is computed from the same inputs in both.
       - **In the view model**  -  when the question is that one screen's, or when the answer needs
         anything the entity does not hold (localized copy, a feature flag, live user state).
+      - **In a named rule namespace** (RULE-01)  -  when several screens share the rule but it is
+        screen policy rather than entity state, so putting it on the entity would make a data
+        carrier answer a question about presentation. RULE-01 carries the selection ladder.
       Never in the mapper, and never as a stored field the mapper fills, because a stored field
       is indistinguishable from a wire value at every call site that reads it.
 
@@ -568,6 +733,75 @@ rules:
       emits or drops a field, an aggregation whose result is a screen state
       (`contains { ... } ? .invalid : .valid`), and any localized string.
 
+  - id: SVC-09
+    title: A service outcome is a closed enum  -  a failure is a value, not control flow
+    severity: important
+    enforcement: judgement
+    rationale: testability
+    check: >
+      A boundary method returns ONE type that enumerates every outcome the caller must handle,
+      and the caller `switch`es over it exhaustively. The compiler then answers "is any outcome
+      unhandled?", which no `catch` can. SVC-01 already bans `throws` alongside a result family;
+      this rule says what the family looks like.
+      Three properties make it work, and each is a separate finding when missing:
+      - **Total.** Success, business failure, and every transport failure the screen renders
+        differently are cases of the same type. A method that returns a result AND throws has two
+        outcome channels, so no `switch` is exhaustive.
+      - **Projected, not leaked.** The transport error family (the networking package's own error
+        type) is projected onto the screen's outcome inside the data layer, through one shared
+        projection helper rather than a per-repository `switch`. The transport type never appears
+        in a Domain or Presentation signature (FLEX-05). A repository that returns the transport
+        error verbatim has moved the classification into every caller.
+      - **Named after the outcome, not the payload.** A success case may carry a DESTINATION
+        rather than data  -  a redirect the backend chose, resolved from the wire value into a case
+        (NAME-04) so no raw string reaches the view model. That is the shape's main advantage over
+        a bare `Result<Payload, Error>`, and it is why the two coexist.
+      Where the error spine lives is SVC-05's question, not this one: the outcome enum is
+      screen-scoped, the failure vocabulary it projects from is module-scoped. Duplicating the
+      same offline / timeout / server triple into each screen's enum is the SVC-05 finding.
+      **The measurement, for a finding to be one:** per boundary method, the outcome-channel count
+      (a result type plus a `throws` is two), the number of call sites that re-classify a transport
+      error, and whether any non-exhaustive `switch` over the result exists. No count, no finding.
+
+  # ── RULE  -  business-rule surface ──────────────────────────────────────────
+  - id: RULE-01
+    title: A shared business rule lives in a named rule namespace, as a pure static, traceable to its source
+    severity: important
+    enforcement: judgement
+    rationale: testability
+    check: >
+      SVC-08 names three homes for a business rule. The ladder that picks between them, cheapest
+      rung first:
+      1. **One screen asks it** -> the view model. Stop here. Do not create a namespace for one
+         caller; a namespace with a single consumer is over-hoisting (STRUCT-05).
+      2. **Several screens ask it, of data the entity already carries** -> a computed property on
+         the entity, under `// MARK: - Derived`. This is also what keeps test doubles honest: a
+         double can no longer hand-set a state the real payload could not produce.
+      3. **Several screens ask it, but the answer is screen POLICY rather than entity state** ->
+         a named rule namespace. Putting it on the entity would make a data carrier answer a
+         question about presentation; leaving it in one view model hides it from the others.
+      The namespace's shape, and each property is what makes it auditable:
+      - A **caseless enum** (never a struct with an initialiser, never a class), so it cannot be
+        instantiated or hold state.
+      - **Static, pure functions.** Inputs in, value out. No stored state, no I/O, no logging, no
+        localized copy. A rule that needs the environment takes it as a parameter  -  a clock as a
+        defaulted parameter is the accepted seam, and it is what keeps TEST-01 satisfied without
+        an injected container for a value transform.
+      - It lives in the module's **domain layer**, beside the entities it reads, not beside the
+        scene that needed it first.
+      - It is **not** a formatter, a mapper, or a validator. A value transform is READ-04d, a
+        shape lowering is SVC-08, a form rule is STRUCT-06. A namespace that accumulates all four
+        is a Utils bucket with a better name (STRUCT-04).
+      **Traceability is part of the rule, not a nicety.** Each function names the requirement it
+      enforces  -  the spec clause, business-rule ID, or ticket  -  in its doc comment, and the test
+      that covers it repeats that same token in its name. One grep then reaches requirement, code
+      and test. This is also the rule's own measurement: a namespace whose functions cite nothing
+      cannot be checked against anything, and a cited rule with no test of the same token is an
+      untested requirement, which is the finding.
+      **What the doc comment is for.** Recording the decision  -  which input the rule keys off and
+      why the obvious alternative was rejected  -  is exactly the case READ-02 protects; it is not
+      trimmed. This rule does not require such a comment, it requires the citation.
+
   - id: PLAT-01
     title: Platform affordances go through the app's own wrapper, not the OS API
     severity: blocking
@@ -704,12 +938,16 @@ rules:
 
   # ── UI ────────────────────────────────────────────────────────────────────
   - id: UI-01
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI view composition  -  a UIKit view controller hierarchy expresses reuse differently
     title: A screen's composite view is never consumed by another screen
     severity: blocking
     enforcement: judgement
     rationale: flexibility
 
   - id: UI-02
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI view construction
     title: No new component is added to a UI target the module marks as frozen
     severity: important
     enforcement: lint
@@ -717,12 +955,16 @@ rules:
     rationale: flexibility
 
   - id: UI-03
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI view construction
     title: Every screen with user actions has its analytics surface; no direct generated-event calls
     severity: important
     enforcement: judgement
     rationale: readability
 
   - id: UI-04
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI copy surface (LocalizedText); UIKit modules localise through a different seam
     title: All user copy goes through the screen's copy surface
     severity: important
     enforcement: lint
@@ -844,11 +1086,24 @@ rules:
     rationale: testability
 
   - id: TEST-04
-    title: Test doubles follow one named taxonomy  -  stub, spy, fake, mock
+    title: Test doubles follow one named taxonomy  -  stub, spy, fake, mock, builder
     severity: suggestion
     enforcement: judgement
     rationale: testability
-    check: One kind per file, name states the kind, signature parity with the real type (SVC-02).
+    check: >
+      One kind per file, name states the kind, signature parity with the real type (SVC-02). All of
+      them live in the test target (TEST-08).
+      **The builder is the fifth kind and the one most often missing.** Where tests need many
+      near-identical entities differing in one field, the alternative to a builder is a wall of
+      full initialiser calls  -  so a test's actual subject drowns in fifty lines of scaffolding, and
+      a new field on the entity breaks every test that never cared about it. A builder is a base
+      value plus chainable single-field overrides returning a copy
+      (`.<baseCase>().with<Field>(...)`), so each test states ONLY what it varies and reads as its
+      own precondition. Two properties keep it honest: it produces the real type (never a
+      parallel test-only mirror, which drifts), and each override sets one field, so a reader can
+      tell what a test depends on from its chain.
+      The finding is not "no builder exists"  -  it is a test file where the setup of a case is
+      longer than its assertion, repeated. Report the ratio, not the absence.
 
   - id: TEST-05
     title: Async behaviour is testable  -  no unstructured task in logic, no sleep, injected clock
@@ -870,6 +1125,41 @@ rules:
     enforcement: scan
     rationale: testability
 
+  - id: TEST-08
+    title: A null object may ship in production sources; a test double may not
+    severity: important
+    enforcement: lint
+    mechanism: >
+      custom regex  -  a type whose name marks it as a double (Mock / Stub / Spy / Fake / Fixture
+      prefix or suffix) declared under the module's production source root rather than its test
+      target. Whether a given production type is a null object or a disguised double is
+      JUDGEMENT: the name is the signal a regex can see, the payload is not.
+    rationale: testability
+    check: >
+      Two kinds of type conform to a protocol without doing the real work, and only one of them
+      belongs in production sources.
+      **A null object does.** It satisfies the protocol by doing nothing and returning the empty
+      answer  -  no event sent, `nil` returned, an empty list. It is the honest default for a
+      dependency the caller has legitimately not wired: a defaulted initialiser parameter, a
+      canvas preview, a screen whose optional slot is not configured yet. It carries no data, so
+      it cannot drift from the real payload, and it makes the seam visible in the DI graph instead
+      of forcing an optional dependency on every call site. Name it so the reader knows what it is
+      (a `Noop`-style prefix, consistently across the module) and let it be found by grep.
+      **A test double does not.** A type that carries canned payloads  -  a mock repository
+      returning a hand-built response, a fixture of sample records  -  ships that data to users,
+      grows in the store binary, and can be resolved by accident because nothing but the name
+      says it is not real. It belongs in the test target, where the compiler keeps it out of the
+      app. Where a canned payload is genuinely needed AT RUNTIME (a demo build, an offline
+      preview mode), that is a debug affordance and SEC-09 governs it: the question is what
+      removes it from the store build, and "it is only referenced by the mock path" is not an
+      answer.
+      Distinguish by payload, never by name: a `Mock` that returns nothing is a null object with
+      the wrong name (rename it), and a `Noop` that returns three sample bookings is a double in
+      the wrong target (move it).
+      **The measurement:** per module, the count of double-named types under the production source
+      root, split into carries-payload and returns-empty. The first number is the finding; the
+      second is a naming fix.
+
   # ── FLEX  -  intra-module flexibility ───────────────────────────────────────
   - id: FLEX-01
     title: Layers meet through protocols; no concrete cross-layer type in a signature
@@ -965,11 +1255,30 @@ rules:
       pasteboard writes explicit and expiring; nothing sensitive cached to disk by default.
 
   - id: SEC-06
-    title: Analytics and crash payloads are redacted
+    title: Analytics and crash payloads are redacted, through a named helper, with a test that proves it
     severity: blocking
     enforcement: judgement
     rationale: security
-    check: Cross-check every analytics event's parameter list, user properties, breadcrumbs and non-fatal payloads for PII.
+    check: >
+      Cross-check every analytics event's parameter list, user properties, breadcrumbs and
+      non-fatal payloads against the module's sensitive-data inventory. A class marked
+      `loggable: never` must not appear at all; one marked `hashed-or-truncated-only` appears only
+      in its reduced form.
+      Redaction that lives at the call site is not redaction  -  it is a habit, and it fails on the
+      event somebody adds next month. Three properties, each a separate finding:
+      - **One named helper does the reduction.** A hashing or truncating function with a name,
+        callable from anywhere the value is emitted, so there is one implementation to review and
+        one thing to grep. Not an inline expression repeated per event.
+      - **The event surface carries only the reduced form.** The typed event (UI-03) declares the
+        parameter as the hash or the truncation, never the raw value with a comment asking callers
+        to reduce it first. A parameter that CAN hold the raw value eventually does.
+      - **The redaction has a test.** At minimum: the output is deterministic for the same input,
+        differs for different inputs, and does not contain the input. A redaction nobody tested is
+        a claim; these three assertions are cheap and turn it into a property. This is the rule's
+        measurement  -  an untested reduction helper is the finding even when the code is correct.
+      Truncation needs one extra check that hashing does not: that what remains cannot identify
+      the subject on its own, and cannot be joined against another field in the same event to do
+      so. Two separately-harmless truncations in one payload are not harmless.
 
   - id: SEC-07
     title: Permissions are least-privilege with accurate purpose strings
@@ -1103,6 +1412,8 @@ rules:
 
   # ── A11Y ──────────────────────────────────────────────────────────────────
   - id: A11Y-01
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI accessibility modifiers
     title: An identifier from the shared source on every interactive element
     severity: important
     enforcement: lint
@@ -1110,18 +1421,24 @@ rules:
     rationale: testability
 
   - id: A11Y-02
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI accessibility modifiers
     title: Localized VoiceOver label, plus a hint where the action is not obvious
     severity: important
     enforcement: judgement
     rationale: accessibility
 
   - id: A11Y-03
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI accessibility modifiers
     title: Minimum 44x44 tap target; grouped content exposes one meaningful element
     severity: important
     enforcement: judgement
     rationale: accessibility
 
   - id: A11Y-04
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI accessibility modifiers
     title: Dynamic Type does not break layout at the largest accessibility sizes
     severity: important
     enforcement: judgement
@@ -1129,6 +1446,8 @@ rules:
     check: No fixed-height container holding scalable text.
 
   - id: A11Y-05
+    scope: { frameworks: [swiftui], paths: ["**/*View.swift", "**/*Screen.swift", "**/*Scene.swift", "**/*Cell.swift", "**/*Configuration.swift", "**/*+Modifiers.swift"] }
+    scope_reason: SwiftUI accessibility modifiers
     title: RTL mirrors correctly; no leading/trailing hardcoded as left/right
     severity: important
     enforcement: lint

package/pipeline/skills/skills-index.md

@@ -3,7 +3,7 @@
 > Auto-generated by `pipeline/scripts/build-skills-index.mjs`  -  do not hand-edit.
 > Regenerate with `node pipeline/scripts/build-skills-index.mjs`.
 
-**193 skills** across 2 groups.
+**196 skills** across 2 groups.
 
 | Group | Name | Platform | Description |
 |-------|------|----------|-------------|
@@ -75,12 +75,13 @@
 | external | `html-semantic` |  -  | Semantic HTML5: elements, forms with validation and accessibility, SEO best practices, structured data, Open Graph, Twitter Cards. Use when  |
 | external | `humanizer` |  -  | \| |
 | external | `ios-accessibility` |  -  | Implements, reviews, or improves accessibility in iOS/macOS apps with SwiftUI, UIKit, and AppKit. Use when adding VoiceOver, Voice Control,  |
+| external | `ios-coding-standard` |  -  | The iOS coding-standard rule registry: 99 stable-ID rules across readability, security, service layer, business rules, concurrency, testing, |
 | external | `ios-debugger-agent` |  -  | Debug the current iOS project on a booted simulator with XcodeBuildMCP. Use when an iOS bug has to be reproduced and diagnosed on a booted s |
 | external | `ios-developer` |  -  | Develop native iOS applications with Swift/SwiftUI. Masters iOS 18, SwiftUI, UIKit integration, Core Data, networking, and App Store optimiz |
 | external | `ios-localization` |  -  | Implement, review, or improve localization and internationalization in iOS/macOS apps  -  String Catalogs (.xcstrings), generated localizabl |
 | external | `ios-networking` |  -  | Build, review, or improve networking code in iOS/macOS apps using URLSession with async/await, structured concurrency, and modern Swift patt |
 | external | `ios-security` |  -  | Secure iOS apps with Keychain Services, CryptoKit encryption, biometric authentication (Face ID, Touch ID), Secure Enclave key storage, LACo |
-| external | `ios-simulator` |  -  | Manages iOS Simulator devices and tests app behavior using xcrun simctl. Covers device lifecycle (create, boot, shutdown, erase, delete), ap |
+| external | `ios-simulator` |  -  | Manages iOS Simulator devices and tests app behaviour with xcrun simctl: device lifecycle, app install and launch, push notification and loc |
 | external | `kotlin-coroutines-expert` |  -  | Expert patterns for Kotlin Coroutines and Flow, covering structured concurrency, error handling, and testing. Use when writing or reviewing  |
 | external | `live-activities` |  -  | Implement, review, or improve Live Activities and Dynamic Island experiences in iOS apps using ActivityKit. Use when building real-time upda |
 | external | `macos-menubar-tuist-app` |  -  | Build, refactor, or review SwiftUI macOS menubar apps that use Tuist. Use when building, refactoring or reviewing a SwiftUI macOS menubar ap |
@@ -96,15 +97,16 @@
 | core | `multi-agent-channels` |  -  | Multi-channel reporter  -  Jira/Confluence/Wiki/PR description. Multi-select channels + content, humanizer pass, reviewer-preserving Bitbuck |
 | core | `multi-agent-create-jira` |  -  | Create a standards-compliant Jira issue (Task / Bug / Story): asks the type, mines project conventions, drafts from a standard template with |
 | core | `multi-agent-design-check` |  -  | Mock-mode vs Figma design audit (iOS / Android, local-only). Pick repo + module, gate on mock support, enumerate every state driver into a c |
-| core | `multi-agent-dev` |  -  | Fast development mode: Init → Dev (Opus) → Test → Commit → Report. Analysis, planning, and review phases are skipped. Use when the work is a |
-| core | `multi-agent-dev-autopilot` |  -  | Fastest mode: Dev (Opus) plus Autopilot. Init → Dev → Commit → Report with zero confirmations. Use when a change is well understood and shou |
-| core | `multi-agent-dev-local` |  -  | Fast mode + local  -  Init → Dev(Opus) → Commit → Report, no worktree. Use when a change should be developed on the current branch without c |
+| core | `multi-agent-dev` |  -  | Fast development mode: Init → Dev (Opus) → Review → Test → Commit → Report. Analysis and planning are skipped, review is not. Use when the w |
+| core | `multi-agent-dev-autopilot` |  -  | Fastest mode: Dev (Opus) plus Autopilot. Init → Dev → Review → Commit → Report with zero confirmations. Review still runs and auto-fixes blo |
+| core | `multi-agent-dev-local` |  -  | Fast mode + local  -  Init → Dev(Opus) → Review → Commit → Report, no worktree. Use when a change should be developed and reviewed on the cu |
 | core | `multi-agent-dev-local-autopilot` |  -  | Fastest + local  -  Dev(Opus) + autopilot, no worktree, zero interaction. Use when a change should be developed on the current branch with n |
 | core | `multi-agent-diff-explain` |  -  | Map Phase 4 triage findings to branch diff lines. Read-only post-hoc command, used after review to answer 'which finding lines up with which |
-| core | `multi-agent-finish` |  -  | Continue already-done LOCAL work through the pipeline tail: Review → Build+Test → Commit/PR → Report (technical analysis + Jira test-scenari |
+| core | `multi-agent-ship` |  -  | Continue already-done LOCAL work through the pipeline tail: Review → Build+Test → Commit/PR → Report (technical analysis + Jira test-scenari |
 | core | `multi-agent-forget` |  -  | Remove a saved /multi-agent routine (created by /multi-agent:save): deletes its local-only command and its registry entry. Asks which one an |
 | core | `multi-agent-garbage-collect` |  -  | Sweep leftover /tmp scratch (picker state, review diffs, channel payloads, analysis drafts) from past runs. Dry-run first; confirms before d |
 | core | `multi-agent-help` |  -  | Multi-agent pipeline usage guide  -  renders in EN or TR per prefs.global.outputLanguage (falls back to promptLanguage for backward compatib |
+| core | `multi-agent-ios-coding-standard` |  -  | Audit an iOS module against the shared coding-standard registry (99 stable-ID rules), produce a remediation plan, then hand off to dev/dev-l |
 | core | `multi-agent-issue` |  -  | List unassigned GitHub issues, pick one, auto-assign, and launch the multi-agent pipeline. Use when a GitHub issue should be picked up and s |
 | core | `multi-agent-jira` |  -  | List open Jira issues, pick one, and launch the multi-agent pipeline. Use when a Jira issue should be picked up and started without knowing  |
 | core | `multi-agent-kill` |  -  | Stop the given task, then remove its worktree and branch. Asks for confirmation. Use when a running or stuck task should be stopped and its  |
@@ -129,6 +131,7 @@
 | core | `multi-agent-status` |  -  | Show every multi-agent task's ID, phase, branch, and status. Use when asked what is running, or for an overview of every task. |
 | core | `multi-agent-sync` |  -  | One-shot sync of the entire multi-agent ecosystem: Claude Code, Copilot CLI, pipeline repo, website, and the dev-toolkit MCP server. Use whe |
 | core | `multi-agent-test` |  -  | UI Bug Hunter  -  iOS Simulator (simctl) + Android Emulator (adb). Auto-detects platform. Screenshot + tap + analyze on the booted device. T |
+| core | `multi-agent-testflight-validation` |  -  | Pre-submission validation for a TestFlight / App Store build (iOS, local-only). Three gates: static archive audit, Apple's own `altool --val |
 | core | `multi-agent-uninstall` |  -  | Uninstall the pipeline from Claude Code + Copilot CLI. Keychain access tokens are always left untouched; --all-data also clears pipeline set |
 | core | `multi-agent-update` |  -  | Update the pipeline to the latest version: git pull, install, migrate. Use when the installed pipeline is behind and should be brought to th |
 | external | `musickit-audio` |  -  | Integrate Apple Music playback, catalog search, and Now Playing metadata using MusicKit and MediaPlayer. Use when adding music search, Apple |
@@ -155,7 +158,7 @@
 | external | `speech-recognition` |  -  | Transcribe speech to text using Apple's Speech framework. Use when implementing live microphone transcription with AVAudioEngine, recognizin |
 | external | `spm-build-analysis` |  -  | Analyze Swift Package Manager dependencies, package plugins, module variants, and CI-oriented build overhead that slow Xcode builds. Use whe |
 | external | `storekit` |  -  | Implement, review, or improve in-app purchases and subscriptions using StoreKit 2. Use when building paywalls with SubscriptionStoreView or  |
-| external | `swift-api-design-guidelines` |  -  | Apply Swift API Design Guidelines to name, label, and document Swift APIs. Covers argument label rules (prepositional phrase rule, grammatic |
+| external | `swift-api-design-guidelines` |  -  | Swift API Design Guidelines: clarity at the point of use, naming for readability over brevity, argument labels and prepositional phrases, me |
 | external | `swift-architecture` |  -  | Select, implement, or migrate between app architecture patterns for Apple platform apps. Use when choosing between MV (Model-View with @Obse |
 | external | `swift-charts` |  -  | Implement, review, or improve data visualizations using Swift Charts. Use when building bar, line, area, point, pie, donut, or iOS 26 3D cha |
 | external | `swift-codable` |  -  | Implement Swift Codable models for JSON and property-list encoding and decoding with JSONDecoder, JSONEncoder, CodingKeys, and custom init(f |
@@ -169,7 +172,7 @@
 | external | `swift-testing-pro` |  -  | Writes, reviews, and improves Swift Testing code using modern APIs and best practices. Use when reading, writing, or reviewing projects that |
 | external | `swiftdata` |  -  | Implement, review, or improve data persistence using SwiftData. Use when defining @Model classes with @Attribute, @Relationship, @Transient, |
 | external | `swiftdata-pro` |  -  | Writes, reviews, and improves SwiftData code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use |
-| external | `swiftlint` |  -  | Configures and enforces SwiftLint in Swift projects using build tool plugins, run scripts, and CI. Covers .swiftlint.yml configuration, disa |
+| external | `swiftlint` |  -  | Configures and enforces SwiftLint via build tool plugins, run scripts and CI: .swiftlint.yml rule sets, analyzer rules, baselines, autocorre |
 | external | `swiftui-animation` |  -  | Implement, review, or improve SwiftUI animations and transitions. Use when adding explicit animations with withAnimation, configuring implic |
 | external | `swiftui-expert-skill` |  -  | Write, review, or improve SwiftUI code following best practices for state management, view composition, performance, macOS-specific APIs, an |
 | external | `swiftui-gestures` |  -  | Implement, review, or improve SwiftUI gesture handling. Use when adding tap, long press, drag, magnify, or rotate gestures, composing gestur |