Feat/remove generated files from git ignore

[dev-jodee]

Important

Uncommented generated client files in .gitignore and added autogenerated Rust and TypeScript client files for a commerce program.

• Git Ignore:
  • Uncommented /clients/rust/src/generated/* and /clients/typescript/src/generated/* in .gitignore to include generated client files.
• Rust Client:
  • Added autogenerated files for accounts, errors, instructions, and types in rust/src/generated/.
  • Includes merchant.rs, operator.rs, payment.rs, and others.
• TypeScript Client:
  • Added autogenerated files for accounts, errors, instructions, and types in typescript/src/generated/.
  • Includes operator.ts, payment.ts, commerceProgram.ts, and others.

^{This description was created by for 8a272ff. You can customize this summary. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
commerce-sdk-docs	Ready	Preview	Comment	Oct 21, 2025 8:26pm

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 8a272ff in 2 minutes and 37 seconds. Click for details.

• Reviewed 16080 lines of code in 80 files
• Skipped 0 files when reviewing.
• Skipped posting 26 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. program/clients/rust/src/generated/accounts/merchant.rs:1

• Draft comment:
  Auto‐generated merchant account code follows standard Borsh and Anchor patterns. No issues noted.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the code follows standard patterns and no issues are noted. It does not provide any actionable feedback or suggestions for improvement.

2. program/clients/rust/src/generated/accounts/merchant_operator_config.rs:1

• Draft comment:
  MerchantOperatorConfig code is consistent and correctly implements fetch and Anchor traits. Looks good.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It simply states that the code is consistent and correctly implements certain traits, which does not align with the rules provided.

3. program/clients/rust/src/generated/accounts/operator.rs:1

• Draft comment:
  Operator account implementation is straightforward and follows conventions. No concerns.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide any actionable feedback or suggestions. It simply states that the implementation is straightforward and follows conventions, which does not align with the rules for useful comments.

4. program/clients/rust/src/generated/accounts/payment.rs:1

• Draft comment:
  Payment account code is auto-generated and adheres to expected patterns for serialization, fetching, and Anchor support.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the payment account code is auto-generated and adheres to expected patterns. It does not provide any actionable feedback or suggestions for improvement.

5. program/clients/rust/src/generated/errors/commerce_program.rs:8

• Draft comment:
  CommerceProgramError enum is clear and includes conversion to ProgramError. No issues.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It simply states that there are no issues with the CommerceProgramError enum, which is not useful for the PR author.

6. program/clients/rust/src/generated/instructions/update_operator_authority.rs:8

• Draft comment:
  UpdateOperatorAuthority instruction and builder are correctly implemented. Use of unwrap in serialization is acceptable in auto‐generated code.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the implementation is correct and the use of unwrap is acceptable. It does not provide any actionable feedback or suggestions for improvement.

7. program/clients/rust/src/generated/types/chargeback_policy.rs:8

• Draft comment:
  ChargebackPolicy struct is simple and correctly defined using Borsh serialization.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the ChargebackPolicy struct is simple and correctly defined using Borsh serialization. It does not provide any actionable feedback or suggestions for improvement.

8. program/clients/rust/src/generated/types/fee_type.rs:8

• Draft comment:
  FeeType enum properly derives necessary traits and looks correct.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the FeeType enum properly derives necessary traits and looks correct. It does not provide any actionable feedback or suggestions for improvement.

9. program/clients/rust/src/generated/types/payment_chargebacked_event.rs:8

• Draft comment:
  PaymentChargebackedEvent struct is correctly defined with appropriate field attributes.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, as it simply states that the struct is correctly defined without suggesting any changes or asking for confirmation on any specific aspect. It does not provide any actionable feedback or raise any concerns.

10. program/clients/rust/src/generated/types/payment_refunded_event.rs:8

• Draft comment:
  PaymentRefundedEvent struct similarly looks correct with proper field definitions.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the struct looks correct. It doesn't provide any actionable feedback or suggestions for improvement.

11. program/clients/rust/src/generated/types/policy_type.rs:8

• Draft comment:
  PolicyType enum is well defined with expected variants.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, as it simply states that the PolicyType enum is well defined. It does not provide any actionable feedback or suggestions for improvement.

12. program/clients/rust/src/generated/types/refund_policy.rs:8

• Draft comment:
  RefundPolicy struct is straightforward and correctly implemented.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the RefundPolicy struct is straightforward and correctly implemented. It does not provide any actionable feedback or suggestions for improvement, nor does it ask for confirmation or testing. According to the rules, purely informative comments should be removed.

13. program/clients/rust/src/generated/types/settlement_policy.rs:8

• Draft comment:
  SettlementPolicy is properly defined with expected fields.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that SettlementPolicy is properly defined with expected fields. It does not provide any actionable feedback or suggestions for improvement, nor does it ask for confirmation of intent or highlight any potential issues. According to the rules, purely informative comments should be removed.

14. program/clients/typescript/src/generated/accounts/merchantOperatorConfig.ts:9

• Draft comment:
  TypeScript MerchantOperatorConfig code correctly defines codecs and types. Code is consistent with auto-generation.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the TypeScript code correctly defines codecs and types and is consistent with auto-generation. It does not provide any actionable feedback or suggestions for improvement.

15. program/clients/typescript/src/generated/accounts/payment.ts:9

• Draft comment:
  TypeScript Payment account definitions and codec implementations are correctly generated.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that something is correctly generated. It does not provide any actionable feedback or suggestions for improvement.

16. program/clients/typescript/src/generated/instructions/createOperator.ts:9

• Draft comment:
  The createOperator instruction is auto‐generated and correctly uses a transformEncoder to set the discriminator. Logic for resolving default accounts is clear.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the createOperator instruction is auto-generated and correctly uses a transformEncoder. It does not provide any actionable feedback or suggestions for improvement.

17. program/clients/typescript/src/generated/instructions/updateMerchantSettlementWallet.ts:9

• Draft comment:
  UpdateMerchantSettlementWallet instruction is well structured, including default PDA resolution using getProgramDerivedAddress.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, praising the structure of the code without suggesting any changes or asking for confirmation on any specific aspect. It doesn't provide any actionable feedback or raise any concerns.

18. program/clients/typescript/src/generated/pdas/eventAuthority.ts:9

• Draft comment:
  findEventAuthorityPda function correctly computes a PDA using the 'event_authority' seed.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that a function correctly computes something. It doesn't provide any actionable feedback or suggestions for improvement.

19. program/clients/typescript/src/generated/pdas/merchantOperatorConfig.ts:9

• Draft comment:
  The PDA function for MerchantOperatorConfig is correctly constructed using expected seeds.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, as it simply states that the function is correctly constructed without suggesting any changes or asking for confirmation. It does not provide any actionable feedback or raise any concerns.

20. program/clients/typescript/src/generated/programs/commerceProgram.ts:9

• Draft comment:
  CommerceProgram.ts properly exports program address, enums for accounts/instructions, and an instruction identifier function. Everything is as expected.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that everything is as expected without suggesting any changes or asking for confirmation on specific code behavior. It does not provide any actionable feedback or raise any concerns.

21. program/clients/typescript/src/generated/shared/index.ts:9

• Draft comment:
  Shared helper functions for account resolution and validation are clear and appropriately implemented.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, as it praises the implementation without providing any actionable feedback or suggestions. It does not align with the rules for good comments, which should offer specific suggestions or ask for confirmation on potentially unintended changes.

22. program/clients/typescript/src/generated/types/paymentClearedEvent.ts:9

• Draft comment:
  PaymentClearedEvent type and codec functions are defined clearly and use appropriate fixed-size codecs.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, praising the clarity and appropriateness of the PaymentClearedEvent type and codec functions. It doesn't provide any actionable feedback or suggestions for improvement.

23. program/clients/typescript/src/generated/types/refundPolicy.ts:9

• Draft comment:
  RefundPolicy types and codecs are implemented as expected.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, stating that the RefundPolicy types and codecs are implemented as expected. It does not provide any actionable feedback or suggestions for improvement.

24. program/clients/rust/src/generated/instructions/chargeback_payment.rs:290

• Draft comment:
  There's a potential typographical issue in the default value for commerce_program ("commkU28d52cwo2Ma3Marxz4Qr9REtfJtuUfqnDnbhT"). Please double-check if the prefix "commk" is intentional.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is an autogenerated file that shouldn't be edited directly. The commerce program ID is likely intentionally prefixed with "commk" as program IDs often have meaningful prefixes. The comment is speculative and asks for confirmation rather than pointing out a clear issue. It's questioning a dependency/program ID which is explicitly out of scope per the rules. Could the prefix actually indicate a real issue that needs fixing? Maybe there's a typo in the program ID that could cause runtime issues? No - program IDs in Solana commonly have meaningful prefixes, and this is an autogenerated file where the ID is likely validated elsewhere. More importantly, the rules explicitly state not to comment on dependencies or program IDs we don't recognize. Delete the comment. It violates multiple rules - it's speculative, asks for confirmation rather than pointing out a clear issue, and comments on program IDs which are explicitly out of scope.

25. program/clients/rust/src/generated/programs.rs:11

• Draft comment:
  Typo possibly detected in the program ID string on this line: "commkU28d52cwo2Ma3Marxz4Qr9REtfJtuUfqnDnbhT". Please confirm if "commk" was intended, or if it should be corrected to align with commerce_program (for example, "commerce...").
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% 1. This is an autogenerated file, which means the program ID likely comes from a trusted source. 2. Solana program IDs are base58-encoded public keys and don't need to match variable names semantically. 3. The comment is speculative and asks for confirmation rather than pointing out a definite issue. 4. The comment shows a misunderstanding of how Solana program IDs work. I might be wrong about the source of the program ID - perhaps it could actually be a typo in the generation source. Even if there was a typo in the source, this autogenerated file is not the place to fix it - the comment explicitly says to not edit this file and use visitors instead. The comment should be deleted as it asks for confirmation, shows misunderstanding of Solana program IDs, and suggests editing an autogenerated file.

26. program/clients/typescript/src/generated/shared/index.ts:45

• Draft comment:
  Typo in error message: Consider changing 'Expected a Address.' to 'Expected an Address.' for correct grammar.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The file header explicitly states "DO NOT EDIT THIS FILE" and indicates that changes should be made through visitors instead. Making direct edits to this file would be counter to the intended workflow, as they would be overwritten on the next code generation. The grammatical issue should be fixed in the code generator instead. The grammar correction itself is technically correct. And error messages are important for developer experience. However, editing auto-generated files directly is explicitly forbidden and would be futile as changes would be lost on the next generation. The fix needs to happen in the code generator. Delete the comment because it suggests making changes to an auto-generated file, which is explicitly not allowed and would be overwritten.

Workflow ID: wflow_VSgM4sevh04Koiei

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[github-actions]

📊 Coverage Report

📁 View Coverage Artifacts

Coverage reports have been generated for all test suites:

• Combined Coverage Report
• Individual test coverage artifacts available in workflow runs