feat: introduce Two-Export Comparator visual diff MVP

.gitattributes

@@ -0,0 +1,13 @@
+* text=auto eol=lf
+
+*.bat text eol=crlf
+*.cmd text eol=crlf
+*.ps1 text eol=crlf
+
+*.png binary
+*.jpg binary
+*.jpeg binary
+*.gif binary
+*.webp binary
+*.ico binary
+*.pdf binary

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,46 @@
+name: Bug report
+description: Report reproducible incorrect behavior
+title: "[Bug]: "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for reporting a bug. Please use synthetic data only — never attach confidential exports.
+  - type: textarea
+    id: summary
+    attributes:
+      label: What happened?
+      description: Describe the incorrect behavior.
+    validations:
+      required: true
+  - type: textarea
+    id: reproduce
+    attributes:
+      label: Steps to reproduce
+      placeholder: |
+        1. Open...
+        2. Load synthetic File A...
+        3. Load synthetic File B...
+        4. Observe...
+    validations:
+      required: true
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+    validations:
+      required: true
+  - type: input
+    id: browser
+    attributes:
+      label: Browser / version
+  - type: input
+    id: os
+    attributes:
+      label: Operating system
+  - type: textarea
+    id: fixture
+    attributes:
+      label: Minimal synthetic fixture
+      description: Paste the smallest non-sensitive example that reproduces the problem.

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,2 @@
+blank_issues_enabled: false
+contact_links: []

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,41 @@
+name: Feature request
+description: Suggest a focused improvement
+title: "[Feature]: "
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Core promise: two files in → visual differences out.
+        Please explain how the proposal improves that workflow.
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem
+      description: What comparison problem is difficult today?
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed improvement
+    validations:
+      required: true
+  - type: textarea
+    id: scope
+    attributes:
+      label: Why does this belong in the core?
+      description: How does it help users understand differences faster without making the normal workflow harder?
+    validations:
+      required: true
+  - type: checkboxes
+    id: principles
+    attributes:
+      label: Scope check
+      options:
+        - label: This directly helps compare two files.
+          required: true
+        - label: This can preserve local-first/privacy-first behavior.
+          required: true
+        - label: This does not require turning the project into a general spreadsheet/workspace product.
+          required: true

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,25 @@
+## Summary
+
+What changed and why?
+
+## Scope
+
+- [ ] This change directly supports comparing two files or the quality of that workflow.
+- [ ] The default UX remains understandable for non-expert users.
+- [ ] Local-first/privacy-first behavior is preserved.
+
+## Verification
+
+- [ ] `npm test`
+- [ ] `npm run build`
+- [ ] I tested the affected UI/behavior manually where relevant.
+- [ ] New or changed behavior has meaningful regression coverage where practical.
+
+## Data safety
+
+- [ ] No real confidential business/customer export is included in this PR.
+
+## Documentation
+
+- [ ] README/docs updated if user-visible behavior changed.
+- [ ] ROADMAP updated if this completes or changes a planned development round.

.github/workflows/ci.yml

@@ -0,0 +1,34 @@
+name: CI
+
+on:
+  push:
+    branches:
+      - main
+      - ui/frontend-prototype
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  test-and-build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Run tests
+        run: npm test
+
+      - name: Build
+        run: npm run build

CONTRIBUTING.md

@@ -0,0 +1,90 @@
+# Contributing to Two-Export Comparator
+
+Thanks for helping improve the project.
+
+The project intentionally stays focused:
+
+> **Take two files and visually show what is different.**
+
+Please read [PROJECT_SCOPE.md](docs/PROJECT_SCOPE.md) before proposing a large feature.
+
+## Development setup
+
+```bash
+npm install
+npm test
+npm run dev
+```
+
+Before opening a PR:
+
+```bash
+npm test
+npm run build
+```
+
+## Pull request expectations
+
+A good PR should:
+
+- solve one clear problem;
+- keep parser/comparison logic outside UI components;
+- preserve local-first behavior;
+- avoid unnecessary dependencies;
+- include or update tests for behavioral changes;
+- update documentation when behavior changes;
+- update `ROADMAP.md` when completing a planned development round.
+
+## Tests
+
+Tests should prove behavior, not merely execute code.
+
+For a bug fix, the preferred regression test should:
+
+1. fail on the broken behavior;
+2. pass with the fix;
+3. fail again if the protected behavior is removed.
+
+Realistic synthetic fixtures are preferred over tests that only mock everything away.
+
+## Privacy and test data
+
+Never commit real customer, accounting, banking, payment, or other confidential exports.
+
+Use synthetic fixture data only.
+
+## Translations
+
+Translations are a first-class contribution area.
+
+See [docs/TRANSLATIONS.md](docs/TRANSLATIONS.md).
+
+A translation PR should normally:
+
+1. copy an existing locale under `src/i18n/locales/`;
+2. keep the same message keys;
+3. translate message values naturally;
+4. register the locale in `src/i18n/locales/index.js`;
+5. test the full primary workflow;
+6. optionally add a `README.xx.md` translation.
+
+Do not translate imported file values or source column names. They belong to the user data.
+
+## Good contribution areas
+
+- CSV/TSV edge cases;
+- deterministic matching;
+- normalization;
+- duplicate/ambiguity handling;
+- security hardening;
+- accessibility;
+- performance;
+- translations;
+- documentation;
+- regression fixtures.
+
+## Large features
+
+Please discuss large scope changes before implementing them.
+
+A feature that is technically impressive but makes the default workflow harder to understand is unlikely to belong in the core.

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 QvarcY
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.