devendra-skill-package 1.0.2

package/.github/skills/code-test-coverage-analyzer/assets/config-questionnaire.md

@@ -0,0 +1,118 @@
+# Configuration Questionnaire — Project Requirements Compliance Auditor
+
+Ask questions in order. Validate each answer before proceeding. Do not proceed to analysis until all
+required fields are confirmed.
+
+---
+
+## Questions to Ask (in order)
+
+### Q1 — BRD Path
+**Question**: "What is the path to your BRD (Business Requirement Document) Markdown file?"
+**Validation**: File must exist. Must be a .md file. Read the first 20 lines to confirm it contains requirements.
+**Error**: "File not found or not readable. Please provide a valid path to the BRD Markdown file."
+
+### Q2 — User Stories Path
+**Question**: "What is the path to your User Stories Markdown file?"
+**Validation**: File must exist. Must be a .md file. Read the first 20 lines to confirm it contains user stories.
+**Error**: "File not found or not readable. Please provide a valid path to the User Stories Markdown file."
+
+### Q3 — Test Cases Path
+**Question**: "What is the path to your Test Cases Markdown file?"
+**Validation**: File must exist. Must be a .md file. Read the first 20 lines to confirm it contains test cases.
+**Error**: "File not found or not readable. Please provide a valid path to the Test Cases Markdown file."
+
+### Q4 — Project Root
+**Question**: "What is the root directory of the project source code to audit?"
+**Validation**: Directory must exist. Must contain source code files.
+**Error**: "Directory not found. Please provide the absolute or relative path to the project root."
+
+### Q5 — Output Folder
+**Question**: "What name should be used for the output folder where the 15 report files will be created?"
+**Validation**: Non-empty string. Check if folder already exists; if yes, warn the user and ask to confirm overwrite.
+**Default**: `COMPLIANCE_AUDIT_REPORT`
+**Warning if exists**: "A folder named '{name}' already exists. Proceeding will overwrite existing reports. Continue? (yes/no)"
+
+### Q6 — Platform (Auto-detected)
+Run `pwsh scripts/detect-platform.ps1 -ProjectRoot "<Q4>"` (Mac/Linux) or
+`powershell scripts/detect-platform.ps1 -ProjectRoot "<Q4>"` (Windows).
+If confidence >= 1: auto-fill platform without asking. Show detected platform to user.
+If confidence = 0 or script unavailable: "Could not auto-detect platform. Is this project:
+  (1) React Native  (2) React  (3) Angular  (4) Flutter  (5) Android  (6) iOS
+  (7) NestJS  (8) Node.js/Express  (9) Spring Boot  (10) .NET Core  (11) Go  (12) Other"
+**Validation**: Must be one of the supported platforms.
+
+### Q7 — Optional Documents (Optional)
+**Question**: "Do you have any optional documents to include? (Architecture docs, API docs, Swagger, Database schema, Screen specs) — Enter paths comma-separated or press Enter to skip."
+**Validation**: If provided, verify each file exists.
+
+### Q8 — Deferred BRD Requirement IDs (Optional)
+**Question**: "Are any BRD requirement IDs intentionally excluded from this audit scope? (Enter comma-separated BRD-IDs such as BRD-015, BRD-022, or press Enter to skip.)"
+**Validation**: Optional. If provided, store as the SCOPED_OUT ID list. These requirements will be excluded from coverage calculation and marked SCOPED_OUT in all reports.
+**Note for AI**: If Q8 is skipped, no SCOPED_OUT items exist. Do not mark any requirement as SCOPED_OUT unless its ID appears in Q8.
+
+### Q9 — Project Type for Coverage Weight Preset (Optional)
+**Question**: "Project type for coverage weights — press Enter for default balanced weights or select: (1) Full Stack (2) Frontend Only (3) Backend Only (4) Mobile App (5) API Service"
+**Validation**: Optional. If skipped, use the default balanced weight preset from assets/coverage-calculation-rules.md.
+**Weight presets**:
+- Default / Full Stack: BRD 25%, Stories 20%, TC 20%, Validation 10%, API 10%, UI 5%, BL 5%, Nav 5%
+- Frontend Only: BRD 20%, Stories 20%, TC 15%, Validation 10%, API 5%, UI 20%, BL 5%, Nav 5%
+- Backend Only: BRD 25%, Stories 15%, TC 20%, Validation 10%, API 25%, UI 0%, BL 5%, Nav 0%
+- Mobile App: BRD 25%, Stories 20%, TC 15%, Validation 15%, API 10%, UI 10%, BL 3%, Nav 2%
+- API Service: BRD 25%, Stories 10%, TC 25%, Validation 15%, API 25%, UI 0%, BL 0%, Nav 0%
+
+### Q10 — Previous Audit Folder for Delta Mode (Optional)
+**Question**: "Enter the path to a previous audit output folder to run in delta mode (shows only changes since last audit), or press Enter for a full audit."
+**Validation**: Optional. If provided, verify the folder exists and contains at least 01_EXECUTIVE_SUMMARY.md. If valid, load it and at the end of each pass compare new findings against prior findings — flag new MISSING, resolved MISSING, new INCORRECT, new CONFLICTS as delta items.
+**Note for AI**: If Q10 is provided and valid, add a "### Delta from Previous Audit" section to Files 02, 11, and 13 showing what changed since the prior audit.
+
+---
+
+## Part A — Configuration Summary Record
+
+Present this summary and wait for user confirmation (user must type "OK", "yes", "confirm", or "proceed"):
+
+```
+COMPLIANCE AUDITOR — CONFIGURATION SUMMARY
+===========================================
+Q1  BRD File:          {Q1}
+Q2  User Stories:      {Q2}
+Q3  Test Cases:        {Q3}
+Q4  Project Root:      {Q4}
+Q5  Output Folder:     {Q5}/
+Q6  Platform:          {Q6}
+Q7  Optional Docs:     {Q7 list or "None"}
+Q8  Deferred BRD IDs:  {Q8 list or "None"}
+Q9  Project Type:      {Q9 or "Default (Balanced)"}
+Q10 Delta Mode:        {Q10 path or "Full audit (no prior baseline)"}
+
+Estimated scope:
+  Source files to scan:   {count from tree scan}
+  Platform patterns:      {reference file name}
+
+Type "OK" to begin the audit or "cancel" to abort.
+```
+
+---
+
+## Validation Rules
+
+| Field | Rule |
+|---|---|
+| Q1, Q2, Q3 | Must be readable .md files with content |
+| Q4 | Must be a readable directory |
+| Q5 | Non-empty string; alphanumeric, underscores, hyphens allowed |
+| Q6 | Must match exactly one supported platform |
+| Q7 | Each path must exist if provided; silently skip empty input |
+| Q8 | Optional; validate each ID matches the pattern BRD-\d+ if provided |
+| Q9 | Optional; must be 1–5 if provided; default to balanced weights if skipped |
+| Q10 | Optional; if provided the folder must exist and contain 01_EXECUTIVE_SUMMARY.md |
+
+---
+
+## Re-prompt Policy
+
+- Q1, Q2, Q3: Re-prompt up to 3 times if file not found. Abort if still not found after 3 attempts.
+- Q4: Re-prompt up to 3 times. Abort if not found.
+- Q5: Re-prompt if string is empty or contains invalid characters.
+- Q6: Re-prompt until valid platform selected.

