devendra-skill-package 1.0.2

package/.github/skills/test-case-validator/prompts/06-missing-scenario-detection.md

@@ -0,0 +1,32 @@
+# Prompt 06 — Missing Scenario Detection
+
+**Input**: `RTM`, `TEST_CASE_MODEL`, Rule 17 applicability determination.
+**Output**: Rule 7 table for Report Template Section 13.
+
+## Procedure
+
+1. Walk the full category list in `VALIDATION_RULES.md` Rule 7.
+2. Filter each through Rule 17 — a category inapplicable to this project
+   (e.g. "File Upload" for a module with no upload feature anywhere in
+   `US_MODEL`/`BRD_MODEL`) is `N/A`, not a missing scenario. Do not report
+   an N/A category in this section at all except in a short trailing note
+   summarizing which categories were excluded and why (avoid duplicating
+   the full Applicability table from Section 1 here).
+3. For each Applicable category, search `TEST_CASE_MODEL` for any test
+   whose title, steps, or test data indicates that category is exercised
+   (e.g. a test passing an empty string tests "Blank"; a test passing a
+   256-character string against a documented 255-char limit tests "Maximum
+   Length").
+4. For every Applicable category with zero matching evidence, record it
+   with the specific requirement(s) it would have applied to — a missing
+   scenario report entry with no linked requirement is not actionable;
+   always tie it back to *which* input/field/flow the missing scenario
+   would protect.
+5. Where a category is partially covered (e.g. Null is tested but Blank and
+   Whitespace-only are not, for the same field), report the specific gap,
+   not just "input validation partially covered" — precision here is what
+   makes Section 19's recommendations concrete.
+
+## Output
+
+Table: Category | Applicable? | Present? | Affected Requirement(s) | Note.

package/.github/skills/test-case-validator/prompts/07-duplicate-detection.md

@@ -0,0 +1,36 @@
+# Prompt 07 — Duplicate Test Case Detection
+
+**Input**: `TEST_CASE_MODEL`.
+**Output**: Rule 8 table for Report Template Section 14.
+
+## Procedure
+
+1. Group test cases by their mapped requirement (from `RTM`) — comparison is
+   only meaningful within the same requirement; two unrelated tests that
+   happen to share phrasing are not duplicates.
+2. Within each group, compare every pair on: Objective (what is this test
+   trying to prove?), Steps/body structure, Expected Result, Test Data.
+3. Classify each pair found similar enough to flag:
+   - **Exact Duplicate** — same requirement, same steps, same expected
+     result, same test data (or trivially equivalent data). Recommend
+     removing one, naming which (prefer keeping the one with better
+     traceability tagging or clearer naming).
+   - **Partial Duplicate** — same requirement and steps shape, different
+     data/expected result (e.g. two points along the same boundary).
+     This is normal test breadth — note it, don't recommend removal, unless
+     the *specific* data points are themselves redundant (e.g. testing
+     length 10 and length 11 against a boundary at 255 tells you nothing
+     length-254/255/256 wouldn't already tell you better).
+   - **Near Duplicate** — same objective, different layer (unit vs.
+     component vs. integration) or different requirement that happens to
+     exercise the same code path incidentally. **State explicitly that this
+     is intentional layered coverage, not redundancy**, unless both tests
+     are genuinely at the same layer testing the same thing for no reason.
+4. Only pairs classified Exact Duplicate count against the Quality Score's
+   Duplicates fraction (`QUALITY_SCORING.md`).
+
+## Output
+
+Table: Test Case ID A | Test Case ID B | Classification | Recommendation.
+If zero duplicates of any kind are found, state that plainly — it is a
+genuinely good sign worth naming, not just an empty section.

package/.github/skills/test-case-validator/prompts/08-risk-analysis.md

@@ -0,0 +1,39 @@
+# Prompt 08 — Risk-Based Coverage Analysis
+
+**Input**: `RTM`, `TEST_CASE_MODEL`, `US_MODEL`, `BRD_MODEL`,
+`RESOLVED_CONFIG.risk_thresholds`.
+**Output**: Rule 10 table for Report Template Section 16.
+
+## Procedure
+
+1. Assign a risk tier to every requirement/feature area, using evidence from
+   the source documents only:
+   - **High** — the source document itself flags security, compliance,
+     financial/monetary calculation, data-integrity, or irreversible-action
+     characteristics. Do not assign High based on your own judgment of
+     "this seems important" without a textual signal — cite the sentence
+     that justifies it.
+   - **Medium** — core user workflow, state management, cross-feature
+     integration, without an explicit high-risk signal.
+   - **Low** — cosmetic UI, static/read-only display, an isolated pure
+     function with no external dependency or side effect.
+   - If risk tier genuinely can't be determined from the documents, default
+     to Medium and say so explicitly — do not silently default without
+     stating it, since a silent Medium default changes the minimum test
+     count expected.
+
+2. Count the matched test cases (from `RTM`) for each risk-tiered item.
+
+3. Compare against `RESOLVED_CONFIG.risk_thresholds` for that tier.
+
+4. For any item below its threshold, record the specific gap: how many more
+   tests, of what type, would close it (reference Rule 4's test-type
+   breadth — a High-risk item with 5 positive tests and 0 negative tests
+   technically meets the "5 test cases" numeric bar but has not met the
+   intent of the threshold; call this out rather than treating the raw
+   count as sufficient on its own).
+
+## Output
+
+Table: Requirement/Feature | Risk Tier (+ justification) | Test Count | Test
+Type Breadth | Meets Minimum? | Gap.

package/.github/skills/test-case-validator/prompts/09-gated-wiring-validation.md

@@ -0,0 +1,53 @@
+# Prompt 09 — Gated-Behavior Wiring Validation
+
+**Input**: `US_MODEL`, `BRD_MODEL`, `TEST_CASE_MODEL`.
+**Output**: `VALIDATION_RULES.md` Rule 16 table, for Report Template Section
+17.
+
+This prompt exists because Rule 1's traceability check is satisfied the
+moment *any* test cites a requirement — it cannot by itself distinguish
+"the underlying logic is tested" from "the feature actually activates
+correctly when its trigger condition is met." See `docs/FAQ.md` for the
+real-world case this was built from.
+
+## Procedure
+
+1. **Identify every conditional requirement** — scan `US_MODEL`/`BRD_MODEL`
+   for language indicating the behavior is gated: "when [flag] is enabled,"
+   "only visible to [role]," "on [event/deep-link]," "after [N attempts/a
+   schedule]," "if the user is eligible." Each is a candidate for this rule.
+
+2. **For each candidate, search `TEST_CASE_MODEL` for two distinct kinds of
+   evidence**:
+   - **Logic-level evidence**: a test of the underlying decision in
+     isolation — a pure function returning true/false for the condition, a
+     reducer/slice transitioning correctly when the condition changes, or a
+     component test that receives the condition as a direct prop/parameter
+     rather than reading it from its real source.
+   - **Integration-level evidence**: a test that exercises the actual
+     consumption point — the screen/handler/controller that reads the
+     *real* gate (the actual flag accessor, the actual route/deep-link
+     parameter, the actual session/role check) — with the gate driven to
+     both its true and false state, confirming the behavior does/doesn't
+     activate.
+
+3. **Classify**:
+   - Both present → `Full`.
+   - Logic-level present, integration-level absent → **`Wiring Gap`**. This
+     is the case worth calling out distinctly: everything *looks* tested
+     (the requirement has a passing, green test), but the actual wiring
+     that makes the feature work in production is unverified.
+   - Neither present → `Untested` (this is also caught by ordinary Rule 1 as
+     a plain traceability gap — don't double-report it under both rules;
+     reference the Rule 1 finding instead of duplicating it here).
+
+4. Do not confuse a `Wiring Gap` with a low-risk finding by default — the
+   actual risk depends on the feature (a wiring gap on a cosmetic UI toggle
+   is Low; a wiring gap on an auth/eligibility gate is High). Assign
+   severity using the same evidence-based reasoning as Rule 10.
+
+## Output
+
+Table: Requirement ID | Gate Condition (verbatim) | Logic-Level Test | 
+Integration-Level Test (or "none") | Status | Severity (if Wiring Gap or
+Untested).

package/.github/skills/test-case-validator/prompts/10-observation-report.md

@@ -0,0 +1,56 @@
+# Prompt 10 — Observation Report Assembly
+
+**Input**: Every finding produced by Prompts 04-09.
+**Output**: `VALIDATION_RULES.md` Rule 14 entries, for Report Template
+Section 18, using `templates/observation-entry.md`.
+
+## Procedure
+
+1. **Collect** every non-`Full`/non-clean finding from: RTM gaps (Prompt 04),
+   coverage gaps (Prompt 05), missing scenarios (Prompt 06), true duplicates
+   (Prompt 07), risk-threshold shortfalls (Prompt 08), and wiring gaps
+   (Prompt 09).
+
+2. **Deduplicate.** If the same underlying root cause produced findings
+   under multiple rules (e.g. a requirement with zero tests shows up as a
+   Rule 1 gap, a Rule 4 breadth gap, and a Rule 10 risk-threshold shortfall
+   all at once), merge these into **one** observation that lists every
+   affected angle, rather than three near-identical entries. A reader
+   should never see the same root cause explained three times with three
+   different severities.
+
+3. **Assign severity** per finding, using this rubric (apply consistently —
+   do not let phrasing sound scarier or calmer than the underlying evidence
+   warrants):
+   - **High** — a High-risk requirement (Prompt 08) with zero or clearly
+     insufficient test evidence; a security/auth/financial-calculation gap;
+     a Wiring Gap on a High-risk gate; a Document Integrity contradiction
+     that could cause the wrong behavior to ship.
+   - **Medium** — a Medium-risk requirement gap; a Wiring Gap on a
+     Medium-risk gate; a partial scenario-type gap (e.g. negative path
+     untested) on an otherwise-covered requirement; a recurring pattern
+     across multiple requirements (even if each instance alone would be
+     Low, the pattern itself is Medium — see the recurring-wiring-gap
+     example in `docs/FAQ.md`).
+   - **Low** — cosmetic/naming/hygiene findings (Rule 11); a Low-risk
+     requirement gap; an isolated, non-recurring inferred-mapping-confidence
+     note.
+
+4. **Write each entry** using `templates/observation-entry.md`'s exact
+   fields — Severity, Evidence, Affected Requirement(s), Affected Test
+   Case(s), Impact, Recommendation, Suggested Test Case. Every field is
+   mandatory; "N/A" is an acceptable value for Affected Test Case(s) (when
+   the gap is a pure orphan requirement) but the field must still be present.
+
+5. **Order** the final list High → Medium → Low, and within each severity
+   band, order by how many requirements/user stories the observation
+   affects (most-affecting first).
+
+## Do Not
+
+- Do not write an observation with a vague evidence line like "insufficient
+  testing was found" — cite the exact requirement ID, document section, and
+  (if any) the test case IDs considered.
+- Do not skip writing a Suggested Test Case for a finding just because the
+  fix seems obvious — "obvious" to the auditor is not the same as "written
+  down for whoever picks up the ticket."

package/.github/skills/test-case-validator/prompts/11-final-report-assembly.md

@@ -0,0 +1,57 @@
+# Prompt 11 — Final Report Assembly
+
+**Input**: Everything produced by Prompts 00-10, `QUALITY_SCORING.md`'s
+computed score.
+**Output**: The complete report per `REPORT_TEMPLATE.md`.
+
+## Procedure
+
+1. Walk `REPORT_TEMPLATE.md` section by section, in order, filling each from
+   the corresponding upstream artifact (the template names which prompt/rule
+   feeds each section).
+
+2. **Never leave a section empty without an explanatory line.** "No
+   duplicate test cases were found in this suite." is a complete, correct
+   Section 14 when true. An empty heading with nothing under it is not —
+   the reader can't tell whether that means "checked, found nothing" or
+   "forgot to run this section."
+
+3. **Cross-check internal consistency before emitting**: the Final Summary's
+   numbers must match the sums/percentages shown in the body sections
+   exactly. If Section 2's RTM shows 37 Full + 12 Partial + 3 Missing out of
+   52, the Final Summary's "Covered Requirements" must be derivable from
+   those same numbers (see `QUALITY_SCORING.md` for the partial-credit
+   convention used) — never present a summary number that doesn't trace
+   back to a body table.
+
+4. **Compute and display the Quality Score breakdown** (Section 20) with
+   every category's weight, fraction, and rounded points visible — not just
+   the final total (see `QUALITY_SCORING.md` § Reporting the Score).
+
+5. **Emit the Final Summary** using `templates/final-summary-block.md`
+   exactly, including the computed `PASS`/`NEEDS IMPROVEMENT`/`FAIL` status
+   and the **"What Needs To Be Fixed"** list immediately after it. Populate
+   that list directly from the already-ordered Section 18 Observation
+   Report — do not re-derive or re-word findings for it; pull the short
+   title and severity of each High-severity observation (all of them, never
+   capped) and each Medium-severity observation (capped only for length,
+   per the template's own guidance, with an explicit "+N more" line if
+   capped), and close with a one-line count of any remaining Low-severity
+   items. If Section 18 is empty (no observations at all — only possible
+   when every RTM row is `Full`), state that explicitly rather than
+   omitting the field.
+
+6. **State the resolved configuration** used for this run near the top of
+   the Executive Summary (profile, BRD mode, any `CONFIG_OVERRIDE_INPUT`
+   applied) so the report is self-describing — a reader six months later
+   should be able to tell what rules were in effect without re-reading this
+   skill's source files.
+
+## Rendering Target Awareness
+
+If the calling context supports rendering a rich artifact (e.g. an HTML
+report with colored status pills, a stat-tile executive summary, a
+score-breakdown bar chart), it is appropriate to render one — but the
+underlying section order, content, and every numeric value must be
+identical to the plain-Markdown version this prompt produces. Visual
+treatment is additive presentation, never a substitute for completeness.

package/.github/skills/test-case-validator/templates/coverage-table.md

@@ -0,0 +1,25 @@
+# Template — Coverage Category Table
+
+Shared shape for Report Template Sections 6, 7, 9, 10, 11 (Frontend,
+Backend, API, Database, Security) — anywhere Rules 2/3 produce a per-
+category status list.
+
+```markdown
+| Category | Status | Evidence |
+|---|---|---|
+| <category name, verbatim from VALIDATION_RULES.md's list> | Full / Partial / Missing / N/A | <specific test case ID(s), or the one-line reason if N/A, or what's missing if Partial/Missing> |
+```
+
+## Field Notes
+
+- One table per Report Template section — do not merge Frontend and Backend
+  categories into a single table even though the shape is identical; the
+  reader scans these sections independently and expects them separated.
+- A `Partial` row's Evidence column must say *what part* is covered and
+  *what part* isn't — "Partial" with generic evidence ("some tests exist")
+  fails `SYSTEM_PROMPT.md`'s evidence-citation requirement.
+- If every row in a table is `N/A` (the whole category doesn't apply to this
+  profile), still render the table with the reasons — don't collapse the
+  whole section to one line; a reader auditing *why* nothing applies still
+  needs the per-category reasoning, particularly the "not yet classified"
+  case from Rule 17 step 4.

package/.github/skills/test-case-validator/templates/executive-summary.md

@@ -0,0 +1,38 @@
+# Template — Executive Summary
+
+Opens every report (Report Template Section 1).
+
+```markdown
+## 1. Executive Summary
+
+<One paragraph: what was validated (name the feature/module), against what
+(name the specific documents/files), and the headline finding — the single
+most important thing a reader should walk away knowing, stated in the first
+sentence, not buried at the end of the paragraph.>
+
+<Second paragraph, optional: the dominant *pattern* behind the findings, if
+one exists — e.g. "the domain/calculation layer is comprehensively tested;
+the gaps cluster in one recurring pattern: X" — this is more useful to a
+reader than a flat list of unrelated issues, when a real pattern exists. Do
+not manufacture a pattern that isn't there just to have one.>
+
+**Scope**
+
+| Category | Applicable to this project? | Reason if N/A |
+|---|---|---|
+| <every category referenced anywhere in the report> | Applicable / N/A | <one line> |
+
+**Configuration used**: Project Profile `<name>` (<explicit input | auto-
+detected from <signal>>) · BRD Mode: `<Separate BRD | Combined Spec Mode>` ·
+Scoring weights: <default, or "custom — see CONFIG_OVERRIDE_INPUT">.
+```
+
+## Field Notes
+
+- The Scope table doubles as the human-readable record of Rule 17's
+  resolution for this run — a reader should never have to cross-reference
+  `CONFIGURATION.md` to understand why, say, Database Coverage doesn't
+  appear as a failure later in the report.
+- Keep the narrative paragraphs short. The Executive Summary's job is to let
+  someone who reads only this section still walk away with the headline —
+  the detail lives in Sections 2-20.

package/.github/skills/test-case-validator/templates/final-summary-block.md

@@ -0,0 +1,87 @@
+# Template — Final Summary Block
+
+The mandatory closing block of every report. Every field must have a value —
+never leave one blank, and never omit a field even if its value is `0` or
+`N/A`.
+
+```markdown
+## Final Summary
+
+TEST CASE VALIDATION SUMMARY
+
+Project Profile: <resolved profile>
+BRD Mode: <"Separate BRD" | "Combined Spec Mode">
+
+Total Requirements: <n>
+Covered Requirements: <n> (<n> Full + <n> Partial)
+Missing Requirements: <n>
+
+Total User Stories: <n>
+Covered User Stories: <n>
+
+Total Acceptance Criteria: <n>
+Covered Acceptance Criteria: <n>
+
+Total Test Cases: <n>
+
+Requirement Coverage: <pct>%
+Acceptance Criteria Coverage: <pct>%
+Frontend Coverage: <pct>% (or "N/A — <reason>")
+Backend Coverage: <pct>% (or "N/A — <reason>")
+Functional Coverage: <pct>%
+Negative Coverage: <pct>%
+Boundary Coverage: <pct>%
+Business Rule Coverage: <pct>%
+API Coverage: <pct>% (or "N/A — <reason>")
+Database Coverage: <pct>% (or "N/A — <reason>")
+Security Coverage: <pct>% (or "N/A — <reason>")
+Automation Coverage: <pct>%
+
+Duplicate Test Cases: <n> exact, <n> partial, <n> near (layered — not counted as waste)
+
+Missing Scenarios: <n> categories (see Section 13)
+
+Gated-Behavior Wiring Gaps: <n> (see Section 17)
+
+Overall Quality Score: <score>/100
+
+Status: PASS | NEEDS IMPROVEMENT | FAIL
+
+What Needs To Be Fixed (prioritized, High → Medium → Low):
+1. <one-line action, phrased as what to do, not just what's wrong> — Severity: High (Observation #<n>, Section 18)
+2. ...
+<all High-severity observations, listed in full — never capped>
+<then all Medium-severity observations, listed in full unless there are more than ~8, in which case list the highest-affecting ones and add a trailing line: "+<n> more Medium-severity items — see Section 18/19">
+<Low-severity items are not repeated here individually — close with a trailing line: "+<n> Low-severity items — see Section 18/19", or omit the line entirely if there are zero>
+<If there are zero High and zero Medium observations (typically only when Status is PASS): "No blocking fixes — see Section 19 for optional hardening suggestions.">
+```
+
+## Field Notes
+
+- Every percentage must trace back to `TRACEABILITY_ENGINE.md` §3's
+  formulas, computed from the same `RTM` shown in Section 2 — never a
+  number that can't be reconstructed from the body of the report.
+- `Status` is computed purely from `Overall Quality Score` against
+  `RESOLVED_CONFIG.thresholds` (`QUALITY_SCORING.md` § Status Bands) — never
+  adjusted by "gut feel" after the fact, even if the auditor's prose
+  narrative feels more positive or negative than the number. If the prose
+  and the number seem to disagree, that's a sign the score inputs need
+  re-checking, not that the status should be hand-adjusted.
+- **"What Needs To Be Fixed" is an index into Section 18, not a new analysis
+  surface.** Every line must resolve to an actual Observation Report entry
+  (same Severity, same evidence) — never introduce a fix item here that
+  wasn't already raised as an Observation. This keeps the Final Summary
+  skimmable (a reader who only reads this block still walks away knowing
+  what to do next) while Section 18 remains the single source of truth for
+  the full evidence/impact/recommendation/suggested-test-case behind each
+  one.
+- Order strictly High → Medium → Low, and within each band, in the same
+  order Section 18 uses (most-affecting first per `prompts/10-observation-
+  report.md` step 5).
+- Do not silently drop items past a cap — if Medium-severity findings are
+  capped for length, say how many were left out and point to Section 18/19,
+  mirroring the no-silent-truncation convention already used for the RTM
+  (`REPORT_TEMPLATE.md` Rendering Notes) and Rule 8's large-suite sampling
+  note.
+- If `Status` is `PASS`, this field is still mandatory — state plainly that
+  there are no blocking fixes rather than omitting the field.

package/.github/skills/test-case-validator/templates/observation-entry.md

@@ -0,0 +1,41 @@
+# Template — Observation Entry
+
+One entry per finding in the Observation Report (Report Template Section 18,
+per `VALIDATION_RULES.md` Rule 14).
+
+```markdown
+### <Short, specific title naming the gap — not "Coverage Issue," but "NRI-specific summary layout (FR-012) has zero implementation">
+
+**Severity**: High | Medium | Low
+
+**Evidence**: <exact citation — document + section/ID, and/or test case IDs
+considered, quoting the relevant source text when it's a formula, business
+rule, or contradiction>
+
+**Affected Requirement(s)**: <Requirement/US/AC IDs>
+
+**Affected Test Case(s)**: <Test Case IDs, or "None — orphan requirement">
+
+**Impact**: <what happens if this ships as-is — be concrete: "an NRI user
+sees the standard summary layout, which the spec itself defines as
+incorrect for that user segment," not "could cause issues">
+
+**Recommendation**: <what to do, in priority-appropriate specificity —
+resolve a blocked dependency first if that's the actual blocker, don't just
+say "add tests" when the real gap is an unresolved open question upstream>
+
+**Suggested Test Case**: <objective + key input + expected result — enough
+to hand to whoever writes it next, not a full script>
+```
+
+## Field Notes
+
+- If a finding spans multiple requirements/observations that share one root
+  cause (see `prompts/10-observation-report.md` § Deduplicate), list every
+  affected ID under **Affected Requirement(s)** rather than writing separate
+  entries.
+- **Suggested Test Case** is required even when the recommendation is
+  process-level (e.g. "resolve the open contract-value question first") —
+  in that case, phrase it as the test that should exist *once the
+  dependency is resolved*, so the entry stays actionable rather than a dead
+  end.

package/.github/skills/test-case-validator/templates/rtm-row.md

@@ -0,0 +1,25 @@
+# Template — RTM Row
+
+One row per requirement/user-story/acceptance-criterion in the Requirement
+Traceability Matrix (Report Template Section 2).
+
+```markdown
+| Requirement ID | Requirement | User Story | Acceptance Criteria | Mapped Test Cases | Coverage | Status | Observation |
+|---|---|---|---|---|---|---|---|
+| <ID> | <one-line paraphrase, or verbatim if a formula/legal text> | <parent US ID, if any> | <AC IDs covered by this row, if row is at US level> | <Test Case ID(s), each tagged with its mapping tier: (T1)/(T2)/(T3)> | <Full / Partial / Missing / N/A> | <same as Coverage — kept as two columns because "Coverage" answers "how much" and "Status" answers "the verdict," which can diverge, e.g. Partial coverage with a High-severity gap still nets a Partial status but deserves a stronger Observation> | <One sentence: why Partial/Missing/N/A, or "Fully covered, no gaps" if Full> |
+```
+
+## Field Notes
+
+- **Mapped Test Cases**: always show the mapping tier inline —
+  `TC-004 (T1)`, `HoldingsViewScreen.test.tsx::...(T3, inferred_medium)`.
+  Never present a Tier 3 fuzzy match with the same visual weight as a
+  Tier 1 explicit match.
+- **Observation**: mandatory for every non-Full row. For a Full row, still
+  write one line ("Fully covered — positive, negative, and boundary all
+  present") rather than leaving it blank, so the table doesn't read as
+  incomplete.
+- Group rows in the rendered report by the source document's own
+  organizing structure (typically by User Story, in priority order) —
+  don't present the RTM as one flat alphabetical-by-ID list unless the
+  source document itself has no other structure.

package/.github/skills/validation-engine-builder/README.md

@@ -0,0 +1,50 @@
+# validation-engine-builder
+
+AI-driven centralized form validation skill for **React Native, React (web), Angular, and Flutter**.
+
+**The agent reads your screen/page/component/widget file, figures out what validation each field
+needs, detects which of the 4 platforms the project is, and wires everything up automatically** —
+`Controller`+`useValidatedForm` (RN/React), `FormBuilder`+`Validators` (Angular), or
+`TextFormField.validator` (Flutter).
+
+All error messages stay in one file. All regex patterns stay in one file. One JSON edit updates
+every screen/page/component/widget, on every platform, instantly — the same
+`templates/messages.json` / `templates/regex.json` / `templates/schemas.json` drive all 4 targets.
+
+### How it works
+
+1. Tell the agent to add validation to a screen/page/component/widget (or just open the file)
+2. The agent detects the platform (React Native, React web, Angular, or Flutter) from the project
+3. It reads the file, identifies every input field, and determines the correct validation per field
+4. It checks existing schemas in `templates/schemas.json` — reuses a match, creates a new one if needed
+5. Runs `apply-to-project.js` to regenerate the platform's validation output
+6. Rewrites the file with that platform's form-wiring pattern fully applied
+
+### Generated output per platform
+
+| Platform | Output location | Files |
+|---|---|---|
+| React Native | `src/validation/` | `messages.ts`, `regex.ts`, `schemas.ts` (Yup), `useValidatedForm.ts`, `ValidationError.tsx` |
+| React (web) | `src/validation/` | same 5 files — `ValidationError.tsx` renders a `<span>` instead of RN's `<Text>` |
+| Angular | `src/app/validation/` | `validation-messages.ts`, `validation-regex.ts`, `pattern-with-message.validator.ts`, `validators.ts` (Angular `Validators[]`), `validation-error.component.ts` |
+| Flutter | `lib/core/validation/` | `validation_messages.dart`, `validation_regex.dart`, `validators.dart` — no separate error-display file; `TextFormField` shows the validator's return value automatically |
+
+Edit `templates/*.json`, never the generated output — see `template.md`.
+
+### Supported dependencies
+
+React Native / React (web) install `react-hook-form` + `@hookform/resolvers` + `yup`, version-pinned
+by detected React Native version (see `references/platform-react-native.md`). Angular and Flutter
+need **no additional dependency** — Angular's Reactive Forms ships with `@angular/forms`, and
+Flutter's `TextFormField.validator` needs no package.
+
+| React Native | react-hook-form | @hookform/resolvers | yup |
+|---|---|---|---|
+| 0.80+ | ^7.54.0 | ^3.9.0 | ^1.4.0 |
+| 0.73–0.79 | ^7.51.0 | ^3.4.0 | ^1.3.0 |
+| < 0.73 | ^7.43.0 | ^3.1.0 | ^1.0.0 |
+
+### Reference files
+
+- `references/core.md` — platform-agnostic: field-type detection, regex/message/schema key tables, golden rules
+- `references/platform-react-native.md`, `platform-react.md`, `platform-angular.md`, `platform-flutter.md` — per-platform wiring patterns