devendra-skill-package 1.0.2

package/.github/skills/code-test-coverage-analyzer/SKILL.md

@@ -0,0 +1,1358 @@
+---
+name: code-test-coverage-analyzer
+version: "3.0.0"
+description: >
+  Audits any software project against three requirement documents — BRD (Business Requirement Document),
+  User Stories, and Test Cases — all provided as Markdown files. Performs a multi-pass multi-layered
+  repository scan, compares every single requirement against actual implementation with code evidence,
+  and generates 15 professional compliance-report files. Covers BRD compliance, user story fulfillment,
+  test case pass/fail analysis, validation analysis, UI analysis, API analysis, business logic, navigation,
+  traceability matrix, missing features, extra implementation, compliance scorecard, security analysis,
+  and final recommendations. Framework-agnostic: works with React Native, React, Angular, Flutter,
+  Android, iOS, NestJS, Node.js/Express, Spring Boot, .NET Core, and Go.
+  Behaves like a senior QA + Business Analyst + Technical Architect. Never guesses. Never marks
+  anything implemented without verified code evidence.
+argument-hint: "<BRD.md> <USER_STORIES.md> <TEST_CASES.md> [project-root] [output-folder]"
+user-invocable: true
+---
+
+# CODE TEST COVERAGE ANALYZER
+
+This skill is fully AI-driven. Do NOT rely on any script to perform the analysis. Scripts in this skill
+are helpers for platform detection and directory tree generation only. ALL requirement comparison,
+evidence gathering, status determination, and report generation is performed by the AI through
+systematic reading of source files.
+
+---
+
+## Purpose
+
+Determine with evidence-backed precision how closely the actual implementation matches the declared
+requirements. Every requirement must be assessed. Every assessment must cite actual source files,
+functions, classes, or UI elements. Nothing is assumed. Nothing is fabricated.
+
+This is NOT a code quality review. This is NOT a SonarQube scan. This is a Business Requirements
+Compliance Audit.
+
+---
+
+## When This Skill Applies
+
+Use this skill when:
+- The user provides (or points to) BRD.md, USER_STORIES.md, and TEST_CASES.md
+- The user types `code-test-coverage-analyzer`, `/audit-requirements`, or similar
+- The user asks "does our implementation match the requirements?"
+- The user asks "what features are missing?", "what is the compliance score?", "audit the project against specs"
+- Before a sprint review or production release
+- After a major implementation to verify completeness
+
+Do NOT use this skill when:
+- No requirement documents are provided
+- The user only wants code review or refactoring
+- The user wants test generation (use tdd-spec-generator instead)
+
+---
+
+## Inputs
+
+### Required
+| Input | Description |
+|---|---|
+| `BRD.md` | Business Requirement Document — functional and non-functional requirements |
+| `USER_STORIES.md` | User stories with acceptance criteria |
+| `TEST_CASES.md` | Test cases with expected results |
+| Project Source Code | The codebase to audit |
+
+### Optional (include if provided)
+| Input | Description |
+|---|---|
+| Architecture Documents | High-level system design |
+| API Documents / Swagger / OpenAPI | API contracts |
+| Database Schema | Entity definitions |
+| Screen Specifications | Screen-level design documents |
+| Design Documents / Flow Diagrams | UX flows |
+
+---
+
+## Execution Mode
+
+| Archetype | Script % | LLM % |
+|---|---|---|
+| AI-Primary | ~10% | ~90% |
+
+| Layer | Responsibility |
+|---|---|
+| Script | Platform auto-detection |
+| Script | Directory tree generation |
+| LLM | All 12 passes of analysis |
+| LLM | BRD / User Story / Test Case parsing |
+| LLM | Evidence gathering from source files |
+| LLM | Status determination per requirement |
+| LLM | Coverage calculation |
+| LLM | All 15 report file generation |
+
+---
+
+## Step 0 — Collect Configuration
+
+Read `assets/config-questionnaire.md` and collect the following from the user BEFORE scanning any file.
+
+| # | Field | Type | Required | Notes |
+|---|---|---|---|---|
+| Q1 | BRD_PATH | file path | Yes | Path to BRD.md |
+| Q2 | USER_STORIES_PATH | file path | Yes | Path to USER_STORIES.md |
+| Q3 | TEST_CASES_PATH | file path | Yes | Path to TEST_CASES.md |
+| Q4 | PROJECT_ROOT | directory path | Yes | Root directory of the source code |
+| Q5 | OUTPUT_FOLDER | string | Yes | Name for output folder; warn if already exists |
+| Q6 | PLATFORM | enum | Auto-detected | Run `scripts/detect-platform.ps1`; prompt only if confidence=0 |
+| Q7 | OPTIONAL_DOCS | string[] | Optional | List of any additional documents provided |
+| Q8 | SCOPED_OUT_IDS | string[] | Optional | BRD requirement IDs deferred from this audit |
+| Q9 | PROJECT_TYPE | enum | Optional | Project type for coverage weight preset |
+| Q10 | PRIOR_AUDIT_PATH | path | Optional | Prior audit folder for delta comparison |
+
+Present the completed configuration summary and wait for user confirmation before proceeding.
+
+---
+
+## Step 1 — Platform Auto-Detection
+
+Run the platform detection script. Try both commands (Mac/Linux uses `pwsh`, Windows uses `powershell`):
+```powershell
+# Mac/Linux:
+pwsh .github/skills/code-test-coverage-analyzer/scripts/detect-platform.ps1 -ProjectRoot "<Q4>"
+# Windows:
+powershell .github/skills/code-test-coverage-analyzer/scripts/detect-platform.ps1 -ProjectRoot "<Q4>"
+```
+If neither command is available, skip the script and use the manual platform selection from Q6 in config-questionnaire.md.
+
+Map output to one reference file. Load ONLY the matching reference:
+
+| Platform | Reference File |
+|---|---|
+| ReactNative | `references/react-native-patterns.md` |
+| React | `references/react-patterns.md` |
+| Angular | `references/angular-patterns.md` |
+| Flutter | `references/flutter-patterns.md` |
+| Android | `references/android-patterns.md` |
+| iOS | `references/ios-patterns.md` |
+| NestJS | `references/backend-patterns.md` |
+| NodeJS | `references/backend-patterns.md` |
+| SpringBoot | `references/backend-patterns.md` |
+| DotNet | `references/backend-patterns.md` |
+| Go | `references/backend-patterns.md` |
+| Unknown | Ask user to select from Q6 options; re-route after response |
+
+When loading `references/backend-patterns.md`, read ONLY the section matching the detected platform.
+Each section is labeled "## {Platform} — read this section only if Platform={X}." Skip all other sections.
+
+---
+
+## Step 2 — Parse Requirement Documents
+
+Before scanning a single source file, fully parse all three input documents.
+
+### 2A — Parse BRD.md
+
+Read Q1 file completely. Extract every requirement. For each:
+- Assign a BRD-ID (e.g., BRD-001, BRD-002) if not already present
+- Extract: Category, Requirement Text, Priority, Acceptance Condition
+- Detect requirement type: Functional | Non-Functional | UI | API | Validation | Business Rule | Navigation | Calculation | Security | Performance
+
+Build the **BRD Requirement Catalog** — a structured list of all requirements.
+
+### 2B — Parse USER_STORIES.md
+
+Read Q2 file completely. Extract every user story. For each:
+- Assign a Story-ID (e.g., US-001) if not already present
+- Extract: Role, Goal, Business Value
+- Extract every acceptance criterion individually
+- Assign Criterion-ID (e.g., US-001-AC-01)
+- Detect related BRD requirements (by keyword and context match)
+
+Build the **User Story Catalog**.
+
+### 2C — Parse TEST_CASES.md
+
+Read Q3 file completely. Extract every test case. For each:
+- Assign TC-ID (e.g., TC-001) if not already present
+- Extract: Scenario, Preconditions, Test Steps, Expected Result
+- Identify related User Story ID and BRD requirement ID
+- Classify test type: Functional | Validation | Navigation | API | Business Logic | UI | Edge Case | Negative
+
+Build the **Test Case Catalog**.
+
+### 2D — Cross-Reference and Conflict Detection
+
+Build initial traceability links:
+- BRD-ID → Related Story-IDs → Related TC-IDs
+- Flag any TC that has no BRD or Story link (orphan test)
+- Flag any BRD requirement with no related Story or TC (orphan requirement)
+
+**Conflict Detection (mandatory)**:
+Load `assets/conflict-resolution-protocol.md` now. For each entity shared across documents
+(same field name, same screen, same API endpoint, same business rule), compare constraints:
+- Does the BRD specify one value while a User Story specifies a different value?
+- Does one BRD section contradict another BRD section?
+- Does an acceptance criterion require different behavior than the parent story?
+
+Apply the conflict detection algorithm from conflict-resolution-protocol.md. Flag all CONFLICTED
+pairs with a CONFLICT-ID before proceeding to Pass 1. CONFLICTED items score 0% coverage until
+the conflict is resolved by the project team.
+
+---
+
+## Step 3 — Generate Repository Directory Tree
+
+Run the repository scan script. Try both commands:
+```powershell
+# Mac/Linux:
+pwsh .github/skills/code-test-coverage-analyzer/scripts/scan-repository.ps1 -ProjectRoot "<Q4>" -Platform "<Q6>"
+# Windows:
+powershell .github/skills/code-test-coverage-analyzer/scripts/scan-repository.ps1 -ProjectRoot "<Q4>" -Platform "<Q6>"
+```
+The script output is the authoritative Master File List. Proceed to Step 3B using this output.
+
+---
+
+## Step 3B — Exhaustive File Enumeration (MANDATORY)
+
+Before any pass begins, build the **Master File List** — a complete catalogue of every source file
+in the project. This is not optional. Every file must appear in this list. No file may be skipped.
+
+**How to build**:
+1. Use the output from Step 3's scan-repository.ps1 as the Master File List. Do NOT run a separate
+   Glob enumeration — the script output is the authoritative categorized file list.
+   Only use Glob directly if the script could not be executed (no PowerShell available).
+2. Organize into these mandatory categories:
+
+| Category | What goes here |
+|---|---|
+| **Screens** | All screen / page / activity / view-controller files |
+| **Components** | All reusable UI component files (not full screens — buttons, cards, inputs, modals, bottom sheets, loaders, banners, etc.) |
+| **Hooks** | All custom hook files (useXxx.ts, *_hook.dart, etc.) |
+| **APILayer** | All service, repository, data-source, API-client files |
+| **StateManagement** | All slice, reducer, action, effect, BLoC, Cubit, ViewModel, store files |
+| **Navigation** | All navigator, router, route-definition files |
+| **BusinessLogic** | All use-case, interactor, manager, domain-service, calculation-service files |
+| **Validation** | All schema, validator, form-rule, field-validation files |
+| **Models** | All model, DTO, entity, request/response files |
+| **Core/Security** | All encryption, security, crypto, auth, interceptor, middleware, session files |
+| **Constants** | All constants, config, enum, theme, color, typography files |
+| **Utilities** | All helper, formatter, calculator, date-util, string-util, number-util files |
+| **Localization** | All i18n, l10n, translation, strings, ARB, Localizable.strings files |
+| **Tests** | All test, spec, mock, fixture files |
+| **Assets** | All image, font, icon, lottie asset files |
+| **Generated** | All auto-generated files (note but still inspect for enum values / constants) |
+| **Other** | Everything else |
+
+3. Record the **total file count** per category and the **total across all categories**.
+4. This list is the **read obligation** — every file in every category (except Assets and Generated)
+   must be opened and inspected at least once during the 12 passes.
+5. After all passes complete, verify that every non-excluded file was read. Files not read during
+   a logical pass must be read in a catch-up sweep before Pass 12.
+
+**Commitment statement** (print this at the start of analysis):
+```
+EXHAUSTIVE SCAN COMMITMENT
+Total source files to read: {N}
+  Screens:          {n}
+  Components:       {n}
+  Hooks:            {n}
+  APILayer:         {n}
+  StateManagement:  {n}
+  Navigation:       {n}
+  BusinessLogic:    {n}
+  Validation:       {n}
+  Models:           {n}
+  Core/Security:    {n}
+  Constants:        {n}
+  Utilities:        {n}
+  Localization:     {n}
+  Tests:            {n}
+  Other:            {n}
+No file will be skipped.
+```
+
+---
+
+## §Repository Scanning Efficiency
+
+### Read-Once Principle
+Each source file is read once, in the earliest pass that requires it. Subsequent passes reference
+findings from the Inventory built in that first pass. Passes 3–11 must say "using findings from
+[Pass N] Inventory" rather than re-reading the same files.
+
+### Grep-First Principle
+Use Grep for pattern discovery across many files. Use Read only for logic flow, context, and
+confirmed evidence. For a new requirement type search:
+1. Grep the whole codebase for the most discriminating pattern
+2. Read only the matched files for verification
+Do NOT read every file in a category to find one pattern when Grep can locate it in one call.
+
+### Large File Protocol
+Before reading any source file:
+- Quickly check if it exceeds 2000 lines (using a head/wc equivalent or read with a limit probe)
+- If it exceeds 2000 lines: read in 1800-line chunks with a 200-line overlap between chunks
+- Record key findings from each chunk before proceeding to the next chunk
+- Files confirmed under 2000 lines may be read in one call
+
+### String Map Durability
+After building the String Map in Pass 1, write it to `{Q5}/wip/string-map.md` before proceeding
+to Pass 2. Every subsequent pass must reference this file rather than reconstructing from memory.
+Passes must use `Read {Q5}/wip/string-map.md` for string lookups, not recall from context.
+
+---
+
+## §Checkpoint Protocol
+
+After each pass completes, write a checkpoint file before starting the next pass:
+```
+Write: {Q5}/wip/pass-{N}-findings.md
+Content: Summary of findings from this pass (finding count, key discoveries, files read)
+```
+
+If context approaches its limit mid-pass:
+1. Complete the current requirement being analyzed
+2. Write the checkpoint file for the current pass
+3. State explicitly: "CHECKPOINT: Pass {N} complete — {M} requirements assessed. Resume from Pass {N+1}."
+4. The user can continue in a new session starting from Pass {N+1}
+
+This prevents silent truncation where the audit continues from an empty context and produces
+incomplete findings with no indication of the truncation.
+
+---
+
+## Multi-Pass Repository Analysis
+
+Perform the following passes. Each pass is a targeted scan of source files.
+Do NOT skip any pass. Do NOT combine passes into one.
+After every pass, record findings in working memory AND write a checkpoint file before proceeding.
+
+**EXHAUSTIVENESS RULE**: Every pass must process its full file set — not a sample, not the first N
+files. If a pass covers "all service files", it means EVERY file in the APILayer + BusinessLogic
+categories. Mark each file as "read" as you go. At the end of all passes, any unread file must be
+read in a sweep before Pass 12.
+
+---
+
+### Pass 1 — Project Structure Discovery
+
+**Goal**: Map the complete project architecture and read every structural / configuration file.
+
+Scan: ALL directories and files under Q4 using the Master File List from Step 3B.
+Read every file in: **Constants**, **Core/Security**, **Localization**, and **Generated** categories.
+Also read: package.json / pubspec.yaml / build.gradle, .env files, app.config.ts/js, app.json.
+
+Discover and record:
+- Top-level folder structure (src, lib, app, features, modules, etc.)
+- Technology stack (languages, frameworks, state management)
+- State management library (Redux, Zustand, BLoC, NgRx, Provider, GetX, ViewModel, etc.)
+- HTTP client (Axios, Dio, OkHttp, Alamofire, fetch, etc.)
+- Navigation library (React Navigation, GoRouter, Angular Router, NavController, etc.)
+- Authentication mechanism (JWT, OAuth, session tokens, encryption)
+- Security / encryption implementation (ECDH, AES, RSA, SSL pinning, etc.)
+- Localization/i18n setup — read ALL string resource files and resolve ALL message keys
+- Feature flags and environment flags
+- Configuration files — read every .env, constants file, and config file completely
+- Build configuration
+- Every enum definition (enums constrain allowed values for fields and statuses)
+- Every theme / typography / color constant (these define UI labels via constants)
+- Middleware, interceptors, and request/response transformers
+
+**Resolve all string constants now** — before any pass that needs to compare text.
+Read every localization file (Localizable.strings, en.json, strings.xml, ARB files, messages.ts).
+Build a **String Map**: key → resolved string. Every validation message, button label, and
+error text must be resolvable from this map without re-reading localization files each time.
+
+**String Map Durability**: Write the String Map to `{Q5}/wip/string-map.md` immediately after
+building it. Format: one row per key (key | resolved string | source file). All subsequent passes
+must use `Read {Q5}/wip/string-map.md` for string lookups — never reconstruct from context.
+
+Output: **Architecture Fingerprint** + **String Map** (in `{Q5}/wip/string-map.md`) + **Constant Inventory**.
+
+---
+
+### Pass 2 — Screen AND Component Discovery
+
+**Goal**: Enumerate ALL user-facing screens AND all reusable UI components AND all hooks.
+This pass covers the entire UI layer — not just top-level screens.
+
+#### Pass 2A — Screen Discovery
+
+Read EVERY file in the **Screens** category from the Master File List (Step 3B).
+Do not skip any screen file.
+
+Platform screen patterns (for file categorization reference):
+| Platform | Screen Patterns |
+|---|---|
+| React Native | `*Screen.tsx`, `*Screen.ts`, `*Page.tsx`, `*View.tsx`; exports from `screens/` directories |
+| React | `*Page.tsx`, `*View.tsx`, route-registered components |
+| Angular | `*.component.ts` registered in routing modules |
+| Flutter | `*_screen.dart`, `*_page.dart`; widgets with `Scaffold` |
+| Android | `*Activity.kt`, `*Fragment.kt`, `*Activity.java`, `*Fragment.java` |
+| iOS | `*ViewController.swift`, `*View.swift`, UIViewController subclasses |
+
+For each screen, record:
+- File path
+- Screen name
+- Parent module/feature
+- Every form field (name, type, placeholder, label)
+- Every button (label, action)
+- Every conditional UI element (condition, element shown/hidden)
+- Navigation calls in/out
+- API calls made (note the call site)
+- State management usage (which store/slice/BLoC)
+- Loading state indicator present: Yes/No
+- Empty state component present: Yes/No
+- Error state handling: Yes/No
+
+Output: **Screen Inventory**.
+
+#### Pass 2B — Component Discovery
+
+Read EVERY file in the **Components** category from the Master File List.
+Do not skip any component file — every reusable widget, card, modal, button, input, bottom sheet,
+loader, banner, form field, header, footer, list item, empty state, and error state component
+must be inspected.
+
+For each component, record:
+- File path
+- Component name
+- Props accepted (especially: label, placeholder, errorMessage, value, onPress)
+- UI elements it renders
+- Any hardcoded text (button labels, default messages, placeholder text)
+- Any conditional rendering logic
+- Any validation it performs internally
+- Which screens import and use it (back-reference from Screen Inventory)
+
+**Why components matter**: Requirements may prescribe specific button text, placeholder text,
+or error messages that live inside shared components, not in screen files. A compliance check
+on the screen alone will miss these. Every component that renders text or validation feedback
+must be read.
+
+Output: **Component Inventory**.
+
+#### Pass 2C — Hook Discovery
+
+Read EVERY file in the **Hooks** category from the Master File List.
+Custom hooks often contain the actual business logic, validation, and state management
+that screens delegate to.
+
+For each hook, record:
+- File path
+- Hook name
+- What it does (state it manages, side effects, API calls)
+- Validation rules it contains
+- Business conditions it evaluates
+- Which screens/components use it
+
+Output: **Hook Inventory**.
+
+---
+
+### Pass 3 — API Discovery
+
+**Goal**: Enumerate ALL API calls made from the project. Every single endpoint call.
+
+Read EVERY file in the **APILayer** category from the Master File List.
+Also read every file in **Core/Security** (interceptors, middleware, request wrappers).
+Also read every file in **Hooks** that makes API calls (check Hook Inventory from Pass 2C).
+Also read every **Screen** file for inline API calls not delegated to a service.
+
+Do NOT stop after finding the obvious service files. Check:
+- Shared API client / axios instance configuration files
+- Interceptor files (request interceptors, response interceptors)
+- Auth interceptor / token injection files
+- Retry logic files
+- Error handler middleware
+- Any file that calls `fetch(`, `axios.`, `.get(`, `.post(`, `.request(`, `dio.`, `http.`
+
+Scan all repository, service, and data source files. Using the platform reference:
+
+| Platform | API Patterns |
+|---|---|
+| React Native / React | `axios.get/post/put/delete`, `fetch(`, `apiClient.`, `.request(`, service class methods |
+| Angular | `HttpClient.get/post/put/delete`, `http.`, service class `@Injectable` |
+| Flutter | `dio.get/post/put/delete`, `http.get/post`, repository class methods |
+| Android | `OkHttp.newCall`, `Retrofit` interface methods, `HttpURLConnection` |
+| iOS | `URLSession.dataTask`, `Alamofire.request`, `AF.request` |
+
+For each API call, record:
+- HTTP method (GET/POST/PUT/PATCH/DELETE)
+- Endpoint URL or path template
+- Request payload structure
+- Response model
+- Authentication (token injected? which header?)
+- Error handling (which HTTP codes handled?)
+- Retry logic
+- Timeout configuration
+- File path and function name
+
+Output: **API Inventory** — complete list of all API calls with metadata.
+
+---
+
+### Pass 4 — Business Logic Discovery
+
+**Goal**: Enumerate ALL business rules, conditions, and decision trees implemented.
+Every file that contains conditional logic related to a business outcome must be read.
+
+Read EVERY file in: **BusinessLogic**, **StateManagement**, **Hooks**, **Utilities** categories.
+Also read: every Screen file (screens often contain inline business logic).
+Also read: every Component file (components may encode business rules in their props/rendering).
+Also read: every file in Core/Security (security rules are business rules).
+
+Do NOT assume business logic only lives in "service" files. It can be in:
+- Redux thunks and selectors
+- React hooks (useEffect with conditions, useMemo with calculations)
+- ViewModel computed properties
+- BLoC event handlers
+- Screen-level onSubmit handlers
+- Utility functions used by multiple screens
+- Constants files that define business thresholds (MIN_AMOUNT, MAX_RETRIES, etc.)
+
+Scan: Service files, BLoC files, ViewModel files, Thunks, Reducers, Use Cases, Interactors, Helpers, Utilities.
+
+Look for:
+- Conditional branches related to eligibility, approval, status
+- Threshold and limit checks (amount limits, count limits, age checks)
+- Status transitions and state machines
+- Interest / charge / fee / tax calculations
+- Date-based rules (maturity, expiry, lockout periods)
+- Discount and tier logic
+- Permission-gated behavior
+- Role-based logic
+
+For each business rule, record:
+- Rule description (inferred from code)
+- File path, function name, line range
+- Input conditions
+- Output/effect
+- Related constants or config values
+
+Output: **Business Logic Inventory**.
+
+---
+
+### Pass 5 — Validation Discovery
+
+**Goal**: Enumerate ALL input validations implemented — in every file they appear in.
+Validation is scattered. It appears in schemas, components, hooks, screens, services, and
+even constants files. Read ALL of them.
+
+Read EVERY file in: **Validation**, **Screens**, **Components**, **Hooks**, **Models** categories.
+Also read: every Constants file (regex constants, min/max value constants).
+Also read: every Localization file (already done in Pass 1 — use the String Map).
+
+Validation can appear in:
+- Yup / Zod / Joi schema definitions
+- React Hook Form `register()` options
+- Angular Validators in FormGroup / FormControl
+- Flutter TextFormField `validator:` callbacks
+- Android binding error setters
+- iOS guard statements and NSPredicate matchers
+- Custom hooks that validate before API calls
+- Shared input components that have built-in validation props
+- Constants that define REGEX patterns, MIN lengths, MAX lengths
+- Server-side validation response mapping (what API error codes become what UI messages)
+
+For every validation found, also check:
+- Is the same field validated in a shared component AND in a screen schema? Do they conflict?
+- Is the validation message hardcoded or resolved from a constant/localization key?
+- If it's a key, resolve the actual string using the String Map from Pass 1.
+
+Scan: Form files, screen files, validators, schema files (Yup, Joi, Formik, reactive forms, BLoC validators, ViewModel validators).
+
+For every validation found, record:
+- Field name
+- Validation type (required, min, max, regex, custom, cross-field)
+- Validation rule (exact regex or condition)
+- Error message (exact string or string resource key — resolve to actual string)
+- Where triggered (onBlur, onChange, onSubmit, server-side)
+- File path
+
+Also scan:
+- Server-side validation responses (API error codes mapped to messages)
+- Localization files for validation strings
+
+Output: **Validation Inventory** — field by field, rule by rule.
+
+---
+
+### Pass 6 — Navigation Discovery
+
+**Goal**: Map ALL navigation flows implemented — in every file they appear in.
+
+Read EVERY file in the **Navigation** category from the Master File List.
+Also read: every Screen file (navigation calls originate in screens).
+Also read: every Hook file (navigation is often in custom hooks).
+Also read: every Component file (some components navigate on press).
+Also read: Auth files (authentication triggers navigation).
+
+Do NOT just check the router config file. Also check:
+- Deep link handler files
+- Notification tap handlers (navigate on notification)
+- App-level lifecycle files (navigate on session expiry, on cold start)
+- Auth middleware (redirect on unauthorized)
+- Error boundary files (navigate on fatal error)
+
+Using the platform reference, scan for:
+
+| Platform | Navigation Patterns |
+|---|---|
+| React Native | `navigation.navigate(`, `navigation.push(`, `navigation.goBack(`, `useNavigation`, Stack/Tab/Drawer navigators |
+| React | `useNavigate`, `<Link to=`, `useRouter`, `router.push(`, route definitions |
+| Angular | `router.navigate(`, `routerLink=`, `Router.navigateByUrl`, route guards |
+| Flutter | `Navigator.push(`, `Navigator.pushNamed(`, `GoRouter.go(`, `context.go(` |
+| Android | `startActivity(Intent(`, `NavController.navigate(`, `findNavController(` |
+| iOS | `navigationController?.pushViewController`, `present(`, `NavigationLink(` |
+
+For each navigation, record:
+- Source screen
+- Destination screen
+- Trigger (button tap, API success, error, lifecycle)
+- Parameters passed
+- Back navigation behavior
+- Deep link pattern (if any)
+- Authentication guard (if any)
+
+Output: **Navigation Flow Map**.
+
+---
+
+### Pass 7 — Calculation Discovery
+
+**Goal**: Find ALL mathematical or business calculations in the codebase — wherever they live.
+
+Read EVERY file in: **Utilities**, **BusinessLogic**, **Hooks**, **StateManagement** categories.
+Also re-scan every Screen file for inline calculations not extracted to a utility.
+Also read every Component file for calculations within render logic.
+
+Calculations can hide in:
+- A single line inside a screen's `onSubmit` handler
+- A `useMemo` or `useSelector` in a hook
+- A formatted display value computed in a list item component
+- A computed property in a ViewModel
+- An event handler in a BLoC
+
+Scan: Calculation services, utility files, business logic files, ViewModel files, BLoC handlers, reducers.
+
+Look for:
+- Interest rate calculations
+- EMI / installment calculations
+- Fee and charge computations
+- Tax calculations
+- Discount computations
+- Date difference calculations (days, months, years between dates)
+- Percentage calculations
+- Currency formatting logic
+- Amount rounding rules
+- Limit and threshold computations
+
+For each calculation, record:
+- Formula (expressed as algebraic formula: `result = a op b`)
+- File path, function name, exact code snippet
+- Input parameters and types
+- Output type
+- Edge case handling (null, zero division, negative)
+
+Output: **Calculation Inventory**.
+
+---
+
+### Pass 7B — Security Deep-Dive
+
+**Goal**: Perform a dedicated security audit of all security-related files before the BRD comparison.
+This pass builds the Security Inventory that feeds into File 15.
+
+Read EVERY file in the **Core/Security** category from the Master File List.
+Also read: interceptor files, middleware files, auth wrapper files, token handler files.
+Also grep for: encryption, jwt, bcrypt, hash, salt, cipher, session, pin, password, biometric.
+
+For each security control found, record:
+- Control type: Encryption | Token | PIN | Session | Auth | SSL | Error Safety | Logging
+- Implementation file path and function name
+- Data protected (what is being secured)
+- Algorithm or mechanism used
+- Key/secret management approach
+- Expiry or rotation behavior
+
+**Security checks to perform**:
+1. **Encryption** — read the encryption utility. Confirm algorithm (AES-256? RSA? ECDH?).
+   Confirm key derivation. Confirm IV/salt generation. Compare against BRD security requirements.
+2. **Token storage** — find where access tokens and refresh tokens are stored.
+   Flag if stored in plain AsyncStorage/localStorage without encryption.
+3. **PIN lockout** — find the lockout logic. Confirm threshold, duration, and reset behavior.
+   Compare against BRD requirements.
+4. **Session timeout** — find the session timeout logic. Confirm enforcement.
+5. **SSL pinning** — check if certificate pinning is configured for production.
+6. **Sensitive data in logs** — grep for console.log / Log.d / print near PIN, password, token, OTP.
+7. **Error message safety** — find global error handlers. Check that stack traces and internal
+   paths are not exposed in error messages shown to the user.
+8. **Biometric auth** — if required, verify it is wired to the auth flow correctly.
+
+Output: **Security Inventory** — used by Pass 11H Self-Verification and File 15.
+
+---
+
+### Pass 8 — BRD Comparison
+
+**Goal**: For every requirement in the BRD Requirement Catalog, find evidence in the source code.
+
+**Before starting this pass**: Load `assets/status-definitions.md` — it is the ONLY authoritative
+source for all status definitions. Do not rely on status descriptions elsewhere in this file.
+
+For each BRD requirement:
+
+1. Identify the requirement type (from Step 2A)
+2. Search relevant layers based on type (use findings from Inventories built in Passes 1–7B):
+   - UI requirement → Search Screen Inventory AND Component Inventory AND Hook Inventory.
+     If a UI requirement is not found in screen files, check ALL components used by those screens
+     before declaring MISSING. UI elements often live in shared components, not in screen files.
+   - API requirement → Search API Inventory, service files
+   - Validation requirement → Search Validation Inventory
+   - Business Logic requirement → Search Business Logic Inventory, service files
+   - Navigation requirement → Search Navigation Flow Map
+   - Calculation requirement → Search Calculation Inventory
+   - Security requirement → Search Security Inventory (from Pass 7B), Core/Security files
+   - Performance requirement → Search config files, loading indicators, lazy loading
+3. For every search: read actual source files to confirm evidence
+4. **Before marking MISSING**: Follow the protocol in `assets/multi-strategy-search.md`.
+   All six search strategies must be exhausted (or confirmed inapplicable for the requirement type).
+   Record evidence from each strategy attempted. Two strategies is never sufficient.
+5. **Feature Flag handling**: If a requirement's implementation is gated behind a feature flag,
+   mark IMPLEMENTED with qualifier "FEATURE FLAG GATED: {flag name}". Check the flag's default
+   value and environment-specific values. If the flag is off in all environments, downgrade to
+   PARTIALLY_IMPLEMENTED.
+6. Assign status using `assets/status-definitions.md` (the loaded authoritative source)
+7. Record evidence: file path, function/class name, line range, code excerpt (max 5 lines)
+
+**Status options** (see `assets/status-definitions.md` for full definitions):
+- `IMPLEMENTED` — complete, correct implementation found with evidence
+- `PARTIALLY_IMPLEMENTED` — implementation exists but incomplete or deviates
+- `MISSING` — no implementation found after exhaustive six-strategy search
+- `INCORRECT` — implementation exists but contradicts the requirement
+- `EXTRA` — implemented feature not requested in BRD (flag as extra)
+- `NOT_VERIFIED` — insufficient evidence to make a determination
+- `CONFLICTED` — contradictory specifications across documents (set in Step 2D)
+- `SCOPED_OUT` — excluded from audit scope via Q8
+
+Record confidence level: `HIGH` | `MEDIUM` | `LOW` (per decision tree in status-definitions.md)
+
+Output: **BRD Compliance Matrix**.
+
+---
+
+### Pass 9 — User Story Comparison
+
+**Goal**: For every user story and every acceptance criterion, verify implementation.
+
+For each User Story:
+1. Identify the business flow being tested
+2. Verify the complete end-to-end flow:
+   - UI elements (form, buttons, labels, icons) — check Screen Inventory + screen files
+   - Navigation (from where, to where) — check Navigation Flow Map
+   - API calls (which endpoint, payload, response mapping) — check API Inventory
+   - Business rules (eligibility, conditions) — check Business Logic Inventory
+   - Validation (every field mentioned) — check Validation Inventory
+   - Calculations (any formula mentioned) — check Calculation Inventory
+   - Error handling (what happens on failure) — read error handling in files
+   - Loading states — check screen files for loading indicators
+   - Empty states — check screen files for empty state components
+   - Retry behavior — check error handling, retry logic
+   - Offline handling — check network error handling
+   - Localization — check string resources / i18n files
+   - Accessibility — check accessibility labels, screen readers
+
+For each Acceptance Criterion (AC):
+- Verify individually
+- Assign status: `SATISFIED` | `PARTIALLY_SATISFIED` | `NOT_SATISFIED` | `NOT_VERIFIABLE`
+- Record evidence
+
+Output: **User Story Compliance Matrix**.
+
+---
+
+### Pass 10 — Test Case Comparison
+
+**Goal**: For every test case, logically execute it against the implementation.
+
+Do NOT check if a test file exists. Instead, determine if the actual implementation can satisfy the test case.
+
+For each Test Case:
+
+1. Read the test steps and expected result
+2. Trace through the actual implementation:
+   - Step 1 of TC → Which screen does this map to? Does it exist?
+   - Step 2 of TC → Which action is performed? Is it implemented?
+   - ...
+   - Expected Result → Does the implementation produce this result?
+3. Check:
+   - Is the relevant screen implemented?
+   - Is the required API call made with the correct payload?
+   - Is the response correctly mapped?
+   - Is the expected validation message displayed with exact text?
+   - Is the expected navigation triggered?
+   - Is the expected UI state shown?
+4. Assign test case verdict:
+   - `PASS` — implementation fully satisfies all test steps and expected result
+   - `PARTIAL_PASS` — most steps pass but one or more expected results are wrong
+   - `FAIL` — implementation cannot satisfy the test case
+   - `NOT_IMPLEMENTED` — required feature/screen/API does not exist
+   - `BLOCKED` — test case depends on another missing feature
+   - `UNKNOWN` — cannot determine due to insufficient code evidence
+
+For FAIL, PARTIAL_PASS, and NOT_IMPLEMENTED, record:
+- Which step fails
+- What is missing
+- Which file is the gap in
+- What specific function, validation, or UI element is absent
+
+Output: **Test Case Results Matrix**.
+
+---
+
+### Pass 11 — Cross-Validation
+
+**Goal**: Identify inconsistencies and gaps across all previous passes.
+
+Perform the following cross-checks:
+
+**11A — Validation Message Audit**
+For every validation message found in the Validation Inventory:
+- Compare exact message text against BRD requirements
+- Compare against User Story acceptance criteria
+- Compare against Test Case expected results
+- Flag any mismatch, even minor (e.g., "Mobile required" vs "Please enter mobile number")
+
+**11B — API Contract Audit**
+For every API in the API Inventory:
+- Compare endpoint, method, payload against BRD / API documentation if provided
+- Verify response mapping against model definitions
+- Check that every required API mentioned in BRD / User Stories is present
+- Flag extra APIs not mentioned in requirements
+
+**11C — UI Label Audit**
+For every screen in the Screen Inventory:
+- Extract all visible text labels, button text, placeholder text, error messages
+- Compare against BRD / User Stories where specific text is prescribed
+- Flag mismatches
+
+**11D — Navigation Flow Audit**
+- Compare Navigation Flow Map against required flows in BRD / User Stories
+- Flag missing flows
+- Flag extra flows not requested
+
+**11E — Extra Implementation Detection**
+Using all inventories, identify:
+- Screens that exist but are not mentioned in any requirement
+- APIs called that are not referenced in any requirement
+- Business logic / calculations not traced to any requirement
+- Validations not mentioned in any requirement
+- Navigation flows not mentioned in any requirement
+
+**11F — Orphan Analysis**
+- BRD requirements with no User Story or Test Case coverage → flag as orphan
+- User Stories with no BRD traceability → flag as orphan
+- Test Cases with no User Story or BRD traceability → flag as orphan
+- Implemented features with no requirement traceability → flag as extra
+
+**11G — Localization Audit**
+- Read the primary locale file (en.json / en.strings / Localizable.strings / app_en.arb)
+- Read all other locale files (fr.json, es.json, ar.json, etc.)
+- For each key in the primary locale, verify it exists in all other locale files
+- Flag missing translation keys (primary key absent from another locale)
+- Also compare required string keys from BRD against the primary locale file
+- Flag BRD-required strings that are absent from ALL locale files
+- Add findings to File 06 §Localization Coverage table
+
+**11H — Self-Verification Protocol** (mandatory before Pass 12)
+Before generating any report:
+1. Randomly select 3 IMPLEMENTED findings and 2 INCORRECT findings from the BRD Compliance Matrix
+2. For each selected finding, re-open the cited file at the cited function
+3. Confirm: (a) the file path exists, (b) the function/component exists, (c) the described behavior
+   matches what the code actually does
+4. If any verification fails: downgrade the status to NOT_VERIFIED (citing "Self-verification failed:
+   {reason}") and extend the verification check to ALL findings in that category
+5. Record self-verification results: "{N} of 5 spot-checks CONFIRMED, {M} REVISED"
+
+Output: **Cross-Validation Findings** + **Self-Verification Summary**.
+
+---
+
+### Pass 12 — Report Generation
+
+**Goal**: Generate all 15 output files.
+
+Load `assets/output-file-contracts.md` before generating any file.
+Follow each file's content contract exactly.
+**Generate files in this sequence** (see §Generation Order in output-file-contracts.md for rationale):
+
+**Phase 1** — Detail files (any order within this phase):
+Files 02, 03, 04, 05, 06, 07, 08, 09, 10, 11
+
+**Phase 2** — Extra implementation:
+File 12
+
+**Phase 3** — Scorecard (aggregates all Phase 1 + Phase 2 scores):
+File 13
+
+**Phase 4** — Executive Summary (derived from File 13 scorecard — MUST be after File 13):
+File 01
+
+**Phase 5** — Recommendations and Security:
+Files 14 and 15
+
+Do NOT generate File 01 first. File 01 requires the weighted score from File 13.
+Do NOT skip any file. Do NOT leave placeholder text (`[...]`, `TODO`, `N/A`) in any file
+unless explicitly allowed by the contract.
+
+---
+
+## Status Definitions
+
+Load `assets/status-definitions.md` before Pass 8. This is the ONLY authoritative source for all
+status definitions, confidence levels, message match statuses, CONFLICTED, and SCOPED_OUT.
+Do not rely on the brief descriptions in this file — they are for orientation only.
+
+The status taxonomy covers: IMPLEMENTED, PARTIALLY_IMPLEMENTED, MISSING, INCORRECT, EXTRA,
+NOT_VERIFIED, CONFLICTED, SCOPED_OUT (BRD requirements); PASS, PARTIAL_PASS, FAIL,
+NOT_IMPLEMENTED, BLOCKED, UNKNOWN (Test Cases); SATISFIED, PARTIALLY_SATISFIED, NOT_SATISFIED,
+NOT_VERIFIABLE (Acceptance Criteria).
+
+---
+
+## Coverage Calculation
+
+Load `assets/coverage-calculation-rules.md` for the complete authoritative formula set.
+`coverage-calculation-rules.md` is the single source of truth for:
+- Dimension weight percentages (including Q9 project type preset adjustments)
+- Zero-denominator guards and weight redistribution
+- Grade scale (A+/A/A-/B+/B/B-/C+/C/C-/D/F)
+- Risk band definitions
+
+Coverage is NEVER based on file existence. Coverage is based on verified implementation.
+
+Key formula (from coverage-calculation-rules.md — use the file for exact weights):
+```
+TC Fail % = (FAIL + NOT_IMPLEMENTED + BLOCKED-with-no-BRD-link) / (Total TCs − BLOCKED-linked-to-MISSING) × 100
+Note: BLOCKED tests that are blocked by a MISSING BRD requirement already counted as MISSING
+      are excluded from both numerator and denominator to avoid double-penalizing the same gap.
+
+SCOPED_OUT items are excluded from ALL denominators — they do not affect any coverage score.
+CONFLICTED items score 0% until resolved.
+```
+
+Overall Compliance Score = weighted sum of all dimension scores (use weights from coverage-calculation-rules.md).
+If Q9 was set to a non-default project type, apply the matching weight preset from that file.
+
+---
+
+## Output Files
+
+Load `assets/output-file-contracts.md` for complete content specifications.
+
+### File 01 — 01_EXECUTIVE_SUMMARY.md
+**Audience**: Project managers, stakeholders, QA leads
+**Content**:
+- Project name, audit date, auditor (Claude Code)
+- Overall Compliance % (large, prominent)
+- Risk Score: `CRITICAL` (0–49%) | `HIGH` (50–69%) | `MEDIUM` (70–84%) | `LOW` (85–94%) | `MINIMAL` (95–100%)
+- Production Readiness: `NOT READY` | `NEEDS WORK` | `CONDITIONAL` | `READY`
+- Quality Score (weighted composite)
+- Coverage summary table (all dimensions in one table)
+- Top 5 critical missing features (with BRD IDs)
+- Top 5 critical test case failures (with TC IDs)
+- Key risks (3–5 bullets)
+- Immediate action items (3–5 bullets)
+
+### File 02 — 02_BRD_COMPLIANCE.md
+**Audience**: Business analysts, product managers
+**Content**:
+- BRD compliance summary table (counts by status)
+- BRD coverage pie chart (ASCII bar chart by status)
+- Detailed requirement table — for every BRD requirement:
+
+| Column | Content |
+|---|---|
+| BRD-ID | Requirement identifier |
+| Category | Requirement type |
+| Priority | Business priority |
+| Requirement | Requirement text |
+| Status | Implementation status |
+| Coverage % | Partial coverage percentage if PARTIALLY_IMPLEMENTED |
+| Evidence | File paths and function names |
+| Issues | What is missing or incorrect |
+| Recommendation | What needs to be done |
+
+- Group by Category (UI, API, Validation, Business Logic, Navigation, etc.)
+- Color-code: use markdown bold for MISSING, italics for PARTIAL
+
+### File 03 — 03_USER_STORY_COMPLIANCE.md
+**Audience**: Product owners, QA leads
+**Content**:
+- User story compliance summary
+- For each user story:
+  - Story ID, Role, Goal, Business Value
+  - Overall story status
+  - Acceptance criteria table: AC-ID | Criterion Text | Status | Evidence | Issues
+  - Business flow verified: Yes/Partial/No
+  - Missing elements list
+  - Recommendation
+- Group by feature/epic if detectable from story structure
+
+### File 04 — 04_TEST_CASE_COMPLIANCE.md
+**Audience**: QA engineers, test managers
+**Content**:
+- Test case summary (total, PASS, PARTIAL_PASS, FAIL, NOT_IMPLEMENTED, BLOCKED, UNKNOWN counts)
+- Pass rate as ASCII bar chart
+- For every test case:
+
+| Column | Content |
+|---|---|
+| TC-ID | Test case identifier |
+| Scenario | Test scenario name |
+| Type | Test type |
+| Related Story | US-ID |
+| Related BRD | BRD-ID |
+| Status | Verdict |
+| Expected Result | From test case |
+| Actual Implementation | What the code actually does |
+| Evidence | File paths |
+| Reason for Failure | If FAIL/PARTIAL_PASS |
+| Recommendation | What must be fixed |
+
+- Group by: FAIL first, then PARTIAL_PASS, then NOT_IMPLEMENTED, then BLOCKED, then PASS
+
+### File 05 — 05_VALIDATION_ANALYSIS.md
+**Audience**: Developers, QA
+**Content**:
+- Validation coverage summary
+- For every required validation (from BRD/Stories):
+  - Field name
+  - Required rule (from BRD)
+  - Implemented rule (from code, exact regex or condition)
+  - Required message (from BRD, exact text)
+  - Implemented message (from code, exact string)
+  - Message match: `EXACT` | `SIMILAR` | `MISMATCH` | `MISSING`
+  - Status
+  - File path
+- Validation Message Mismatch Table (all mismatches in one table)
+- Missing validations list
+- Extra validations list (implemented but not required)
+- Server-side validation coverage
+- Validation timing issues (required onChange but implemented onSubmit only)
+
+### File 06 — 06_UI_ANALYSIS.md
+**Audience**: UI developers, QA
+**Content**:
+- UI coverage summary
+- For each required screen:
+  - Screen name
+  - Implemented: Yes/No
+  - File path
+  - Required UI elements vs implemented (table: element, required, implemented, status)
+  - Label/text mismatches (required text vs implemented text)
+  - Missing elements
+  - Extra elements
+  - Conditional UI analysis (conditions that control element visibility)
+  - Loading state: implemented Yes/No
+  - Empty state: implemented Yes/No
+  - Error state: implemented Yes/No
+- Missing screens list
+- Extra screens list (no requirement reference)
+
+### File 07 — 07_API_ANALYSIS.md
+**Audience**: Backend developers, QA
+**Content**:
+- API coverage summary
+- For each required API (from BRD/Stories):
+  - Requirement reference (BRD-ID or US-ID)
+  - Required: method, endpoint, payload, response
+  - Implemented: method, endpoint (from API Inventory)
+  - Endpoint match: Yes/No
+  - Method match: Yes/No
+  - Authentication: required/implemented
+  - Error handling: required/implemented
+  - Retry: required/implemented
+  - Status
+  - File path
+- API not in requirements (extra APIs)
+- APIs in requirements but not implemented (missing APIs)
+- Response mapping issues
+- Authentication gaps
+
+### File 08 — 08_BUSINESS_LOGIC_ANALYSIS.md
+**Audience**: Developers, business analysts
+**Content**:
+- Business logic coverage summary
+- For each required business rule (from BRD/Stories):
+  - BRD-ID / US-ID reference
+  - Business rule description
+  - Rule type (condition, calculation, threshold, eligibility, state machine)
+  - Implementation status
+  - Evidence: file path, function name, code excerpt
+  - Issues (if PARTIAL or INCORRECT)
+  - Recommendation
+- Calculation verification:
+  - For each required calculation: formula, implemented formula (from code), match status, worked example
+- Missing business rules
+- Extra business logic (not in requirements)
+- Decision tree coverage
+
+### File 09 — 09_NAVIGATION_ANALYSIS.md
+**Audience**: Developers, QA
+**Content**:
+- Navigation coverage summary
+- Required navigation flows vs implemented flows (table)
+- For each required flow:
+  - Flow ID (from BRD / User Story)
+  - From screen → To screen
+  - Trigger condition
+  - Parameters
+  - Implemented: Yes/No
+  - File path
+  - Status
+- Missing navigation flows
+- Extra navigation (not in requirements)
+- Back navigation analysis
+- Deep link analysis (if required)
+- Auth guard on navigation: required vs implemented
+
+### File 10 — 10_TRACEABILITY_MATRIX.md
+**Audience**: Project managers, QA, auditors
+**Content**:
+Complete horizontal traceability table:
+
+| BRD-ID | BRD Requirement | Story-ID | Story Title | AC-IDs | TC-IDs | Implementation Files | Status |
+|---|---|---|---|---|---|---|---|
+
+- One row per BRD requirement
+- Orphan analysis section: BRD requirements with no story/TC, stories with no BRD, TCs with no story/BRD
+- Implementation gap analysis
+- Full traceability score (% of items with complete chain)
+
+### File 11 — 11_MISSING_FEATURES.md
+**Audience**: Developers, project managers
+**Content**:
+- Total missing features count
+- Grouped by priority: Critical, High, Medium, Low
+- For each missing feature:
+  - BRD-ID / US-ID
+  - Feature description
+  - Priority
+  - Impact assessment (what breaks without this)
+  - Effort estimate: High/Medium/Low (based on complexity)
+  - Dependencies (what other features depend on this)
+  - Recommendation
+- Missing API endpoints
+- Missing screens
+- Missing validations
+- Missing business rules
+- Missing navigation flows
+- Missing calculations
+
+### File 12 — 12_EXTRA_IMPLEMENTATION.md
+**Audience**: Project managers, architects
+**Content**:
+- Total extra implementation items found
+- For each extra item:
+  - Item type: Screen | API | Business Logic | Validation | Navigation | Calculation
+  - Description
+  - File path
+  - Assessment: Intentional (known extension) | Leftover (orphaned code) | Speculative (premature feature)
+  - Recommendation: Keep | Remove | Document as requirement | Defer
+- Risk assessment of extra implementation
+- Dead code analysis
+
+### File 13 — 13_COMPLIANCE_SCORECARD.md
+**Audience**: All stakeholders
+**Content**:
+- Visual scorecard (ASCII tables with scores)
+- Dimension scores:
+
+| Dimension | Score | Status |
+|---|---|---|
+| BRD Compliance | XX% | ✓ / ✗ |
+| User Story Fulfillment | XX% | |
+| Acceptance Criteria | XX% | |
+| Test Case Pass Rate | XX% | |
+| Validation Coverage | XX% | |
+| API Coverage | XX% | |
+| UI Coverage | XX% | |
+| Business Logic Coverage | XX% | |
+| Navigation Coverage | XX% | |
+| **Overall Compliance** | **XX%** | |
+
+- ASCII bar charts for each dimension
+- Benchmark comparisons:
+  - Production ready: ≥ 90%
+  - Acceptable for beta: ≥ 75%
+  - Needs significant work: < 75%
+  - Not shippable: < 50%
+- Trend indicators (if prior audit data available)
+- Quality gates status
+
+### File 14 — 14_FINAL_RECOMMENDATIONS.md
+**Audience**: All stakeholders, developers
+**Content**:
+- Executive decision: SHIP / CONDITIONAL SHIP / DO NOT SHIP
+- Rationale
+- Prioritized action plan — ordered list of what to fix:
+  - Priority 1 (Blockers): must fix before any release
+  - Priority 2 (Critical): fix before production release
+  - Priority 3 (Important): fix before stable release
+  - Priority 4 (Nice to have): can defer
+- Sprint plan suggestion: T-shirt size groupings (XL/L/M/S) — see output-file-contracts.md §File 14
+- Risk register (identified risks with likelihood and impact)
+- Technical debt items identified during audit
+- Process recommendations (what went wrong in requirements to implementation handoff)
+- Team recommendations (areas needing knowledge transfer or additional QA)
+
+### File 15 — 15_SECURITY_ANALYSIS.md
+**Audience**: Security engineers, compliance teams, all stakeholders
+**Content**:
+- Security findings summary (CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL)
+- Encryption compliance (algorithm, key management, data at rest and in transit)
+- Token and session security (storage, expiry, refresh, revocation)
+- PIN / password security (lockout, complexity, change flow, biometric)
+- Error message safety (stack trace exposure, internal path leakage)
+- SSL / certificate pinning status
+- Sensitive data logging scan results
+- Missing security requirements (required but not implemented)
+- Security recommendations (ordered by severity)
+See `assets/output-file-contracts.md` §File 15 for full contract.
+
+---
+
+## §Extensibility Guide
+
+### Adding a New Platform
+
+To add support for a new platform (e.g., Python/Django), touch these 4 files:
+
+1. **detect-platform.ps1** — Add a new detection block that checks for the platform's marker file
+   (e.g., `requirements.txt` containing `django`). Set `$result.platform = "Django"`.
+
+2. **scan-repository.ps1** — Add the new platform to the `[ValidateSet]` on the `$Platform` param.
+   Add file extensions to the `$extensions` switch block. Add backend category rules to
+   `Get-FileCategory` for the platform's file patterns.
+
+3. **SKILL.md §Step 1 routing table** — Add a row: `| Django | references/django-patterns.md |`
+
+4. **references/django-patterns.md** (new file) — Create following the same structure as
+   `backend-patterns.md`. Add "## Django — read this section only if Platform=Django" header.
+
+### Adding a New Output File
+
+1. **assets/output-file-contracts.md** — Add a new §File NN section with full content contract.
+2. **SKILL.md §Output Files** — Add a description of the new file.
+3. **SKILL.md §Pass 12** — Add the file to the appropriate generation phase.
+4. **SKILL.md Completion Report** — Add `[NN] NN_FILENAME.md` to the Files Generated list.
+
+### Adding a New Requirement Type
+
+1. **SKILL.md §Pass 8 Step 2** — Add a routing rule: `{Type} requirement → Search {Inventory}`.
+2. **assets/multi-strategy-search.md §Minimum Strategies** — Add the new type and its minimum
+   required strategies.
+
+---
+
+## Strict Rules (MUST follow every rule)
+
+1. **Never guess.** If you cannot find evidence in the source code, the status is `MISSING` or `NOT_VERIFIED`, never `IMPLEMENTED`.
+2. **Never hallucinate.** Do not invent file paths, function names, or code behavior. Only cite files you have read.
+3. **Never mark as implemented without evidence.** A requirement is not implemented until you have read the actual code that implements it.
+4. **Every finding must cite.** Every IMPLEMENTED, PARTIAL, or INCORRECT status must include: file path, function/class name (if applicable), and a brief description of what was found.
+5. **Never skip a requirement.** Every single BRD requirement, User Story, Acceptance Criterion, and Test Case must appear in the reports with a status.
+6. **Perform all 12 passes.** Do not combine passes. Do not skip passes. Each pass builds on the previous.
+7. **Read files, do not assume.** Use the Glob tool to find files and the Read/Grep tools to read them. Do not assume what a file contains based on its name alone.
+8. **Read EVERY source file — no exceptions.** The Master File List from Step 3B is a read obligation. Every file in every category (except Assets) must be opened and read at least once. A file that has not been opened cannot be claimed as searched.
+9. **Components are not optional.** Reusable UI components must be read. They contain text labels, placeholders, error messages, conditional rendering, and inline validation that screens delegate to them. A compliance check that only reads screens will miss component-level requirements.
+10. **Hooks are not optional.** Custom hooks contain business logic, validation, API calls, and state management. Every hook must be read and its logic catalogued.
+11. **Core and security files are not optional.** Interceptors, middleware, encryption modules, session managers, and auth wrappers implement critical cross-cutting requirements. Read them all.
+12. **Follow import chains.** When a screen imports a component, a component imports a hook, or a hook imports a service — that is an implementation chain. Follow it one level deep for every requirement being verified.
+13. **Constants define requirements.** Constant files (min/max values, regex patterns, timeout durations, retry counts) encode business rules. Every constant file must be read and its values compared against BRD requirements.
+14. **Validation messages must be exact.** When comparing validation messages, compare character-by-character. "Mobile number is required" and "Mobile number required" are a mismatch. Resolve string keys using the String Map built in Pass 1.
+15. **Resolve string resources.** If an error message is stored in a strings file (strings.xml, en.json, Localizable.strings), read that file and resolve the actual string before comparing.
+16. **Extra features are not failures.** Extra implementation is not a defect but must be reported separately in File 12.
+17. **Confidence must be honest.** Do not assign HIGH confidence unless you have directly read the implementing code. Do not assign LOW confidence speculatively — LOW means you found something suggestive but not conclusive.
+18. **Generate all 15 files.** Do not omit any output file, even if a section has nothing to report (report "None found"). File 15 (Security Analysis) is always generated regardless of platform.
+19. **No placeholder text in output files.** Every table cell, every finding, every recommendation must be filled. No `[TODO]`, `[TBD]`, or `[N/A]` unless the contract explicitly allows it.
+20. **Use all six search strategies.** Before marking any requirement as `MISSING`, follow the complete protocol in `assets/multi-strategy-search.md`. All six strategies must be exhausted (or confirmed inapplicable). Record evidence from each strategy. Two searches is never sufficient.
+21. **Search in components AND screens.** When a requirement mentions a UI element (button, field, label), search both Screen files AND Component files. The element may be in a shared component used by the screen.
+22. **Prioritize correctness over speed.** This audit takes precedence over response time. Scan thoroughly.
+23. **Framework agnostic.** Apply the platform reference loaded in Step 1. Do not impose assumptions from one framework onto another.
+24. **Report format must be professional.** Use proper markdown: headers, tables, bold for status, code blocks for code excerpts. The reports are read by non-technical stakeholders and developers alike.
+25. **No emojis in output files.** Use plain text status indicators and markdown formatting only.
+26. **Scores must be calculated, not estimated.** Every coverage percentage must be computed from actual counts. Show the calculation.
+27. **Output folder must be created at project root** unless the user specifies otherwise.
+28. **Report files read in completion summary.** The final completion report must include `Files read: {N}` — the total count of files actually opened during the audit. This number must match or exceed the non-asset, non-generated file count from the Master File List.
+29. **Unread files = coverage gap.** If a file category was not fully read, every requirement that could be implemented in that category must be marked `NOT_VERIFIED`, not `MISSING` or `IMPLEMENTED`. Partial scanning produces unreliable results.
+
+---
+
+## Completion Report
+
+After generating all 15 files, print:
+
+```
+AUDIT COMPLETE
+==============
+Skill Version: 3.0.0
+Project: {project name}
+Platform: {detected platform}
+Output Folder: {Q5}/
+Delta Mode: {Yes — compared against {Q10} | No}
+
+Input Documents:
+  BRD:          {Q1} — {N} requirements parsed ({SCOPED_OUT} scoped out, {CONFLICTED} conflicts)
+  User Stories: {Q2} — {M} stories, {K} acceptance criteria
+  Test Cases:   {Q3} — {P} test cases
+
+Repository Scan Coverage:
+  Total source files in project:    {N}
+  Files read during audit:          {N}
+  Coverage by category:
+    Screens:                        {read}/{total}
+    Components:                     {read}/{total}
+    Hooks:                          {read}/{total}
+    APILayer:                       {read}/{total}
+    StateManagement:                {read}/{total}
+    Navigation:                     {read}/{total}
+    BusinessLogic:                  {read}/{total}
+    Validation:                     {read}/{total}
+    Models:                         {read}/{total}
+    Core/Security:                  {read}/{total}
+    Constants:                      {read}/{total}
+    Utilities:                      {read}/{total}
+    Localization:                   {read}/{total}
+    Other:                          {read}/{total}
+  Files NOT read (if any):          {list unread files or "None — 100% coverage"}
+
+Self-Verification Results: {N} of 5 spot-checks CONFIRMED | {M} REVISED
+
+Files Generated (in generation order):
+  [02] 02_BRD_COMPLIANCE.md            — Status: COMPLETE | PARTIAL
+  [03] 03_USER_STORY_COMPLIANCE.md     — Status: COMPLETE | PARTIAL
+  [04] 04_TEST_CASE_COMPLIANCE.md      — Status: COMPLETE | PARTIAL
+  [05] 05_VALIDATION_ANALYSIS.md       — Status: COMPLETE | PARTIAL
+  [06] 06_UI_ANALYSIS.md               — Status: COMPLETE | PARTIAL
+  [07] 07_API_ANALYSIS.md              — Status: COMPLETE | PARTIAL
+  [08] 08_BUSINESS_LOGIC_ANALYSIS.md   — Status: COMPLETE | PARTIAL
+  [09] 09_NAVIGATION_ANALYSIS.md       — Status: COMPLETE | PARTIAL
+  [10] 10_TRACEABILITY_MATRIX.md       — Status: COMPLETE | PARTIAL
+  [11] 11_MISSING_FEATURES.md          — Status: COMPLETE | PARTIAL
+  [12] 12_EXTRA_IMPLEMENTATION.md      — Status: COMPLETE | PARTIAL
+  [13] 13_COMPLIANCE_SCORECARD.md      — Status: COMPLETE | PARTIAL
+  [01] 01_EXECUTIVE_SUMMARY.md         — Status: COMPLETE | PARTIAL
+  [14] 14_FINAL_RECOMMENDATIONS.md     — Status: COMPLETE | PARTIAL
+  [15] 15_SECURITY_ANALYSIS.md         — Status: COMPLETE | PARTIAL
+
+Overall Compliance Score: {X}%
+Risk Level: {CRITICAL | HIGH | MEDIUM | LOW | MINIMAL}
+Production Readiness: {NOT READY | NEEDS WORK | CONDITIONAL | READY}
+
+File Read Obligation: FULFILLED ({N}/{N} files) | PARTIAL ({N}/{N} files — list gaps)
+Placeholder Validation: PASS (0 remaining) | FAIL (list occurrences)
+```