package/.github/skills/code-test-coverage-analyzer/assets/conflict-resolution-protocol.md

@@ -0,0 +1,99 @@
+# Conflict Resolution Protocol — Project Requirements Compliance Auditor
+
+This file defines how contradictions between requirement documents are handled.
+Apply this protocol during Step 2D (Cross-Reference) and whenever a contradiction
+is encountered during any audit pass.
+
+---
+
+## What Counts as a Conflict
+
+A conflict exists when two or more source documents specify **contradictory values**
+for the same field, behavior, or constraint. Both must reference the same entity.
+
+**Examples of CONFLICTS:**
+- BRD-014: "PIN max length = 6 digits" | US-007-AC-03: "PIN length 4–8 digits"
+- BRD-029: "OTP expires in 5 minutes" | US-012-AC-01: "OTP expires in 3 minutes"
+- BRD-031: "Amount field allows up to ₹10,00,000" | TC-018: "Max amount = ₹5,00,000"
+
+**Examples of NON-CONFLICTS (complementary, not contradictory):**
+- BRD-014 states max PIN length; User Story adds "show PIN strength indicator" — this adds to the requirement, does not contradict it.
+- BRD says "user must log in" and TC describes the login flow steps — both are consistent.
+
+---
+
+## Types of Conflicts
+
+| Type | Description | Example |
+|---|---|---|
+| BRD vs User Story | BRD specifies a constraint; User Story AC specifies a different value | PIN length |
+| BRD vs Test Case | BRD states expected behavior; TC expects different output | OTP expiry |
+| Intra-BRD | Same BRD document states two different values in different sections | Amount max |
+| User Story vs Test Case | AC says one thing; TC expects another | Error message text |
+
+---
+
+## Detection
+
+During **Step 2D (Cross-Reference Building)**:
+
+1. Group all requirements by their **subject entity** (field name, screen name, API name).
+2. For each entity, list all constraints from all documents.
+3. Compare constraints of the same type (max length vs max length, expiry vs expiry).
+4. Flag any pair where the values contradict each other.
+
+Use grep to find related requirements: search all three input documents for the same keyword.
+
+---
+
+## How to Record a Conflict
+
+Assign a CONFLICT ID: `CONFLICT-{BRD-ID}-{US-ID or TC-ID}` (use the two source IDs).
+
+Record:
+```
+CONFLICT-BRD014-US007:
+  Entity: PIN length
+  Source 1: BRD-014 — "maximum PIN length is 6 digits"
+  Source 2: US-007-AC-03 — "PIN must be between 4 and 8 digits"
+  Contradiction: Max of 6 (BRD) vs Max of 8 (US)
+  Resolution: PENDING — requires stakeholder decision
+```
+
+---
+
+## Status Assignment for Conflicted Requirements
+
+- All requirements involved in a conflict are assigned status: **CONFLICTED**
+- CONFLICTED items score **0%** in coverage calculations
+- They are NOT counted as MISSING or IMPLEMENTED
+- They appear in a dedicated **"Requirement Conflicts"** table in File 02 (BRD Compliance Matrix)
+
+---
+
+## Reporting
+
+### In File 02 (BRD Compliance Matrix)
+Add a section after the main compliance table:
+
+```
+## Requirement Conflicts
+
+| CONFLICT-ID | Entity | Source 1 | Source 2 | Contradiction Summary |
+|---|---|---|---|---|
+| CONFLICT-BRD014-US007 | PIN max length | BRD-014: max 6 | US-007-AC-03: max 8 | Max length differs by 2 |
+```
+
+### In File 01 (Executive Summary)
+List conflicts in the "Risks and Blockers" section. Conflicts must be resolved before
+the requirement can be evaluated for compliance.
+
+---
+
+## Resolution
+
+Conflict resolution requires a human decision. The audit report surfaces the conflict;
+the project team decides which document is authoritative for that item.
+
+After resolution, the user should update the authoritative document and re-run the audit
+(or use delta-audit mode via Q10 to re-evaluate only CONFLICTED items).

package/.github/skills/code-test-coverage-analyzer/assets/coverage-calculation-rules.md

@@ -0,0 +1,294 @@
+# Coverage Calculation Rules — Project Requirements Compliance Auditor
+
+All coverage scores must be calculated from actual counts. Never estimate. Never round up.
+Show the calculation formula alongside the result in the scorecard.
+
+---
+
+## General Principle
+
+Coverage is based on VERIFIED IMPLEMENTATION, not file existence.
+
+Wrong: "The Login screen file exists, so Login is covered."
+Correct: "The Login screen implements all required fields, validations, and API calls confirmed
+by reading the source — Login coverage is 100%."
+
+Wrong: "The authentication module folder exists."
+Correct: "3 of 5 required authentication flows are implemented — coverage is 60%."
+
+---
+
+## BRD Coverage
+
+### IMPLEMENTED Count
+Count only requirements with status = `IMPLEMENTED`.
+
+### PARTIAL Count
+Count requirements with status = `PARTIALLY_IMPLEMENTED`.
+
+### Missing Count
+Count requirements with status = `MISSING`.
+
+### Formulas
+```
+BRD_Total = count of all BRD requirements (excluding SCOPED_OUT and CONFLICTED items)
+BRD_Implemented = count of IMPLEMENTED
+BRD_Partial = count of PARTIALLY_IMPLEMENTED
+BRD_Missing = count of MISSING
+BRD_Incorrect = count of INCORRECT
+BRD_NotVerified = count of NOT_VERIFIED
+
+ZERO-GUARD: If BRD_Total = 0, set BRD_Coverage = N/A and exclude this dimension from
+the Overall weighted score. Redistribute its 25% weight proportionally to remaining dimensions.
+
+BRD_Coverage_Strict %  = (BRD_Implemented / BRD_Total) × 100   [requires BRD_Total > 0]
+BRD_Coverage_Lenient % = ((BRD_Implemented + BRD_Partial × 0.5) / BRD_Total) × 100
+```
+
+Use **Strict** coverage as the primary metric. Show lenient coverage as secondary.
+
+Example output:
+```
+BRD Requirements: 45 total
+  IMPLEMENTED:          32  (71.1%)
+  PARTIALLY_IMPLEMENTED: 6  (13.3%)
+  MISSING:               5  (11.1%)
+  INCORRECT:             1   (2.2%)
+  NOT_VERIFIED:          1   (2.2%)
+
+BRD Coverage (Strict):  71.1%  [= 32/45 × 100]
+BRD Coverage (Lenient): 74.4%  [= (32 + 6×0.5)/45 × 100]
+```
+
+---
+
+## User Story Coverage
+
+### Story-Level Coverage
+A story is "Fully Satisfied" only if ALL of its acceptance criteria are SATISFIED.
+A story is "Partially Satisfied" if at least one AC is SATISFIED but not all.
+A story is "Not Satisfied" if zero ACs are SATISFIED.
+
+```
+Story_Total = count of all user stories
+Story_Full = count of Fully Satisfied stories
+Story_Partial = count of Partially Satisfied stories
+Story_None = count of Not Satisfied + Not Verifiable stories
+
+Story_Coverage % = (Story_Full / Story_Total) × 100
+```
+
+### Acceptance Criteria Coverage
+```
+AC_Total = total count of all acceptance criteria across all stories
+AC_Satisfied = count of SATISFIED ACs
+AC_Partial = count of PARTIALLY_SATISFIED ACs
+AC_Not = count of NOT_SATISFIED ACs
+
+AC_Coverage % = (AC_Satisfied / AC_Total) × 100
+```
+
+---
+
+## Test Case Coverage
+
+### Pass Rate (Primary Metric)
+```
+TC_Total = count of all test cases
+TC_Pass = count of PASS
+TC_Partial = count of PARTIAL_PASS
+TC_Fail = count of FAIL
+TC_NotImpl = count of NOT_IMPLEMENTED
+TC_Blocked = count of BLOCKED
+TC_Unknown = count of UNKNOWN
+
+TC_Pass_Rate % = (TC_Pass / TC_Total) × 100
+TC_Implementation_Rate % = ((TC_Total - TC_NotImpl) / TC_Total) × 100
+```
+
+Note: BLOCKED tests are excluded from denominator for pass rate IF the blocker is a MISSING feature
+already counted in BRD missing (to avoid double-penalizing the same gap).
+
+---
+
+## Validation Coverage
+
+```
+Val_Required = total validations required across all fields (from BRD + User Stories)
+Val_Implemented = validations where rule is implemented correctly
+Val_MsgMatch = validations where message is EXACT match
+Val_MsgPartial = validations where message is SIMILAR
+Val_MsgMismatch = validations where message is MISMATCH
+Val_Missing = validations not implemented at all
+
+Val_Coverage % = (Val_Implemented / Val_Required) × 100
+Msg_Accuracy % = (Val_MsgMatch / Val_Required) × 100
+```
+
+---
+
+## API Coverage
+
+```
+API_Required = count of distinct APIs required by BRD / User Stories
+API_Implemented = count of required APIs with implementation found
+API_Missing = count of required APIs not found
+API_Extra = count of APIs in code with no requirement reference
+
+API_Coverage % = (API_Implemented / API_Required) × 100
+```
+
+Note: API_Extra does not penalize the coverage score. It is reported separately.
+
+---
+
+## UI Coverage
+
+```
+UI_Screens_Required = count of distinct screens required by BRD / User Stories
+UI_Screens_Implemented = count implemented
+UI_Elements_Required = total required UI elements across all screens
+UI_Elements_Implemented = elements confirmed implemented
+UI_Labels_Required = text labels / buttons with prescribed text
+UI_Labels_Exact = labels matching requirements exactly
+
+UI_Screen_Coverage % = (UI_Screens_Implemented / UI_Screens_Required) × 100
+UI_Element_Coverage % = (UI_Elements_Implemented / UI_Elements_Required) × 100
+UI_Label_Accuracy % = (UI_Labels_Exact / UI_Labels_Required) × 100
+```
+
+---
+
+## Navigation Coverage
+
+```
+Nav_Required = count of distinct navigation flows required
+Nav_Implemented = count fully implemented
+Nav_Partial = count partially implemented (source or destination missing)
+Nav_Missing = count not found
+
+Nav_Coverage % = (Nav_Implemented / Nav_Required) × 100
+```
+
+---
+
+## Business Logic Coverage
+
+```
+BL_Required = count of distinct business rules required
+BL_Implemented = rules fully implemented
+BL_Partial = rules partially implemented
+BL_Missing = rules not found
+
+BL_Coverage % = (BL_Implemented / BL_Required) × 100
+```
+
+---
+
+## Overall Compliance Score
+
+Weighted composite of all dimension scores.
+
+### Weights
+| Dimension | Weight |
+|---|---|
+| BRD Coverage (Strict) | 25% |
+| User Story Coverage | 20% |
+| Test Case Pass Rate | 20% |
+| Validation Coverage | 10% |
+| API Coverage | 10% |
+| UI Screen Coverage | 5% |
+| Business Logic Coverage | 5% |
+| Navigation Coverage | 5% |
+
+**Total weight**: 100%
+
+### Formula
+```
+Overall % = (BRD_Coverage × 0.25)
+          + (Story_Coverage × 0.20)
+          + (TC_Pass_Rate × 0.20)
+          + (Val_Coverage × 0.10)
+          + (API_Coverage × 0.10)
+          + (UI_Screen_Coverage × 0.05)
+          + (BL_Coverage × 0.05)
+          + (Nav_Coverage × 0.05)
+```
+
+### Zero-Guard — Dimension Exclusion
+
+If any dimension's total count is zero (e.g., BRD has no navigation requirements), that
+dimension is N/A and excluded from the formula. Its weight is redistributed proportionally.
+
+Example — if Nav_Required = 0 (Nav excluded, 5% weight freed):
+```
+Redistributed weights = each remaining dimension × (100% / 95%) × original_weight
+Practical shortcut: increase each remaining weight by factor (100/95 = 1.0526)
+```
+
+Always document which dimensions were N/A and show the adjusted weights used.
+
+Zero-guard applies to ALL dimension formulas:
+- AC_Coverage: if AC_Total = 0, dimension = N/A
+- TC_Pass_Rate: if TC_Total = 0, dimension = N/A
+- Val_Coverage: if Val_Required = 0, dimension = N/A
+- API_Coverage: if API_Required = 0, dimension = N/A
+- UI_Screen_Coverage: if UI_Screens_Required = 0, dimension = N/A
+- BL_Coverage: if BL_Required = 0, dimension = N/A
+- Nav_Coverage: if Nav_Required = 0, dimension = N/A
+
+### Risk Score from Overall %
+| Range | Risk Score |
+|---|---|
+| 95–100% | MINIMAL |
+| 85–94% | LOW |
+| 70–84% | MEDIUM |
+| 50–69% | HIGH |
+| 0–49% | CRITICAL |
+
+### Production Readiness from Overall %
+| Range | Readiness |
+|---|---|
+| ≥ 90% | READY |
+| 75–89% | CONDITIONAL |
+| 60–74% | NEEDS WORK |
+| < 60% | NOT READY |
+
+---
+
+## Grade Scale
+
+Used in the Compliance Scorecard per dimension.
+
+| Grade | Score Range | Interpretation |
+|---|---|---|
+| A+ | 98–100% | Exceptional compliance |
+| A | 93–97% | Production ready |
+| A- | 90–92% | Near production ready |
+| B+ | 87–89% | Minor gaps |
+| B | 83–86% | Some gaps |
+| B- | 80–82% | Noticeable gaps |
+| C+ | 77–79% | Significant gaps |
+| C | 73–76% | Needs work |
+| C- | 70–72% | Substantial rework needed |
+| D | 60–69% | Major gaps |
+| F | 0–59% | Not shippable |
+
+---
+
+## Calculation Display Format
+
+Always show the formula with actual numbers when reporting scores in output files.
+
+Good:
+```
+BRD Coverage: 71.1% [= 32 IMPLEMENTED / 45 Total × 100]
+```
+
+Bad:
+```
+BRD Coverage: ~71%
+```
+
+Never round up. Always round to one decimal place using standard rounding (0.5 rounds up).
+Never show a score higher than what the data supports.

