Initial import: eCW Charge Validation bot and results Portal

Snapshot of the working project as of 2026-10-23 (local 2d4d4fc), one
commit with no earlier history: the tracked files were de-identified
first (synthetic claim ids and patient data only; see Context.md
section 7). Credentials, run logs, screenshots, claim reports and client
workbooks are gitignored and not included.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/agents/domain.md

@@ -0,0 +1,42 @@
+# Domain Docs
+
+How the engineering skills read this repo's domain documentation before working on it. The repo
+is single-context: one glossary and one ADR folder, both at the repo root.
+
+## Before exploring, read these
+
+- **`GLOSSARY.md`** at the repo root: the project's terms (VERIFY / LIVE-WRITE, Charge Summary,
+  condition, ...).
+- **`docs/adr/`**: read the ADRs that touch the area you're about to work in.
+
+If either is missing, **proceed silently**: don't flag its absence and don't suggest creating it
+upfront. The `domain-modeling` skill creates them lazily, when a term or a decision actually gets
+settled.
+
+## File structure
+
+```
+/
+├── GLOSSARY.md
+├── docs/adr/
+│   ├── 0001-verify-sets-boxes-on-screen-only.md
+│   └── 0002-save-corrections-off-until-client-approves.md
+└── src/ecw_bot/
+```
+
+## Use the glossary's vocabulary
+
+When your output names a domain concept (in a Jira summary, a refactor proposal, a hypothesis, a
+test name), use the term as `GLOSSARY.md` defines it, e.g. **VERIFY** / **LIVE-WRITE** for the run
+modes, **Charge Summary** for the results sheet, **condition** for one rule module. Don't drift to
+synonyms the glossary explicitly avoids.
+
+If the concept you need isn't in the glossary yet, that's a signal: either you're inventing
+language the project doesn't use (reconsider) or there's a real gap (note it for the
+`domain-modeling` skill).
+
+## Flag ADR conflicts
+
+If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
+
+> _Contradicts ADR-0001 (VERIFY sets boxes on screen only), but worth reopening because…_

docs/agents/issue-tracker.md

@@ -0,0 +1,37 @@
+# Issue tracker: Jira (EEWA)
+
+Issues and specs for this repo live in Jira, project **EEWA** on ecareindia.atlassian.net,
+reached through the Atlassian MCP tools (cloudId `dbc481dd-f4cd-4204-9f15-02f26c6914a1`).
+
+## Conventions
+
+- Every ticket is a **Subtask** of **EEWA-5 "Charge Validation"** (EEWA-5 is itself a Task, not an
+  epic: a Task with parent EEWA-5 is refused as "Please select valid parent issue").
+- Assignee: **Manikandan** (accountId `712020:a3b618bb-f8b4-4105-9f6f-ba5f88b15804`), set at creation.
+- Statuses: To Do → In Progress → Done. Work that starts moves to In Progress; a ticket is closed
+  only when the operator says so.
+- **No claim ids, no patient data, no credentials** in titles, descriptions or comments.
+- Summary style: `<module or condition> (<doc row #>: <one line>)`,
+  e.g. `injection_admin_code (#20: add 96372 for injection codes)`.
+- A spec is one Subtask whose description holds the spec. Its implementation tickets are separate
+  Subtasks of EEWA-5 that mention the spec ticket's key.
+- Labels: when a skill asks for `ready-for-agent`, add the Jira label `ready-for-agent`.
+
+## When a skill says "publish to the issue tracker"
+
+Create it with `createJiraIssue` (project EEWA, issueTypeName `Subtask`, parent `EEWA-5`,
+assignee as above, label `ready-for-agent`), in dependency order (blockers first).
+
+## When a skill says "fetch the relevant ticket"
+
+`getJiraIssue` with the key (e.g. `EEWA-21`), including its comments.
+
+## Blocking edges
+
+Use Jira's native "Blocks" link: `createIssueLink` with type `Blocks`, `inwardIssue` = the
+blocker, `outwardIssue` = the ticket it blocks.
+
+## Comments and updates
+
+`addCommentToJiraIssue` for notes; `transitionJiraIssue` for status. Never close or edit the
+parent EEWA-5.