Skip to content

feat: add InstrumentDocumentType with bank_statement - #227

Open
armando-rodriguez-cko wants to merge 1 commit into
mainfrom
feat/INT-1691-instrument-document-type-bank-statement
Open

feat: add InstrumentDocumentType with bank_statement#227
armando-rodriguez-cko wants to merge 1 commit into
mainfrom
feat/INT-1691-instrument-document-type-bank-statement

Conversation

@armando-rodriguez-cko

@armando-rodriguez-cko armando-rodriguez-cko commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

What

Adds InstrumentDocumentType with the single value bank_statement, the document type for the bank account behind a platforms payment instrument.

Reported internally: the value is documented in the API reference but missing from the SDK, and it is blocking a merchant. Verified against the spec, where that document type is a single-value enum whose only accepted value (and default) is bank_statement.

Why a separate type instead of adding the value to the existing document type

The existing document type lists identity documents (passport, national identity card, driving license) and is used for entity onboarding. The API models the bank account document type as its own enum. Adding bank_statement alongside the identity values would offer it in every place the API rejects it, and would equally suggest the identity values are accepted on an instrument document, where they are not.

Tests

One of the tests asserts bank_statement is not in the identity document type. That is deliberate: it is what stops the two being merged the next time someone reports the value as missing from the identity enum.

Not breaking

Purely additive. No existing constant, field or signature changes.

Refs INT-1691.

@agent-wall-e

agent-wall-e Bot commented Aug 17, 2026

Copy link
Copy Markdown
🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code Kind Clause Meaning
no_low_class_matched informational §2.2 (fall-through) None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified informational §2.1 M7 (informational) At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.
2.2.6_logical_extensionPurely additive new enum class reusing existing abstractions (str, Enum pattern) in the same enums module, with no new endpoints, persisted data, auth changes, or external integrations. classifying §2.2.6 Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

Kinds:

  • classifying — this rule contributed to the chosen tier.
  • informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

wall-e 2026.06.19-02 · debug

Reported internally: a merchant creating a bank_account payment instrument found no
constant for the document type. Verified in the spec, where
PlatformsPaymentInstrumentBankAccount.document.type is a single-value enum accepting
only bank_statement, which is also its default.

Kept separate from DocumentType rather than added to it. DocumentType lists identity
documents, and the API models the bank account document type as its own enum, so
putting bank_statement there would offer it where the API rejects it and imply a
passport is valid on a bank account document. DocumentType now says so in its
docstring.

One test asserts bank_statement is NOT in DocumentType. That is the one that matters
long term: it is what stops the two being merged the next time someone reports the
value as missing from the identity enum.

Refs INT-1691.
@armando-rodriguez-cko
armando-rodriguez-cko force-pushed the feat/INT-1691-instrument-document-type-bank-statement branch from 719f00a to 940db95 Compare August 17, 2026 15:55
@agent-wall-e

agent-wall-e Bot commented Aug 17, 2026

Copy link
Copy Markdown

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

  • no_low_class_matched
  • prod_source_modified
  • 2.2.6_logical_extension:Purely additive new enum constant in an existing enums file, no new endpoints, persisted data, auth changes, or external integrations introduced.

Operational gates

  • ✅ jira_ticket (INT-1691)
  • ✅ independent_review

Files analysed: 2


wall-e 2026.06.19-02 · policy 376219bc71e6…

@agent-wall-e

agent-wall-e Bot commented Aug 17, 2026

Copy link
Copy Markdown
🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code Kind Clause Meaning
no_low_class_matched informational §2.2 (fall-through) None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified informational §2.1 M7 (informational) At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.
2.2.6_logical_extensionPurely additive new enum constant in an existing enums file, no new endpoints, persisted data, auth changes, or external integrations introduced. classifying §2.2.6 Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

Kinds:

  • classifying — this rule contributed to the chosen tier.
  • informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

wall-e 2026.06.19-02 · debug

@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant