193## Making a Pull Request194 195### Keep PRs Small and Focused196 197Large PRs are difficult to review and more prone to errors. We strongly encourage smaller, self-contained PRs:198 199- **Size limits**: Keep PRs under 500 lines of code changed and under 10 code files modified (excludes documentation, lock files, and auto-generated files)200- **Single responsibility**: Each PR should address one concern (one feature, one bug fix, or one refactor)201- **Split large changes**: If your task requires extensive changes, break it into multiple PRs that can be reviewed and merged independently202 203**How to split large changes:**204- Separate database/schema changes from application logic205- Split frontend and backend changes when possible206- Do preparatory refactoring in a separate PR before adding new features207- Create PRs in dependency order (infrastructure first, then features)208 209### PR Checklist210 211- Be sure to [check the "Allow edits from maintainers" option](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork) when creating your PR. (This option isn't available if you're [contributing from a fork belonging to an organization](https://github.com/orgs/community/discussions/5634))212- If your PR refers to or fixes an issue, add `refs #XXX` or `fixes #XXX` to the PR description. Replace `XXX` with the respective issue number. See more about [linking a pull request to an issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).213- Fill out the PR template accordingly.214- Review the [App Contribution Guidelines](./packages/app-store/CONTRIBUTING.md) when building integrations.215- Lastly, make sure to keep your branches updated (e.g., click the `Update branch` button on the GitHub PR page).

104### Repository Files105 106- Repository class files must include the `Repository` suffix.107- If the repository is backed by a specific technology (e.g. Prisma), prefix the filename and class name with it.108- File name must match the exported class exactly (PascalCase).109 110**Pattern:**111 112`Prisma<Entity>Repository.ts`113 114**Examples:**115 116```ts117// File: PrismaAppRepository.ts118export class PrismaAppRepository { ... }119 120// File: PrismaMembershipRepository.ts121export class PrismaMembershipRepository { ... }122```123 124This avoids ambiguous filenames like app.ts and improves discoverability in editors.125 126### Service Files127 128- Service class files must include the Service suffix.129- File name should be in PascalCase, matching the exported class.130- Keep naming specific — avoid generic names like AppService.ts.131 132**Pattern:**133 134`<Entity>Service.ts`135 136**Examples:**137 138```ts139// File: MembershipService.ts140export class MembershipService { ... }141 142// File: HashedLinkService.ts143export class HashedLinkService { ... }144```

81            // Check 1: Is the author a trusted contributor?82            if (trustedAssociations.includes(pr.author_association)) {83              console.log(`Author has trusted association: ${pr.author_association}`);84              core.setOutput('is-trusted', true);85              return;86            }87 88            // Check 2: Verify write access via API (author_association can be unreliable)89            if (await hasWriteAccess(pr.user.login)) {90              console.log(`Author has write access`);91              core.setOutput('is-trusted', true);92              return;93            }94 95            // Check 3: Was 'run-ci' label added AFTER this SHA was pushed by someone with write access?96            // This enables re-runs triggered by the run-ci.yml workflow97            // NOTE: We use workflow run created_at instead of commit timestamp because98            // git commit timestamps can be arbitrarily backdated by attackers99            if (pr.labels?.some(l => l.name === 'run-ci')) {