@mmerterden/multi-agent-pipeline 13.1.0 → 13.2.0

package/pipeline/skills/shared/core/multi-agent-sync/SKILL.md

@@ -31,8 +31,8 @@ Run all steps automatically:
 
 ```
 Step 1: DETECT      Compare timestamps, find stale targets
-Step 2: COPILOT     Claude Code -> Copilot CLI (instructions + 43 sub-command skills)
-Step 2b: CODEX      Claude Code -> Codex CLI (1 router skill + 43 specs as refs + 8 agent TOML)
+Step 2: COPILOT     Claude Code -> Copilot CLI (instructions + 44 sub-command skills)
+Step 2b: CODEX      Claude Code -> Codex CLI (1 router skill + 44 specs as refs + 8 agent TOML)
 Step 3: REPO        Claude Code -> pipeline repo (genericized, personal data scrub)
 Step 3d: DEV-TOOLKIT Companion MCP server -> detect movement, ship gates, commit + publish
 Step 4: WEBSITE     Version + phase/model counts -> {website-host} (i18n + projects.ts)
@@ -223,12 +223,12 @@ When invoked with the `release` argument:
 |-------------|-------------|
 | `~/.claude/commands/multi-agent/{cmd}.md` | `~/.copilot/skills/multi-agent-{cmd}/SKILL.md` |
 
-**43 commands are synced** (canonical inventory  -  must match `cross-cli-contract.md` section 1; drift = contract violation):
+**44 commands are synced** (canonical inventory  -  must match `cross-cli-contract.md` section 1; drift = contract violation):
 
 ```
 analysis, analysis-resolve, autopilot, build-optimize, channels, create-jira, design-check, dev,
 dev-autopilot, dev-local, dev-local-autopilot, diff-explain, finish, forget, garbage-collect,
-help, issue, jira, kill, language, local,
+help, ios-coding-standard, issue, jira, kill, language, local,
 local-autopilot, log, manual-test, prune-logs, purge, refactor, resume, review, review-issue, review-jira,
 routines, save, scan, search, setup, stack, status, sync, test, testflight-validation, uninstall, update
 ```

package/pipeline/skills/shared/external/ios-coding-standard/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: ios-coding-standard
+description: "The iOS coding-standard rule registry: 95 stable-ID rules across readability, security, service layer, concurrency, testing, module boundaries, naming and visibility, each with a severity and enforcement kind. Use when writing or reviewing Swift and you need the project rule rather than an opinion, or on a persistence or logging question."
+user-invocable: true
+---
+
+# iOS coding standard
+
+The registry is `references/rules.yml`. It is the source of truth, and it is
+the reason to load this skill: a rule cited by ID is checkable and a remembered rule
+is not.
+
+| File | What it is | When to read it |
+|---|---|---|
+| `references/rules.yml` | 95 rules with stable IDs, severity, enforcement kind and a `check` describing what counts as a violation | before asserting that something is or is not a violation |
+| `references/STANDARD.md` | the same rules taught with before/after Swift, for a human | when you need the reasoning or an example, not just the rule |
+| `references/swiftlint.draft.yml` | the mechanically-enforceable subset as a SwiftLint config | when wiring lint into a project |
+| `references/lint-local.sh` | runs that config over one module, with a baseline mode | when grandfathering existing violations so only new ones surface |
+
+## How to use it
+
+1. **Cite, do not paraphrase.** Reference `SEC-04`, `READ-01`, `SVC-02`. A finding
+   without an ID is an opinion, and the author cannot look it up to disagree.
+2. **A rule not in the registry is not a rule.** If a review wants one, propose it
+   as `status: proposed` with a rationale rather than enforcing it silently.
+3. **Severity decides whether it blocks.** `blocking` stops the change,
+   `important` is fixed in the same pass, `suggestion` is optional. Do not promote a
+   suggestion to blocking because it happens to bother you.
+4. **Enforcement kind decides who checks it.** `format` belongs to the formatter,
+   `lint` to the linter, `scan` to a tool, `judgement` to a person or an audit run.
+   Reviewing a `format` rule by hand wastes the review.
+5. **Exceptions are marked in code, with an expiry:**
+   `// standard:exception(<RULE-ID>) <reason> <expiry:YYYY-MM-DD>`. An unmarked
+   deviation is a finding; a marked one is a decision.
+
+## Two decisions the registry answers, and code usually gets wrong
+
+**Persistence.** Read `references/rules.yml → persistence_decision` before reaching for
+storage. The ladder starts at "does this value need to outlive the current flow?"
+with the default answer *no*. The Keychain answers "where does a persisted secret
+live", not "this value is sensitive" - most sensitive values in a flow never need to
+persist, and persisting them is the more expensive mistake, because the item
+outlives the flow and the cleanup belongs to nobody.
+
+**What a mapper may do.** A mapper lowers one shape onto another. Unwrapping an
+optional wire field to an empty value is lowering. Arithmetic and unit conversion, a
+clamp or threshold, choosing a screen state, and policy defaults are **not** - each
+belongs to the view model, or to a named domain rule when several screens share it.
+Carry the wire value with its unit in the name and convert where it is read.
+
+## Rule families
+
+`READ` readability and section structure · `SEC` secrets, logging, storage ·
+`SVC` service layer and mapping · `TEST` testability seams · `MOD` module
+boundaries and imports · `NAME` naming · `FLEX` flexibility and extension points ·
+`CONC` concurrency · `VIS` visibility and access level · `UI` view construction ·
+`PERF` performance · `DEPR` deprecation and retirement.
+
+## Scope note
+
+The registry is project-configurable, not project-specific: rule bodies describe
+shapes (a mapper doing arithmetic, a logger interpolating a token) rather than named
+modules. A project adds its own vocabulary through a `modules/<Module>.yml` overlay
+beside `references/rules.yml` - the module's terms, its allowed dependencies, its validation
+rules - which the audit binds on top of the shared registry. Nothing in the shared
+registry names a module, so it applies unchanged to any SwiftUI codebase.
+
+`references/swiftlint.draft.yml` carries one placeholder worth changing per project: the remote
+image-host allowlist is set to `example.com`. Point it at your own CDN, or the rule
+flags every remote image.
+
+## Running a full audit
+
+For a module-wide pass with a plan and a handoff, the pipeline ships
+`/multi-agent:ios-coding-standard`, which builds the module registry, binds the
+overlay, applies the surviving rules and produces a remediation plan. This skill is
+the registry that audit reads; use the skill directly when you are writing or
+reviewing code rather than auditing a whole module.

