docs: add pr.author_type context variable [LINBEE-12321]

[MishaKav]

Documents pr.author_type (user / bot / organization).

• https://linearb.atlassian.net/browse/LINBEE-12321
• Closes Add author type to all author context instances  #596
• Implementation: linear-b/gitstream-sls-pipeline#3005 → #3009 (stacked)

Values are lowercase, matching pr.status and repo.visibility. Notes the two coverage limits: GitHub PAT-based automation and Bitbucket access-token bot users both report user.

✨ PR Description

Purpose: Document the new pr.author_type context variable that identifies PR author account type (user, bot, or organization).

Main changes:

• Added pr.author_type field to PR context variables table with string type and account kind values
• Included comprehensive documentation section explaining limitations on GitHub (GitHub Apps only) and Bitbucket platform differences
• Provided automation examples showing bot detection without maintaining bot name lists

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}

[orca-security-us]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	OSS Licenses	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[linearb]

✨ PR Review

The PR is a clear and useful documentation addition for pr.author_type. The explanation of limitations and the fallback example pattern are valuable. One subtle but important issue exists in the example code snippet that could mislead users.

1 issues detected:

🐞 Bug - `"[bot]"` is a regex character class matching one of 'b', 'o', or 't', not the literal `[bot]` suffix used in GitHub bot usernames. 🛠️

Details: In the fallback example, "[bot]" is used as a match-list entry. In regex, [bot] is a character class that matches any single character that is 'b', 'o', or 't' — not the literal string [bot]. GitHub appends the literal suffix [bot] to automated account usernames (e.g., github-actions[bot], dependabot[bot]), so the documented pattern will silently produce incorrect results: it will match far too broadly (any name containing 'b', 'o', or 't') while missing the exact intended pattern.

File: docs/context-variables.md (335-335)

_{🛠️ A suggested code correction is included in the review comments.}

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[Copilot]

Pull request overview

Adds documentation for the new pr.author_type context variable so automations can distinguish PRs opened by user, bot, or organization, and includes platform-specific caveats to set expectations.

Changes:

• Added pr.author_type to the pr context variable table.
• Added a dedicated “PR author type” note section with usage examples and GitHub/Bitbucket limitations.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MishaKav]

/gs feedback False positive. match(list=[...]) does substring matching, not regex — the two are mutually exclusive parameters. In gitstream-core src/rules-parser/filters/general-filters.ts:26-39, termRegexOrList routes term and list entries through internalIncludes and only regex= through internalRegex; internalIncludes is file?.includes(searchTerm) (src/rules-parser/filters/common.ts:3), and parseTermToValidString only treats a value as a pattern when it starts with r/. So "[bot]" is matched as the literal 4-character string, never as a character class. Corroborating evidence: gitStream ships this exact list in its own default automations — bot_author: {{ pr.author | match(list=["github-actions", "_bot_", "[bot]", "dependabot"]) | some }} (gitstream-sls-pipeline src/common/cmFile/defaultAutomations.consts.ts:217). If the finding were correct, default bot detection would be broken for every customer. No docs change needed.