| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 0 | 15 | 0% |
| Commands | 0 | 0 | 2 | 0% |
| Section tags | 1 | 0 | 10 | 9% |
What each file covers
Sections
0 shared · 0 only in A · 15 only in B- + Repository Guidelines
- + Project Structure & Module Organization
- + Build, Test, and Development Commands
- + Coding Style & Naming Conventions
- + Testing Guidelines
- + Commit & Pull Request Guidelines
- + Security & Configuration Tips
- + API Development Guidelines
- + OpenAPI Documentation (MANDATORY)
- + Post-commit API consistency (LLM checklist)
- + Design System Hygiene (UI PRs)
- + Securities Providers
- + Debug Logging for Provider Syncs
- + Providers: Pending Transactions and FX Metadata (SimpleFIN/Plaid/Lunchflow)
- + Provider support notes
Commands
0 shared · 0 only in A · 2 only in B- + npm run lint
- + npm run format
Section tags
1 shared · 0 only in A · 10 only in B- + build
- + test
- + lint-format
- + architecture
- + git-pr
- + security
- + api
- + ui
- + do-not
- + docs
- code-style
Line diff
we-promise/sure · .cursor/rules/view_conventions.mdc
@@ −1 @@
1---
2description:
3globs: app/views/**,app/javascript/**,app/components/**/*.js
4alwaysApply: false
5---
6Use this rule to learn how to write ERB views, partials, and Stimulus controllers should be incorporated into them.
7
8- **Component vs. Partial Decision Making**
9 - **Use ViewComponents when:**
10 - Element has complex logic or styling patterns
11 - Element will be reused across multiple views/contexts
12 - Element needs structured styling with variants/sizes (like buttons, badges)
13 - Element requires interactive behavior or Stimulus controllers
14 - Element has configurable slots or complex APIs
15 - Element needs accessibility features or ARIA support
16
17 - **Use Partials when:**
18 - Element is primarily static HTML with minimal logic
19 - Element is used in only one or few specific contexts
20 - Element is simple template content (like CTAs, static sections)
21 - Element doesn't need variants, sizes, or complex configuration
22 - Element is more about content organization than reusable functionality
23
24- **Prefer components over partials**
25 - If there is a component available for the use case in app/components, use it
26 - If there is no component, look for a partial
27 - If there is no partial, decide between component or partial based on the criteria above
28
29- **Examples of Component vs. Partial Usage**
30 ```erb
31 <%# Component: Complex, reusable with variants and interactivity %>
32 <%= render DialogComponent.new(variant: :drawer) do |dialog| %>
33 <% dialog.with_header(title: "Account Settings") %>
34 <% dialog.with_body { "Dialog content here" } %>
35 <% end %>
36
37 <%# Component: Interactive with complex styling options %>
38 <%= render ButtonComponent.new(text: "Save Changes", variant: "primary", confirm: "Are you sure?") %>
39
40 <%# Component: Reusable with variants %>
41 <%= render FilledIconComponent.new(icon: "credit-card", variant: :surface) %>
42
43 <%# Partial: Static template content %>
44 <%= render "shared/logo" %>
45
46 <%# Partial: Simple, context-specific content with basic styling %>
47 <%= render "shared/trend_change", trend: @account.trend, comparison_label: "vs last month" %>
48
49 <%# Partial: Simple divider/utility %>
50 <%= render "shared/ruler", classes: "my-4" %>
51
52 <%# Partial: Simple form utility %>
53 <%= render "shared/form_errors", model: @account %>
54 ```
55
56- **Keep domain logic out of the views**
57 ```erb
58 <%# BAD!!! %>
59
60 <%# This belongs in the component file, not the template file! %>
61 <% button_classes = { class: "bg-blue-500 hover:bg-blue-600" } %>
62
63 <%= tag.button class: button_classes do %>
64 Save Account
65 <% end %>
66
67 <%# GOOD! %>
68
69 <%= tag.button class: computed_button_classes do %>
70 Save Account
71 <% end %>
72 ```
73
74- **Stimulus Integration in Views**
75 - Always use the **declarative approach** when integrating Stimulus controllers
76 - The ERB template should declare what happens, the Stimulus controller should respond
77 - Refer to [stimulus_conventions.mdc](mdc:.cursor/rules/stimulus_conventions.mdc) to learn how to incorporate them into
78
79 GOOD Stimulus controller integration into views:
80
81 ```erb
82 <!-- Declarative - HTML declares what happens -->
83
84 <div data-controller="toggle">
85 <button data-action="click->toggle#toggle" data-toggle-target="button">Show</button>
86 <div data-toggle-target="content" class="hidden">Hello World!</div>
87 </div>
88 ```
89
90- **Stimulus Controller Placement Guidelines**
91 - **Component controllers** (in `app/components/`) should only be used within their component templates
92 - **Global controllers** (in `app/javascript/controllers/`) can be used across any view
93 - Pass data from Rails to Stimulus using `data-*-value` attributes, not inline JavaScript
94 - Use Stimulus targets to reference DOM elements, not manual `getElementById` calls
95
96- **Naming Conventions**
97 - **Components**: Use `ComponentName` suffix (e.g., `ButtonComponent`, `DialogComponent`, `FilledIconComponent`)
98 - **Partials**: Use underscore prefix (e.g., `_trend_change.html.erb`, `_form_errors.html.erb`, `_sync_indicator.html.erb`)
99 - **Shared partials**: Place in `app/views/shared/` directory for reusable content
100 - **Context-specific partials**: Place in relevant controller view directory (e.g., `accounts/_account_sidebar_tabs.html.erb`)
101
102
we-promise/sure · AGENTS.md
@@ +1 @@
1# Repository Guidelines
2
3## Project Structure & Module Organization
4- Code: `app/` (Rails MVC, services, jobs, mailers, components), JS in `app/javascript/`, styles/assets in `app/assets/` (Tailwind, images, fonts).
5- Config: `config/`, environment examples in `.env.local.example` and `.env.test.example`.
6- Data: `db/` (migrations, seeds), fixtures in `test/fixtures/`.
7- Tests: `test/` mirroring `app/` (e.g., `test/models/*_test.rb`).
8- Tooling: `bin/` (project scripts), `docs/` (guides), `public/` (static), `lib/` (shared libs).
9
10## Build, Test, and Development Commands
11- Setup: `cp .env.local.example .env.local && bin/setup` — install deps, set DB, prepare app.
12- Run app: `bin/dev` — starts Rails server and asset/watchers via `Procfile.dev`.
13- Test suite: `bin/rails test` — run all Minitest tests; add `TEST=test/models/user_test.rb` to target a file.
14- Lint Ruby: `bin/rubocop` — style checks; add `-A` to auto-correct safe cops.
15- Lint/format JS/CSS: `npm run lint` and `npm run format` — uses Biome.
16- Security scan: `bin/brakeman` — static analysis for common Rails issues.
17
18## Coding Style & Naming Conventions
19- Ruby: 2-space indent, `snake_case` for methods/vars, `CamelCase` for classes/modules. Follow Rails conventions for folders and file names.
20- Views: ERB checked by `erb-lint` (see `.erb_lint.yml`). Avoid heavy logic in views; prefer helpers/components.
21- JavaScript: `lowerCamelCase` for vars/functions, `PascalCase` for classes/components. Let Biome format code.
22- Commit small, cohesive changes; keep diffs focused.
23
24## Testing Guidelines
25- Framework: Minitest (Rails). Name files `*_test.rb` and mirror `app/` structure.
26- Run: `bin/rails test` locally and ensure green before pushing.
27- Fixtures/VCR: Use `test/fixtures` and existing VCR cassettes for HTTP. Prefer unit tests plus focused integration tests.
28
29## Commit & Pull Request Guidelines
30- Commits: Imperative subject ≤ 72 chars (e.g., "Add account balance validation"). Include rationale in body and reference issues (`#123`).
31- PRs: Clear description, linked issues, screenshots for UI changes, and migration notes if applicable. Ensure CI passes, tests added/updated, and `rubocop`/Biome are clean.
32
33## Security & Configuration Tips
34- Never commit secrets. Start from `.env.local.example`; use `.env.local` for development only.
35- Run `bin/brakeman` before major PRs. Prefer environment variables over hard-coded values.
36
37## API Development Guidelines
38
39### OpenAPI Documentation (MANDATORY)
40When adding or modifying API endpoints in `app/controllers/api/v1/`, you **MUST** create or update corresponding OpenAPI request specs for **DOCUMENTATION ONLY**:
41
421. **Location**: `spec/requests/api/v1/{resource}_spec.rb`
432. **Framework**: RSpec with rswag for OpenAPI generation
443. **Schemas**: Define reusable schemas in `spec/swagger_helper.rb`
454. **Generated Docs**: `docs/api/openapi.yaml`
465. **Regenerate**: Run `RAILS_ENV=test bundle exec rake rswag:specs:swaggerize` after changes
47
48### Post-commit API consistency (LLM checklist)
49After every API endpoint commit, ensure: (1) **Minitest** behavioral coverage in `test/controllers/api/v1/{resource}_controller_test.rb` (no behavioral assertions in rswag); (2) **rswag** remains docs-only (no `expect`/`assert_*` in `spec/requests/api/v1/`); (3) **rswag auth** uses the same API key pattern everywhere (`X-Api-Key`, not OAuth/Bearer). Full checklist: [.cursor/rules/api-endpoint-consistency.mdc](.cursor/rules/api-endpoint-consistency.mdc).
50
51## Design System Hygiene (UI PRs)
52
53When a PR touches `.erb`, view components, or `.css`:
54
551. **Tokens, not palette.** Use functional tokens from `app/assets/tailwind/sure-design-system.css` (`bg-warning/10`, `text-destructive`, `bg-container`, `text-primary`, `border-primary`). No raw Tailwind palette (`bg-blue-50`, `text-red-500`, hex literals).
562. **Reach for `DS::*` first.** Check `app/components/DS/` (`DS::Alert`, `DS::Button`, `DS::Disclosure`, `DS::Dialog`, `DS::Menu`, etc.) before writing an alert, badge, button, disclosure, dialog, or input shape.
573. **Two copies → lift to DS.** Same hand-rolled shape ≥2× in a diff with no DS equivalent → propose a new `DS::*` primitive before the second copy lands.
584. **Conventions.** Use the `icon` helper (never `lucide_icon` directly), no raw SVG outside DS primitives, user-facing strings via `t()`, avoid arbitrary `*-[Npx]` values when a scale token fits.
59
60Reviewers escalate violations of (2)–(3) to close/rewrite; (1) and (4) are request-changes.
61
62## Securities Providers
63
64If you need to add a new securities price provider (Tiingo, EODHD, Binance-style crypto, etc.), see [adding-a-securities-provider.md](./docs/llm-guides/adding-a-securities-provider.md) for the full walkthrough — provider class, registry wiring, MIC handling, settings UI, locales, and tests.
65
66## Debug Logging for Provider Syncs
67
68When a provider sync/import path hits a recoverable error or suspicious partial response that support may need to inspect later, prefer `DebugLogEntry.capture(...)` over `Rails.logger.*`.
69
70- Record support-relevant diagnostics in the debug log so they surface in the super-admin-friendly `/settings/debug` UI.
71- Include `category`, `level`, `message`, `source`, `provider_key`, and useful structured `metadata`.
72- Attach `family` and `account_provider` when available so support can filter and trace the affected connection.
73- Reserve raw Rails logging for low-value local noise; anything operators may need should go to the debug log.
74
75## Providers: Pending Transactions and FX Metadata (SimpleFIN/Plaid/Lunchflow)
76
77- Pending detection
78 - SimpleFIN: pending when provider sends `pending: true`, or when `posted` is blank/0 and `transacted_at` is present.
79 - Plaid: pending when Plaid sends `pending: true` (stored at `transaction.extra["plaid"]["pending"]` for bank/credit transactions imported via `PlaidEntry::Processor`).
80 - Lunchflow: pending when API returns `isPending: true` in transaction response (stored at `transaction.extra["lunchflow"]["pending"]`).
81- Storage (extras)
82 - Provider metadata lives on `Transaction#extra`, namespaced (e.g., `extra["simplefin"]["pending"]`).
83 - SimpleFIN FX: `extra["simplefin"]["fx_from"]`, `extra["simplefin"]["fx_date"]`.
84- UI
85 - Shows a small “Pending” badge when `transaction.pending?` is true.
86- Variability
87 - Some providers don’t expose pendings; in that case nothing is shown.
88- Configuration (default-off)
89 - SimpleFIN runtime toggles live in `config/initializers/simplefin.rb` via `Rails.configuration.x.simplefin.*`.
90 - Lunchflow runtime toggles live in `config/initializers/lunchflow.rb` via `Rails.configuration.x.lunchflow.*`.
91 - ENV-backed keys:
92 - `SIMPLEFIN_INCLUDE_PENDING=1` (forces `pending=1` on SimpleFIN fetches when caller didn’t specify a `pending:` arg)
93 - `SIMPLEFIN_DEBUG_RAW=1` (logs raw payload returned by SimpleFIN)
94 - `LUNCHFLOW_INCLUDE_PENDING=1` (forces `include_pending=true` on Lunchflow API requests)
95 - `LUNCHFLOW_DEBUG_RAW=1` (logs raw payload returned by Lunchflow)
96
97### Provider support notes
98
99- SimpleFIN: supports pending + FX metadata; stored under `extra["simplefin"]`.
100- Plaid: supports pending when the upstream Plaid payload includes `pending: true`; stored under `extra["plaid"]`.
101- Plaid investments: investment transactions currently do not store pending metadata.
102- Lunchflow: supports pending via `include_pending` query parameter; stored under `extra["lunchflow"]`.
103- Manual/CSV imports: no pending concept.
104
@@ −1 +1 @@
1−---
2−description:
3−globs: app/views/**,app/javascript/**,app/components/**/*.js
4−alwaysApply: false
5−---
6−Use this rule to learn how to write ERB views, partials, and Stimulus controllers should be incorporated into them.
1+# Repository Guidelines
72
8−- **Component vs. Partial Decision Making**
9− - **Use ViewComponents when:**
10− - Element has complex logic or styling patterns
11− - Element will be reused across multiple views/contexts
12− - Element needs structured styling with variants/sizes (like buttons, badges)
13− - Element requires interactive behavior or Stimulus controllers
14− - Element has configurable slots or complex APIs
15− - Element needs accessibility features or ARIA support
16−
17− - **Use Partials when:**
18− - Element is primarily static HTML with minimal logic
19− - Element is used in only one or few specific contexts
20− - Element is simple template content (like CTAs, static sections)
21− - Element doesn't need variants, sizes, or complex configuration
22− - Element is more about content organization than reusable functionality
3+## Project Structure & Module Organization
4+- Code: `app/` (Rails MVC, services, jobs, mailers, components), JS in `app/javascript/`, styles/assets in `app/assets/` (Tailwind, images, fonts).
5+- Config: `config/`, environment examples in `.env.local.example` and `.env.test.example`.
6+- Data: `db/` (migrations, seeds), fixtures in `test/fixtures/`.
7+- Tests: `test/` mirroring `app/` (e.g., `test/models/*_test.rb`).
8+- Tooling: `bin/` (project scripts), `docs/` (guides), `public/` (static), `lib/` (shared libs).
239
24−- **Prefer components over partials**
25− - If there is a component available for the use case in app/components, use it
26− - If there is no component, look for a partial
27− - If there is no partial, decide between component or partial based on the criteria above
10+## Build, Test, and Development Commands
11+- Setup: `cp .env.local.example .env.local && bin/setup` — install deps, set DB, prepare app.
12+- Run app: `bin/dev` — starts Rails server and asset/watchers via `Procfile.dev`.
13+- Test suite: `bin/rails test` — run all Minitest tests; add `TEST=test/models/user_test.rb` to target a file.
14+- Lint Ruby: `bin/rubocop` — style checks; add `-A` to auto-correct safe cops.
15+- Lint/format JS/CSS: `npm run lint` and `npm run format` — uses Biome.
16+- Security scan: `bin/brakeman` — static analysis for common Rails issues.
2817
29−- **Examples of Component vs. Partial Usage**
30− ```erb
31− <%# Component: Complex, reusable with variants and interactivity %>
32− <%= render DialogComponent.new(variant: :drawer) do |dialog| %>
33− <% dialog.with_header(title: "Account Settings") %>
34− <% dialog.with_body { "Dialog content here" } %>
35− <% end %>
36−
37− <%# Component: Interactive with complex styling options %>
38− <%= render ButtonComponent.new(text: "Save Changes", variant: "primary", confirm: "Are you sure?") %>
39−
40− <%# Component: Reusable with variants %>
41− <%= render FilledIconComponent.new(icon: "credit-card", variant: :surface) %>
42−
43− <%# Partial: Static template content %>
44− <%= render "shared/logo" %>
45−
46− <%# Partial: Simple, context-specific content with basic styling %>
47− <%= render "shared/trend_change", trend: @account.trend, comparison_label: "vs last month" %>
48−
49− <%# Partial: Simple divider/utility %>
50− <%= render "shared/ruler", classes: "my-4" %>
51−
52− <%# Partial: Simple form utility %>
53− <%= render "shared/form_errors", model: @account %>
54− ```
18+## Coding Style & Naming Conventions
19+- Ruby: 2-space indent, `snake_case` for methods/vars, `CamelCase` for classes/modules. Follow Rails conventions for folders and file names.
20+- Views: ERB checked by `erb-lint` (see `.erb_lint.yml`). Avoid heavy logic in views; prefer helpers/components.
21+- JavaScript: `lowerCamelCase` for vars/functions, `PascalCase` for classes/components. Let Biome format code.
22+- Commit small, cohesive changes; keep diffs focused.
5523
56−- **Keep domain logic out of the views**
57− ```erb
58− <%# BAD!!! %>
24+## Testing Guidelines
25+- Framework: Minitest (Rails). Name files `*_test.rb` and mirror `app/` structure.
26+- Run: `bin/rails test` locally and ensure green before pushing.
27+- Fixtures/VCR: Use `test/fixtures` and existing VCR cassettes for HTTP. Prefer unit tests plus focused integration tests.
5928
60− <%# This belongs in the component file, not the template file! %>
61− <% button_classes = { class: "bg-blue-500 hover:bg-blue-600" } %>
29+## Commit & Pull Request Guidelines
30+- Commits: Imperative subject ≤ 72 chars (e.g., "Add account balance validation"). Include rationale in body and reference issues (`#123`).
31+- PRs: Clear description, linked issues, screenshots for UI changes, and migration notes if applicable. Ensure CI passes, tests added/updated, and `rubocop`/Biome are clean.
6232
63− <%= tag.button class: button_classes do %>
64− Save Account
65− <% end %>
33+## Security & Configuration Tips
34+- Never commit secrets. Start from `.env.local.example`; use `.env.local` for development only.
35+- Run `bin/brakeman` before major PRs. Prefer environment variables over hard-coded values.
6636
67− <%# GOOD! %>
37+## API Development Guidelines
6838
69− <%= tag.button class: computed_button_classes do %>
70− Save Account
71− <% end %>
72− ```
39+### OpenAPI Documentation (MANDATORY)
40+When adding or modifying API endpoints in `app/controllers/api/v1/`, you **MUST** create or update corresponding OpenAPI request specs for **DOCUMENTATION ONLY**:
7341
74−- **Stimulus Integration in Views**
75− - Always use the **declarative approach** when integrating Stimulus controllers
76− - The ERB template should declare what happens, the Stimulus controller should respond
77− - Refer to [stimulus_conventions.mdc](mdc:.cursor/rules/stimulus_conventions.mdc) to learn how to incorporate them into
42+1. **Location**: `spec/requests/api/v1/{resource}_spec.rb`
43+2. **Framework**: RSpec with rswag for OpenAPI generation
44+3. **Schemas**: Define reusable schemas in `spec/swagger_helper.rb`
45+4. **Generated Docs**: `docs/api/openapi.yaml`
46+5. **Regenerate**: Run `RAILS_ENV=test bundle exec rake rswag:specs:swaggerize` after changes
7847
79− GOOD Stimulus controller integration into views:
48+### Post-commit API consistency (LLM checklist)
49+After every API endpoint commit, ensure: (1) **Minitest** behavioral coverage in `test/controllers/api/v1/{resource}_controller_test.rb` (no behavioral assertions in rswag); (2) **rswag** remains docs-only (no `expect`/`assert_*` in `spec/requests/api/v1/`); (3) **rswag auth** uses the same API key pattern everywhere (`X-Api-Key`, not OAuth/Bearer). Full checklist: [.cursor/rules/api-endpoint-consistency.mdc](.cursor/rules/api-endpoint-consistency.mdc).
8050
81− ```erb
82− <!-- Declarative - HTML declares what happens -->
51+## Design System Hygiene (UI PRs)
8352
84− <div data-controller="toggle">
85− <button data-action="click->toggle#toggle" data-toggle-target="button">Show</button>
86− <div data-toggle-target="content" class="hidden">Hello World!</div>
87− </div>
88− ```
53+When a PR touches `.erb`, view components, or `.css`:
8954
90−- **Stimulus Controller Placement Guidelines**
91− - **Component controllers** (in `app/components/`) should only be used within their component templates
92− - **Global controllers** (in `app/javascript/controllers/`) can be used across any view
93− - Pass data from Rails to Stimulus using `data-*-value` attributes, not inline JavaScript
94− - Use Stimulus targets to reference DOM elements, not manual `getElementById` calls
55+1. **Tokens, not palette.** Use functional tokens from `app/assets/tailwind/sure-design-system.css` (`bg-warning/10`, `text-destructive`, `bg-container`, `text-primary`, `border-primary`). No raw Tailwind palette (`bg-blue-50`, `text-red-500`, hex literals).
56+2. **Reach for `DS::*` first.** Check `app/components/DS/` (`DS::Alert`, `DS::Button`, `DS::Disclosure`, `DS::Dialog`, `DS::Menu`, etc.) before writing an alert, badge, button, disclosure, dialog, or input shape.
57+3. **Two copies → lift to DS.** Same hand-rolled shape ≥2× in a diff with no DS equivalent → propose a new `DS::*` primitive before the second copy lands.
58+4. **Conventions.** Use the `icon` helper (never `lucide_icon` directly), no raw SVG outside DS primitives, user-facing strings via `t()`, avoid arbitrary `*-[Npx]` values when a scale token fits.
9559
96−- **Naming Conventions**
97− - **Components**: Use `ComponentName` suffix (e.g., `ButtonComponent`, `DialogComponent`, `FilledIconComponent`)
98− - **Partials**: Use underscore prefix (e.g., `_trend_change.html.erb`, `_form_errors.html.erb`, `_sync_indicator.html.erb`)
99− - **Shared partials**: Place in `app/views/shared/` directory for reusable content
100− - **Context-specific partials**: Place in relevant controller view directory (e.g., `accounts/_account_sidebar_tabs.html.erb`)
60+Reviewers escalate violations of (2)–(3) to close/rewrite; (1) and (4) are request-changes.
10161
62+## Securities Providers
63+
64+If you need to add a new securities price provider (Tiingo, EODHD, Binance-style crypto, etc.), see [adding-a-securities-provider.md](./docs/llm-guides/adding-a-securities-provider.md) for the full walkthrough — provider class, registry wiring, MIC handling, settings UI, locales, and tests.
65+
66+## Debug Logging for Provider Syncs
67+
68+When a provider sync/import path hits a recoverable error or suspicious partial response that support may need to inspect later, prefer `DebugLogEntry.capture(...)` over `Rails.logger.*`.
69+
70+- Record support-relevant diagnostics in the debug log so they surface in the super-admin-friendly `/settings/debug` UI.
71+- Include `category`, `level`, `message`, `source`, `provider_key`, and useful structured `metadata`.
72+- Attach `family` and `account_provider` when available so support can filter and trace the affected connection.
73+- Reserve raw Rails logging for low-value local noise; anything operators may need should go to the debug log.
74+
75+## Providers: Pending Transactions and FX Metadata (SimpleFIN/Plaid/Lunchflow)
76+
77+- Pending detection
78+ - SimpleFIN: pending when provider sends `pending: true`, or when `posted` is blank/0 and `transacted_at` is present.
79+ - Plaid: pending when Plaid sends `pending: true` (stored at `transaction.extra["plaid"]["pending"]` for bank/credit transactions imported via `PlaidEntry::Processor`).
80+ - Lunchflow: pending when API returns `isPending: true` in transaction response (stored at `transaction.extra["lunchflow"]["pending"]`).
81+- Storage (extras)
82+ - Provider metadata lives on `Transaction#extra`, namespaced (e.g., `extra["simplefin"]["pending"]`).
83+ - SimpleFIN FX: `extra["simplefin"]["fx_from"]`, `extra["simplefin"]["fx_date"]`.
84+- UI
85+ - Shows a small “Pending” badge when `transaction.pending?` is true.
86+- Variability
87+ - Some providers don’t expose pendings; in that case nothing is shown.
88+- Configuration (default-off)
89+ - SimpleFIN runtime toggles live in `config/initializers/simplefin.rb` via `Rails.configuration.x.simplefin.*`.
90+ - Lunchflow runtime toggles live in `config/initializers/lunchflow.rb` via `Rails.configuration.x.lunchflow.*`.
91+ - ENV-backed keys:
92+ - `SIMPLEFIN_INCLUDE_PENDING=1` (forces `pending=1` on SimpleFIN fetches when caller didn’t specify a `pending:` arg)
93+ - `SIMPLEFIN_DEBUG_RAW=1` (logs raw payload returned by SimpleFIN)
94+ - `LUNCHFLOW_INCLUDE_PENDING=1` (forces `include_pending=true` on Lunchflow API requests)
95+ - `LUNCHFLOW_DEBUG_RAW=1` (logs raw payload returned by Lunchflow)
96+
97+### Provider support notes
98+
99+- SimpleFIN: supports pending + FX metadata; stored under `extra["simplefin"]`.
100+- Plaid: supports pending when the upstream Plaid payload includes `pending: true`; stored under `extra["plaid"]`.
101+- Plaid investments: investment transactions currently do not store pending metadata.
102+- Lunchflow: supports pending via `include_pending` query parameter; stored under `extra["lunchflow"]`.
103+- Manual/CSV imports: no pending concept.
102104