package/.github/skills/code-test-coverage-analyzer/assets/multi-strategy-search.md

@@ -0,0 +1,145 @@
+# Multi-Strategy Search Protocol — Project Requirements Compliance Auditor
+
+**Rule**: A requirement may NEVER be marked MISSING after a single search.
+All six strategies below must be exhausted (or confirmed inapplicable) before declaring MISSING.
+
+---
+
+## The Six Search Strategies
+
+### Strategy 1 — Semantic Name Search
+Search for the feature name and common synonyms in file names and code.
+
+```
+Grep patterns: {featureName}, {camelCase(featureName)}, {PascalCase(featureName)}
+Example: "authentication" → grep: authenticate, login, signIn, signin, auth
+```
+
+### Strategy 2 — API Endpoint URL Search
+Search for the exact endpoint URL string (or URL fragment) from the BRD.
+
+```
+Grep: the URL path (e.g., "/api/v1/loan/apply", "/auth/token", "/otp/verify")
+Also grep: the last path segment alone (e.g., "loan/apply", "otp/verify")
+```
+
+### Strategy 3 — Screen / Component Name Search
+Search for the screen or component name that would contain the feature.
+
+```
+Grep: {ScreenName}Screen, {FeatureName}Screen, {FeatureName}Page, {FeatureName}View
+Also glob: **/screens/**/*{keyword}*
+```
+
+### Strategy 4 — UI Label / String Search
+Search for visible text that would appear in the UI for this feature.
+
+```
+Grep: the button label text from BRD (e.g., "Submit Application", "Verify OTP")
+Grep: the field label text (e.g., "Loan Amount", "Mobile Number", "PAN Card")
+Grep: the error message text (e.g., "Invalid OTP", "Amount exceeds limit")
+```
+
+### Strategy 5 — Import Chain Trace
+Starting from the app entry point (App.tsx, main.dart, MainActivity, etc.), follow imports.
+
+```
+1. Read the root navigator / router file
+2. Find all screen imports
+3. For each screen, find its component imports
+4. Trace until you find — or confirm absence of — a component related to the requirement
+```
+
+### Strategy 6 — Semantic Synonyms
+Consult the synonym map below. Search using all synonyms for the domain concept.
+Apply ALL sections that match your project's domain (the maps are additive, not exclusive).
+
+**Fintech / Banking domain**:
+```
+authentication / login / signin / signIn / credentials / logIn / auth
+payment / transaction / transfer / remittance / charge / debit / credit
+loan / credit / borrow / lending / advance / finance / EMI
+registration / onboarding / signup / sign-up / createAccount / newUser
+profile / account / myAccount / userDetails / personalInfo
+notification / alert / push / reminder / message / inbox
+KYC / verification / identity / document / aadhaar / PAN
+OTP / one-time-password / passcode / 2FA / twoFactor / verification-code
+```
+
+**E-commerce / Retail domain**:
+```
+cart / basket / bag / shopping-cart / cartItems
+checkout / payment / purchase / order-summary
+order / purchase / transaction / booking
+product / item / listing / sku / variant
+inventory / stock / availability / inStock
+wishlist / favorites / saved / bookmarked
+search / filter / sort / browse / discover
+```
+
+**Healthcare domain**:
+```
+patient / user / member / beneficiary
+appointment / booking / schedule / slot
+record / history / chart / medical-record
+prescription / medication / drug / dosage
+diagnosis / condition / ailment / symptom
+doctor / physician / provider / practitioner / specialist
+```
+
+**General / Cross-domain**:
+```
+user / account / member / customer / subscriber
+settings / preferences / profile / configuration
+dashboard / home / overview / summary
+report / analytics / statistics / metrics / insights
+notification / alert / badge / message
+search / find / discover / explore / browse
+```
+
+---
+
+## Search Evidence Recording
+
+For each strategy attempted, record the outcome in the finding:
+
+```
+Evidence: Searched using:
+  S1 [Semantic]:    grep "authenticate", "login", "signIn" — no match in src/
+  S2 [API URL]:     grep "/auth/login", "/api/auth" — no match
+  S3 [Screen name]: glob **/LoginScreen*, **/AuthScreen* — no match
+  S4 [UI label]:    grep "Login", "Sign In", "Submit" — found in WelcomeScreen.tsx (unrelated)
+  S5 [Import chain]:traced App.tsx → RootNavigator → no auth-related screen imports
+  S6 [Synonyms]:    grep "credentials", "signIn", "auth" — no dedicated screen found
+  → Status: MISSING (all 6 strategies exhausted)
+```
+
+---
+
+## Minimum Strategies by Requirement Type
+
+| Requirement Type | Minimum Strategies Required |
+|---|---|
+| Screen / page | S1, S3, S5 |
+| API endpoint | S1, S2, S3 |
+| Validation rule | S1, S4 (message text), S3 (screen containing the field) |
+| Business logic / calculation | S1, S3, S5 |
+| Navigation flow | S3, S5 (import chain from navigator) |
+| UI element / label | S1, S4, S3 |
+
+**Always include S6 (synonyms)** for any requirement where the first strategy fails.
+
+---
+
+## When MISSING is Confirmed
+
+Only after all applicable strategies return no results may the status be MISSING.
+
+Final evidence string format:
+```
+Searched [S1–S6 as applicable]: {list of grep patterns, glob patterns, files traced}.
+No implementation found across {N} strategies.
+Status: MISSING (Confidence: HIGH — exhaustive search completed)
+```
+
+Note: A MISSING status after exhaustive search has HIGH confidence (we are confident it is missing).