package/pipeline/skills/shared/external/ios-coding-standard/references/STANDARD.md

@@ -0,0 +1,445 @@
+# iOS Coding Standard
+
+The one document to read before your first PR. Rule IDs in brackets point at `rules.yml`, which
+carries severity, tooling and rationale for each; `EXAMPLES.md` carries a worked ✗/✓ pair for
+every rule a tool cannot decide — look one up by ID when a review cites it. Your module's own docs
+win where they differ — this is the floor, not the ceiling.
+
+Five principles, in the order they break things: **security · testability · readability ·
+flexibility · consistency.**
+
+---
+
+## 0. The ten lines
+
+1. Sensitive data goes in the Keychain, never in `UserDefaults`, and never into a log. `[SEC-01, SEC-03]`
+2. Never reach for the environment — inject time, storage, randomness, session. `[TEST-01]`
+3. One type per file; the file is named after it. `[STRUCT-01]`
+4. A screen is a known set of files, always the same set. `[STRUCT-02]`
+5. Where a type lives is decided by how many things use it. `[STRUCT-05]`
+6. A feature module never imports another feature module. `[MOD-01]`
+7. Everything is `private` and `final` until something forces otherwise. `[VIS-01, VIS-02]`
+8. One request in, one result out — `async`, no completion handlers, no `throws`. `[SVC-01]`
+9. Split concerns with `// MARK:` — business rules, service calls and UI never share a section. `[READ-01]`
+10. Variants are configuration, not `if` trees. `[FLEX-02]`
+
+---
+
+## 1. Security
+
+Work out which **data class** a value belongs to before you decide where it goes.
+`rules.yml → sensitive_data_classes` is the list: auth token, credential, government ID, travel
+document, booking reference, membership identity, payment instrument, personal contact,
+biometric/health, precise location. The class decides the storage, not convenience.
+
+### Storage `[SEC-01]` — ask "does it persist?" before "where does it go?"
+
+Keychain answers *where a persisted secret lives*. It does not answer *this value is sensitive*.
+Most sensitive values in a flow are used and dropped, and those must not be persisted at all.
+
+```swift
+// ✗ over-persistence — a value the flow throws away in 30 seconds now outlives logout
+//   and nobody owns deleting it
+try credentialStore.save(oneTimeCode, for: .verificationCode)
+UserDefaults.standard.set(passportNumber, forKey: "apisPassport")
+```
+```swift
+// ✓ transient: held by the flow's model, gone when the flow ends
+@Observable final class APISFormViewModel {
+    private var passportNumber: String = ""      // never leaves memory
+}
+```
+```swift
+// ✓ persisted, because it must survive an app restart — Keychain, explicit accessibility,
+//   no iCloud sync
+try credentialStore.save(
+    membershipToken,
+    for: .authToken,
+    accessibility: .whenUnlockedThisDeviceOnly
+)
+```
+
+**The ladder, in order:**
+
+1. **Does it need to outlive this flow?** Assume no. In-flow data — a form field, a scanned
+   document number, a one-time code, a draft — stays in memory and dies with the flow.
+2. **If yes: survive what?** Backgrounding → still just model state. App restart → Keychain.
+   Reinstall → a product decision someone signs off, never a storage default.
+3. **Which class is it?** `payment-instrument`, `biometric-or-health` and `precise-location`
+   stay transient no matter what step 2 said — the answer to "it must survive" there is a
+   server-side or system token, not local storage.
+
+**Why both directions are findings:** `UserDefaults` is a plist in the app container — it lands in
+unencrypted backups and outlives the session, so under-protection is obvious. Over-persistence is
+the subtler one: an unnecessary Keychain item survives the flow, survives logout unless someone
+remembers to delete it, and creates a cleanup obligation with no owner. "Put it in the Keychain to
+be safe" is not a safe default.
+
+**Transient is not unregulated.** A value held only in memory is still never logged `[SEC-03]`,
+still cleared when the session drops and hidden from the app-switcher snapshot `[SEC-05]`, and
+still never sent to analytics `[SEC-06]`.
+
+### Logging `[SEC-03]`
+
+```swift
+// ✗ three violations: print, a token in the message, a raw body
+print("order response: \(response)")
+logger.debug("token=\(token)")
+```
+```swift
+// ✓ private by default; only provably non-sensitive values are public
+logger.debug("order completed for \(itemCount, privacy: .public) items")
+```
+**Why:** device logs are readable by other tooling and are collected in diagnostics. Defaulting to
+private means a forgotten annotation fails safe; defaulting to public means it fails open.
+
+### The rest, briefly
+
+- No secret in source — anything committed is already leaked. `[SEC-02]`
+- HTTPS only; an ATS exception carries a written reason and an expiry date. `[SEC-04]`
+- Sensitive data has a lifetime: cleared on logout, hidden from the app-switcher snapshot,
+  not cached to disk by default. `[SEC-05]`
+- Analytics events, user properties and crash breadcrumbs are redacted — check the parameter
+  list of every event you add. `[SEC-06]`
+- Permissions are least-privilege with honest purpose strings; the privacy manifest matches what
+  you actually collect. `[SEC-07, SEC-08]`
+- Debug menus, mock launch arguments and redirect shortcuts are **compiled out** of release, not
+  hidden behind a flag. `[SEC-09]`
+
+---
+
+## 2. Testability
+
+Testability is a property of the production code. You cannot add it later by writing tests.
+
+### Inject the environment `[TEST-01]`
+
+```swift
+// ✗ untestable by construction — the assertion depends on today's date
+struct BoardingEligibility {
+    func canCheckIn(flight: Flight) -> Bool {
+        Date() > flight.departure.addingTimeInterval(-24 * 3600)
+    }
+}
+```
+```swift
+// ✓ the seam is one parameter wide
+struct BoardingEligibility {
+    let now: () -> Date
+
+    func canCheckIn(flight: Flight) -> Bool {
+        now() > flight.departure.addingTimeInterval(-24 * 3600)
+    }
+}
+```
+**Why:** the rule is not "avoid `Date()`" — it is that anything the outside world decides
+(time, randomness, identifiers, locale, storage, session, feature flags) must be something the
+test can decide instead. A type that reaches for it has no seam, and no test discipline recovers.
+
+### Keep the rule callable `[TEST-02, TEST-03]`
+
+```swift
+// ✗ the rule is trapped inside the view model, behind a network call and a singleton
+func submit() async {
+    guard Session.shared.isLoggedIn, passengers.allSatisfy(\.hasDocument) else { return }
+    ...
+}
+```
+```swift
+// ✓ the decision is a value-returning function; the view model orchestrates
+func submitGate(for passengers: [Passenger], isLoggedIn: Bool) -> SubmitGate {
+    guard isLoggedIn else { return .requiresLogin }
+    guard passengers.allSatisfy(\.hasDocument) else { return .missingDocuments }
+    return .allowed
+}
+```
+**Why:** the second version is one line to test and reads as the business rule it is. The first
+needs a session, a network stub and a view model instance to answer "what happens when a document
+is missing".
+
+Also: name test doubles for what they do — stub, spy, fake, mock — one kind per file, and keep
+the signature identical to the real type, because a drifted double is the first thing the next
+person copies. `[TEST-04, SVC-02]`
+
+---
+
+## 3. Readability
+
+### Separate concerns with MARKs `[READ-01]`
+
+Business rules, service calls and UI never share a section. A reader must find each without
+reading the file. ViewModel order: `Properties → Init → Derived state → Flow → Gate → Intents →
+Error handling`. Scene order: `State → Init → Body →` one `@ViewBuilder` per visual section.
+
+### Extract by call-site count, not by feel `[READ-04]`
+
+Two or more call sites → its own file with its own configuration. Exactly one call site and bound
+to the screen's state → a `private @ViewBuilder` in a MARK'd extension. Pushing a state-coupled
+fragment into its own file to shrink the screen trades one long file for a file plus a binding
+tangle — that reads worse, and it is a finding in the same way the opposite is.
+
+### A pure transform is a shared helper `[READ-04d]`
+
+```swift
+// ✗ a date formatter living on the scene that happened to need it first
+extension PassengerAndFlightSelectionScene {
+    func formattedDate(_ raw: String?) -> String { ... }   // and again, later, in a mapper
+}
+```
+```swift
+// ✓ one home for value transforms
+enum OrderBFFFormatters {
+    static func displayDate(fromISODay raw: String?) -> String { ... }
+    static func initials(from name: String?) -> String? { ... }
+}
+```
+**Why:** these have no screen state, so nothing ties them to a screen — and left where they were
+typed they get written a second time somewhere else, with a slightly different edge case.
+
+### A view fragment that renders a thing is a component file `[READ-04b]`
+
+```swift
+// ✗ a component hiding as a computed property: cannot be previewed, cannot be reused,
+//   and it reads the whole view model so it never could be
+private var legSwitcher: some View {
+    HStack {
+        ForEach(viewModel.segments) { segment in
+            Button { Task { await viewModel.onSegmentSelected(segment.segmentIndex) } } label: { ... }
+        }
+    }
+}
+```
+```swift
+// ✓ SeatMapLegSwitcher.swift — data in, callbacks out, previewable on its own
+struct SeatMapLegSwitcher: View {
+    let segments: [SeatMapSegment]
+    let activeSegmentIndex: Int
+    let onSelect: (Int) -> Void
+    var body: some View { ... }
+}
+
+#Preview {
+    SeatMapLegSwitcher(segments: [.gidis, .donus], activeSegmentIndex: 0, onSelect: { _ in })
+}
+
+// ✓ the scene keeps the composition — which component shows, in what order
+@ViewBuilder
+var content: some View {
+    if viewModel.loadError { errorRetryView } else { SeatMapLegSwitcher(...) }
+}
+```
+**Why:** the canvas is the fastest way to check a visual piece, and it only works when the piece
+takes data. A fragment bound to a view model needs the DI container no preview configures — so
+it never gets looked at until the whole flow is run on a device.
+
+### One type per file; nest only owned details `[STRUCT-01]`
+
+```swift
+// ✗ a response model nested inside another — invisible to a filename search,
+//   and moving it later renames every reference
+struct OrderResponseModel {
+    struct PassengerModel { ... }
+}
+```
+```swift
+// ✓ data types are top level, one per file
+struct OrderResponseModel { let items: [OrderItemModel] }   // OrderResponseModel.swift
+struct PassengerModel { ... }                                      // PassengerModel.swift
+
+// ✓ still fine — an owned detail with exactly one owner
+@Observable final class SeatMapViewModel {
+    enum ViewState { case loading, loaded, failed }
+}
+
+// ✓ also fine — a pure constants namespace; the nesting IS the grouping
+enum AppConstant {
+    enum Phone { static let defaultDialCode = "+90" }
+    enum DeepLink { static let scheme = "myapp" }
+}
+```
+**Why:** entities and transport models get looked up by name, move between placement tiers as
+consumers change, and are referenced from mappers and tests. A `ViewState` or a `static let`
+literal does none of that — flattening `AppConstant.Phone` to `AppConstantPhone` loses the
+grouping and buys no discoverability.
+
+### A method that wraps one service is named after it `[SVC-07]`
+
+```swift
+// ✗ transport verbs invented by the client — the name says what the code does
+//   (which the signature already says), not which service will fire
+func fetchOpenStatus(_ request: CheckOpenStatusRequestModel) async -> Result
+func loadPassengers(...) async -> Result
+```
+```swift
+// ✓ `send` + the endpoint path, segments in the backend's own order
+func sendCheckOpenStatus(_ request: CheckOpenStatusRequestModel) async -> Result  // check-open-status
+func sendOrderItemsSave(...) async -> Result                                      // order/items/save
+func sendSeatExtend() async -> Result                                             // seat/extend
+
+// ✗ the generated client's method name is not the service name: `get` is the generator's
+//   HTTP-verb prefix and it reorders the path the backend chose
+func sendGetSeatMapPageInfo() async -> Result   // seat/map-page-info -> sendSeatMapPageInfo
+
+// ✓ variants over one service: the single caller is named, the variants sit above it
+func sendGetCountryList() async throws -> CountryLookupResponse   // private, the one call
+func fetchNationalityList() async -> Result  // standard:exception(SVC-07) screen variant
+func fetchAreaCodeList() async -> Result     // standard:exception(SVC-07) screen variant
+```
+**Why:** one grep from the endpoint reaches every layer that touches it, and the call site
+tells you which service fires without opening the repository. It also survives the rename the
+other way round: when the backend renames an endpoint, the compiler shows you every screen.
+
+### A mapper moves values; it never decides `[SVC-08]`
+
+```swift
+// ✗ three decisions hiding in a lowering: a unit conversion, a clamp, and a screen state
+struct SummaryMapper: Sendable {
+    func map(dto: SummaryDto) -> SummaryData {
+        SummaryData(
+            sessionTimeout: dto.sessionTimeout.map { TimeInterval($0) / 1000.0 },
+            variant: dto.info?.status == .error ? .flightError : .standard,
+            otpTimeout: dto.timeout ?? 180
+        )
+    }
+}
+```
+```swift
+// ✓ the mapper carries the wire facts, unit in the name
+SummaryData(sessionTimeoutMs: dto.sessionTimeout, isFailure: dto.info?.status == .error,
+            otpTimeout: dto.timeout)
+
+// ✓ the view model decides, in its own business-rules section
+var variant: SummaryVariant {
+    if data.isFailure { return anyApisRedirect ? .apisError : .flightError }
+    return data.isMultiSegment ? .oneStop : .standard
+}
+```
+**Why:** the mapper is the one type with no screen context. A rule buried in it is invisible
+from the view model that owns the behaviour, untestable without hand-building a DTO, and quietly
+duplicated the next time another screen needs the same decision. `?? ""` on an optional wire
+field is not a decision — it is the lowering itself.
+
+### Signatures read as the contract `[SVC-01]`
+
+```swift
+// ✗ the parameter list is a request model nobody wrote
+func savePassengers(pnr: String, surname: String, passengers: [Passenger],
+                    contact: ContactInfo?, acceptsTerms: Bool) async throws -> Bool
+```
+```swift
+// ✓
+public func savePassengers(
+    _ request: SaveOrderItemsRequestModel
+) async -> OrderServiceResult<SaveOrderItemsResponseModel> {
+```
+**Why:** one request model means adding a field touches one type instead of every caller; one
+result family means one error channel instead of `throws` plus a result plus an optional. Past
+~2 parameters at a service boundary, the parameters want to be a model.
+
+### Visibility is documentation `[VIS-01, VIS-02, VIS-04]`
+
+Everything `private` and `final` until something forces otherwise. `public` only on what another
+module actually imports — and every surviving `public`, plus every cross-module contract, carries
+a doc comment. That is the one place the "no unnecessary comments" rule inverts: an
+implementation detail explains itself through naming, a contract between two teams cannot.
+
+---
+
+## 4. Flexibility
+
+### A screen is a known file manifest `[STRUCT-02, STRUCT-03]`
+
+`Scene · ViewModel · LocalizedText · CoordinatorEvent · AnalyticsTracking · UseCase · Repository
+(+protocol +mock) · Mapper + models` — each present when its responsibility exists, absent when it
+does not. An empty `LocalizedText` on a screen with no copy is noise, not compliance. Every screen
+sits at the same depth with the same internal grouping, because people navigate by muscle memory.
+
+### Placement is a consumer count `[STRUCT-05]`
+
+| Consumers | Home |
+|---|---|
+| 2+ modules | cross-module shared tier |
+| 2+ screens | the module's shared entities |
+| one screen | that screen's own folder — **not** the shared tier |
+| one type | its own file beside that type |
+
+Both directions are findings. A single-consumer type parked in the shared tier inflates the shared
+surface and makes the next reader think it is load-bearing.
+
+### Modules do not know each other `[MOD-01, MOD-05, MOD-06]`
+
+A feature module never imports a sibling feature. Cross-feature needs go through the seam layer
+(contracts / bridges / adapters). DI resolves a protocol declared in core or the seam — resolving
+another feature's concrete type is a compile-time dependency in a runtime disguise. Only the
+composition root knows the module list.
+
+The test: **removing this module should touch only the composition root.** If a sibling feature
+mentions it, it is not a module, it is a folder.
+
+### Variants are configuration `[FLEX-02, FLEX-03]`
+
+```swift
+// ✗ branches that differ only in tokens and copy
+if isCompact { Text(title).font(.body).padding(8) }
+else { Text(title).font(.title).padding(16) }
+```
+```swift
+// ✓ one path, a configuration value
+Text(title)
+    .typographyStyle(style.typography)
+    .padding(style.padding)
+```
+**Why:** adding a third variant costs a case instead of a branch, and the component stays open for
+extension — the next design change does not edit its body.
+
+---
+
+## 5. Concurrency
+
+Applies where the module is in Swift 6 language mode; the compiler already blocks the unsafe
+cases, so these rules are about the model being *legible*.
+
+- The isolation policy is one decision applied everywhere. A reader must know where a function
+  runs from its declaration, without tracing callers. `[CONC-01]`
+- State `Sendable` where it is load-bearing, consistently. `[CONC-02]`
+- `@preconcurrency`, `nonisolated(unsafe)` and `@unchecked Sendable` are migration tools. Each
+  needs a reason and a removal condition — they are counted, and a rising count means the module
+  is quietly returning to pre-Swift-6 guarantees while the build stays green. `[CONC-03]`
+- One model: no `DispatchQueue`, semaphore or completion handler layered onto `async`. `[CONC-04]`
+- Every task has an owner and a cancellation story. An unowned task outlives its screen and writes
+  to dead state. `[CONC-05]`
+
+---
+
+## 6. Accessibility
+
+Identifier from the shared source on every interactive element `[A11Y-01]` · localized VoiceOver
+label, plus a hint when the action is not obvious from the label `[A11Y-02]` · 44×44 minimum tap
+target, and grouped content exposes one meaningful element rather than five fragments `[A11Y-03]`
+· Dynamic Type survives the largest accessibility sizes — no fixed-height container around
+scalable text `[A11Y-04]` · RTL mirrors, so `leading`/`trailing`, never `left`/`right` `[A11Y-05]`.
+
+---
+
+## 7. Performance — the four that are also readability
+
+No expensive computation in a view body `[PERF-01]` · lazy containers with stable identity, never
+index-as-id `[PERF-02]` · no blocking work at init or on the main actor `[PERF-03]` · no formatter,
+calendar or regex constructed per render `[PERF-04]`.
+
+**Explicitly out of scope of this standard:** Instruments-driven optimisation, launch-time budgets,
+memory profiling. Those belong to a performance workflow — measure before optimising, and do not
+let a style document push you into speculative tuning.
+
+---
+
+## 8. Exceptions
+
+A rule you cannot follow is fine; an undocumented one is not. Mark it in code:
+
+```swift
+// standard:exception(SEC-04) legacy partner endpoint pending TLS migration 2026-12-31
+```
+
+The linter honours the marker, the audit counts it, and the count is reviewed. Unwritten
+exceptions become silent decay; counted ones become a backlog.