Bitbucket vs Gitea

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Bitbucket—none0/10

   Direct probes for llms.txt, markdown docs, and OpenAPI specs all returned 404s, and no evidence shows Bitbucket/Atlassian publishing agent-oriented docs like llms.txt.

   • [probe] “PROBE llms.txt: HTTP 404 at https://support.atlassian.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”

   proof ↗⚑ flag

   Gitea—none0/10

   The probe explicitly shows llms.txt returns 404 at docs.gitea.com, and no other evidence indicates agent-oriented documentation exists elsewhere; the OpenAPI probe also failed, further indicating no machine-readable/agent-friendly docs endpoint.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.gitea.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Gitea
   Bitbucket✓fullclaimed7/10

   Bitbucket ships a native CI/CD system (Pipelines) that runs headlessly with hosted or private runners and 'no infrastructure needed,' and explicitly supports triggering AI-powered automated workflows (cleanup, docs, release notes, flaky-test fixes) from the pipeline. This directly satisfies running the product headlessly/in CI for automation. missing for 10: independent/hands-on corroboration of Pipelines reliability and any CLI-level headless invocation outside the pipeline UI.

   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”
   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”

   proof ↗⚑ flag

   Gitea✓fullprobed8/10

   Gitea deploys as a single binary or container with no complex dependencies, runs on Linux/Windows/macOS/Kubernetes, and exposes a full REST API, webhooks, and an official CLI ('tea') for scripting — all enabling headless/CI automation. Community evidence corroborates smooth Docker-based headless deployments on small VPS/servers. Missing for 10: an explicit first-party guide on running Gitea itself as an ephemeral CI service/container, and independent hands-on proof of automated CI orchestration beyond deployment reports.

   • [claimed-docs] “It can be easily deployed on various servers without complex configurations or dependencies.”
   • [claimed-docs] “Universally compatible with diverse operating systems and environments, including Linux, Windows, macOS, FreeBSD, and Kubernetes. Compatible…”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [probe] “official CLI documented at https://gitea.com/gitea/tea”
   • [community] “Used Gitea (previously Gogs) for a team of 45; setup with Docker was smooth and worked easily with Certbot, but documentation is lacking (ha…”
   • [community] “Put Gitea on a $5 VPS for personal projects; works great, though unsure how secure it is if exposed publicly (uses SSH port-forwarding inste…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Bitbucket—none0/10

   The only MCP-related evidence found is Atlassian's own MCP server (bitbucket-probe-4), meaning Bitbucket exposes tools via MCP rather than allowing users to plug external MCP servers into Bitbucket so it can use their tools. No evidence shows Bitbucket/Rovo acting as an MCP client that can consume third-party MCP servers.

   • [probe] “official MCP server documented at https://github.com/atlassian/atlassian-mcp-server”
   • [claimed-docs] “Access the latest models with Rovo — in your terminal or in your IDE.”

   proof ↗⚑ flag

   Gitea—none0/10

   The story asks whether Gitea itself can consume external MCP servers' tools (client-side), but the only MCP-related evidence shows Gitea publishing its own MCP server (gitea-mcp) for others to call into Gitea, not Gitea invoking outside MCP tools. No evidence of Gitea acting as an MCP client or integrating third-party MCP servers into its workflows.

   • [probe] “official MCP server documented at https://gitea.com/gitea/gitea-mcp”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Bitbucket✓fullprobed7/10

   There is direct evidence of an official Atlassian MCP server repository (atlassian-mcp-server), which covers Bitbucket as part of the Atlassian suite, enabling agents to connect via MCP. However, the evidence pack lacks detailed documentation on Bitbucket-specific MCP setup, tool scope, or independent hands-on confirmation. Missing for 10: first-party Bitbucket docs describing MCP server usage, independent verification of the server's functionality with Bitbucket specifically.

   • [probe] “official MCP server documented at https://github.com/atlassian/atlassian-mcp-server”

   proof ↗⚑ flag

   Gitea✓fullprobed7/10

   There is direct evidence of an official Gitea MCP server repository (gitea/gitea-mcp) that would let AI agents connect to Gitea, and Gitea is not itself an agent product so the axis applies. Missing for 10: detailed docs on setup/configuration, independent hands-on validation, and tool/capability list exposed via MCP.

   • [probe] “official MCP server documented at https://gitea.com/gitea/gitea-mcp”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Gitea
   Bitbucket~partialclaimed4/10

   Docs mention Rovo being accessible 'in your terminal or in your IDE,' implying some CLI-based AI access, but there's no dedicated documentation of an official Bitbucket CLI tool, its command set, or installation/usage details. missing for 10: dedicated official CLI product docs, command reference, installation instructions, independent corroboration of CLI usage.

   • [claimed-docs] “Access the latest models with Rovo — in your terminal or in your IDE.”

   proof ↗⚑ flag

   Gitea~partialprobed5/10

   Gitea has an official CLI ('tea') documented, but the evidence pack gives no detail on AI-native features (scripting for agents, structured output, automation-friendly design) — it's just a generic CLI reference. missing for 10: documentation of AI-native/agentic use cases for the CLI, details on output formats or automation support, independent corroboration of CLI capabilities.

   • [probe] “official CLI documented at https://gitea.com/gitea/tea”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to Gitea
   Bitbucket—none0/10

   The evidence pack contains no documentation or reference to a public Bitbucket REST/GraphQL API; the only related probes (llms.txt, docs.md, OpenAPI spec) all returned 404s, and no other citation mentions an API for programmatic control. While a documented API is a plausible axis for an SCM/CI platform, this pack provides no confirming evidence.

   • [probe] “PROBE llms.txt: HTTP 404 at https://support.atlassian.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”

   proof ↗⚑ flag

   Gitea~partialprobed6/10

   Gitea documents a public API and webhooks for building custom workflows, and third-party evidence confirms scriptable behavior (e.g., creating private repos via git push without UI/CLI), plus an official CLI (tea) exists. However, probes found no discoverable OpenAPI spec or llms.txt at the expected docs endpoints, and there's no first-party documentation snippet in the pack showing detailed API reference structure or auth flows. Missing for 10: verifiable OpenAPI/swagger spec discovery, llms.txt or AI-friendly docs, and independent hands-on confirmation of API usage beyond one anecdote.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [community] “You can create a private repo without using the UI/CLI just by adding a git remote and pushing—Gitea auto-creates it as private.”
   • [probe] “official CLI documented at https://gitea.com/gitea/tea”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.gitea.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Gitea
   Bitbucket—none0/10

   Evidence shows only general workspace/repo/branch permission controls (bitbucket-docs-9) but nothing about issuing scoped or least-privilege API credentials/tokens specifically for an AI agent, such as app passwords or API token scopes tied to agent use cases.

   • [claimed-docs] “Control permissions at the workspace, project, or repo level, and define granular branch‑level, environment‑level, and package permissions —…”

   proof ↗⚑ flag

   Gitea~partialclaimed3/10

   Gitea's docs mention general permission management/ACLs and an API for building custom workflows, which implies some capability to control access, but the evidence pack contains no explicit documentation of fine-grained/scoped personal access tokens or least-privilege credential issuance for agent use. Missing for 10: explicit docs on scoped API token creation, granular permission scopes for tokens, and any hands-on confirmation that an agent can be issued a least-privilege credential.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Bitbucket—none0/10

   The evidence pack contains no mention of official SDKs for building against Bitbucket/Atlassian APIs, and the probes explicitly show 404s for openapi/API-schema and machine-readable docs endpoints, indicating no discoverable SDK or API spec was found. Only an MCP server is documented, which addresses a different story, not SDK access.

   • [probe] “PROBE llms.txt: HTTP 404 at https://support.atlassian.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”

   proof ↗⚑ flag

   Gitea—none0/10

   Gitea documents a general REST API and webhooks (gitea-docs-4) but no evidence of official client SDKs/libraries; OpenAPI/spec probes returned 404 (gitea-probe-2) and no llms.txt exists (gitea-probe-1). CLI (tea) and an MCP server exist but these are not SDKs for building integrations.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.gitea.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Gitea
   Bitbucket—none0/10

   The evidence pack contains no mention of webhooks or event subscription APIs for Bitbucket; docs cover Jira integration, AI code review, CI/CD, security, and permissions but not webhook support, which is a well-known Bitbucket capability but unevidenced here.

   ⚑ flag

   Gitea✓fullclaimed7/10

   Gitea's docs explicitly mention webhooks as a way to extend functionality and create custom workflows, and Gitea is well-known for repo/issue/PR event webhooks, which is a mainstream Gitea feature referenced in official docs. missing for 10: detailed documentation of specific webhook event types/payloads, independent hands-on confirmation of webhook reliability, and any AI-specific integration examples.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Bitbucket
   Bitbucket~partialclaimed6/10

   Bitbucket docs claim AI code review that reviews changes and suggests fixes, plus Rovo-powered AI workflows and model access, indicating AI-generated insights/suggestions from repository data. However, these are vendor claims with no independent/hands-on corroboration, and community evidence is silent on AI features entirely. Missing for 10: independent verification of AI review quality, concrete examples of AI-generated insights in practice, and detail on how deeply Rovo integrates with actual code/data.

   • [claimed-docs] “Our AI code reviewer reviews all code changes and suggests fixes so you can merge faster.”
   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Access the latest models with Rovo — in your terminal or in your IDE.”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of any AI-generated insights, summaries, or suggestions surfaced from Gitea's own data (e.g., code review AI, issue analysis, PR summarization). The MCP server exposes Gitea data to external agents but doesn't itself generate insights, and no other AI-native features are documented.

   ⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Gitea
   Bitbucket~partialclaimed5/10

   Bitbucket documents AI-triggered pipeline automations (cleanup, docs updates, release notes, flaky test fixes) that run 'all from your pipeline,' suggesting background autonomous execution, but there is no detail on scheduling, triggers, or true autonomy without human initiation, and no independent/hands-on corroboration. Missing for 10: concrete documentation of trigger conditions/scheduling for autonomous runs, evidence of unattended multi-step agentic execution, and third-party confirmation the feature works as described.

   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”

   proof ↗⚑ flag

   Gitea✓fullclaimed7/10

   Gitea Actions (gitea-docs-2) provides CI/CD workflows that run autonomously in response to events/schedules, and webhooks/API (gitea-docs-4) allow further custom automations, both of which enable background automations without manual triggering. missing for 10: independent/hands-on corroboration of Actions running reliably at scale, and AI-specific orchestration examples.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Bitbucket
   Bitbucket~partialclaimed6/10

   Bitbucket docs mention built-in AI capabilities: an AI code reviewer that reviews changes and suggests fixes, AI-powered pipeline workflows to automate tasks (feature flag cleanup, docs updates, release notes, flaky test fixes), and access to Rovo AI assistant in terminal/IDE. These support delegating tasks to a built-in AI assistant, but the story's depth (e.g., detailed task delegation UX, chat-based commands) isn't well documented and there is no independent/hands-on corroboration of these AI features actually working. Missing for 10: independent verification of AI assistant behavior, deeper documentation of delegation workflow, and community evidence confirming real-world use.

   • [claimed-docs] “Our AI code reviewer reviews all code changes and suggests fixes so you can merge faster.”
   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Access the latest models with Rovo — in your terminal or in your IDE.”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of a built-in AI assistant in Gitea; the product offers an MCP server for external agents to connect to, but that is not a native AI assistant feature delegable by an end user within the product itself.

   ⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Bitbucket—none0/10

   Evidence shows AI code review, AI-triggered pipeline workflows, and Rovo access in terminal/IDE, but nothing indicates Bitbucket itself can be operated via natural-language commands (e.g., chat-based repo management, NL-driven PR/merge actions). Missing for 10: any documentation of natural-language command interface, conversational control of Bitbucket actions, or hands-on evidence of NL-driven operation.

   • [claimed-docs] “Our AI code reviewer reviews all code changes and suggests fixes so you can merge faster.”
   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Access the latest models with Rovo — in your terminal or in your IDE.”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence Gitea itself exposes natural-language command interfaces; the CLI (tea) and API/webhooks are structured, not NL-based, and llms.txt/openapi probes returned 404s. Presence of an MCP server implies external agents could translate NL into API calls, but that is a separate integration axis, not Gitea natively supporting NL commands.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.gitea.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”
   • [probe] “official MCP server documented at https://gitea.com/gitea/gitea-mcp”
   • [probe] “official CLI documented at https://gitea.com/gitea/tea”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Bitbucket—none0/10

   No evidence of an interactive API reference or runnable examples; probes for OpenAPI/docs-md/llms.txt all returned 404s, indicating no such interactive reference is exposed.

   • [probe] “PROBE llms.txt: HTTP 404 at https://support.atlassian.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”

   proof ↗⚑ flag

   Gitea—none0/10

   While Gitea documents having an API (gitea-docs-4), the evidence pack shows no interactive API reference or runnable examples—probes for OpenAPI/Swagger specs at the docs site returned 404s, and no community or docs evidence mentions a Swagger UI or interactive playground.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Bitbucket—none0/10

   Probes explicitly show no OpenAPI/swagger spec found at Bitbucket's/Atlassian's support domain, and no docs evidence mentions a downloadable machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://support.atlassian.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”

   proof ↗⚑ flag

   Gitea—none0/10

   Gitea's docs mention a generic 'API' for extending functionality (gitea-docs-4), but there is no evidence of a downloadable OpenAPI/Swagger spec; direct probes for openapi.json/swagger.json/llms.txt at the docs site all returned 404 (gitea-probe-1, gitea-probe-2). No first-party or community evidence confirms a machine-readable API spec is published.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.gitea.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Bitbucket—none0/10

   No evidence of a versioned API or documented deprecation policy; probes for OpenAPI/docs endpoints returned 404s and no mention of API versioning or deprecation exists in the evidence pack.

   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”

   proof ↗⚑ flag

   Gitea—none0/10

   Evidence only shows generic API/webhook extensibility (gitea-docs-4) with no mention of API versioning scheme or a documented deprecation policy; probes for OpenAPI/llms.txt spec both 404 (gitea-probe-1, gitea-probe-2). A community report even describes a breaking change (1.17.0 reserved usernames) with maintainers dismissing concerns, further indicating no formalized deprecation process (gitea-comm-17).

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.gitea.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”
   • [community] “Complaint about Gitea 1.17.0 breaking changes (e.g. reserving usernames) and maintainers allegedly ignoring valid concerns about email regex…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Gitea
   Bitbucket—none0/10

   No evidence describes bulk operations across many items (e.g., batch PR merges, bulk repo/branch management, mass API operations) for AI-native or automated workflows; docs focus on single-PR review, CI/CD pipelines, and policy enforcement rather than bulk/batch actions.

   ⚑ flag

   Gitea~partialprobed4/10

   Gitea exposes a REST API and webhooks (gitea-docs-4) and an official CLI 'tea' (gitea-probe-4) that could be scripted for bulk operations, but there is no direct evidence of built-in bulk-action features (e.g., multi-item issue/PR batch edits, bulk merges) or documentation describing bulk workflows for AI-native automation. missing for 10: explicit documentation or examples of bulk/batch operations across many items, evidence of API rate limits or batch endpoints suited for large-scale automation, and independent confirmation that CLI/API supports bulk operations at scale.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [probe] “official CLI documented at https://gitea.com/gitea/tea”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Gitea
   Bitbucket~partialclaimed6/10

   Bitbucket supports event-driven automation via Pipelines (triggered on push/PR/tag events), merge checks/branch policies, and Jira issue auto-updates on commit events, which cover core event→action rule triggering. However there's no dedicated declarative 'rules engine' (like Jira Automation) for defining custom conditional triggers beyond CI/CD pipeline YAML and merge-check policies. Missing for 10: a first-class no-code rules/automation builder for arbitrary event-condition-action logic, and independent hands-on validation of rule reliability.

   • [claimed-docs] “when you include your issue key in commits, your Jira issue statuses update automatically”
   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”
   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”

   proof ↗⚑ flag

   Gitea✓fullclaimed7/10

   Gitea Actions provides GitHub Actions-compatible YAML workflows that trigger automatically on repo events (push, PR, etc.), and webhooks/API allow custom automation rules to fire on additional events. This directly satisfies 'rules that trigger actions automatically on events.' Missing for 10: independent/hands-on corroboration of Actions triggers in practice, and any AI-native-specific tooling or examples (e.g., AI agent hooked to webhook events) beyond generic docs.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Gitea
   Bitbucket—none0/10

   The evidence describes CI/CD pipelines, AI-triggered workflows, and merge automation, but no citation mentions scheduling recurring jobs or cron-like automation. Missing for 10: any mention of scheduled/recurring pipeline triggers, cron syntax, or automated recurring task execution.

   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”

   proof ↗⚑ flag

   Gitea~partialclaimed4/10

   Gitea Actions is described as YAML-based and 'compatible with GitHub Actions,' which implies support for scheduled/cron workflow triggers since that's a core GitHub Actions feature, but no citation explicitly confirms a 'schedule' event trigger or documents recurring job scheduling. missing for 10: explicit documentation of cron/schedule triggers in Gitea Actions, hands-on confirmation from users running recurring workflows, and details on any limitations vs GitHub Actions' scheduling.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Gitea
   Bitbucket~partialclaimed4/10

   Bitbucket Pipelines configs live in the same git repo, so pull-request review (docs-7, docs-11) and change-management enforcement (docs-6) apply to pipeline/automation changes, and AI-powered pipeline workflows are documented (docs-4, docs-8, docs-10). However, no evidence explicitly confirms automation-specific versioning history, dedicated review flows for automation scripts, or a rollback mechanism for automations. Missing for 10: explicit documentation of automation version history/diffing, dedicated review workflow for automation changes, and an explicit rollback/undo feature for pipeline or Rovo-triggered automations.

   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”
   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”
   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”

   proof ↗⚑ flag

   Gitea✓fullclaimed7/10

   Gitea Actions workflows are YAML files stored in-repo, so they inherit full git history, branch/PR review, and revert capability like any other code (gitea-docs-1, gitea-docs-2, gitea-docs-3). This gives version control, review via pull requests, and rollback via git history for automation definitions, though Gitea provides no automation-specific rollback UI or workflow-run diffing beyond generic git tooling. Missing for 10: dedicated workflow versioning/rollback UI (e.g. one-click revert of a workflow run), independent hands-on confirmation of rolling back Actions specifically, and clarity on whether workflow run history itself (not just definitions) is preserved/reversible.

   • [claimed-docs] “Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing …”
   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”

   proof ↗⚑ flag

Deployment

1. developerAutomate application deployments as part of my CI/CD pipeline

   weight 2 · round to Bitbucket
   Bitbucket✓fullclaimed7/10

   Bitbucket Pipelines is documented as a built-in CI/CD tool for automated workflows, with deployment environments, permissions, and centralized visibility across pipeline/deployment status, supporting deployment automation as part of CI/CD. Missing for 10: hands-on/independent evidence of deployment pipeline execution, detailed deployment-specific docs (e.g., deployment triggers, rollback), and no community corroboration of deployment automation specifically.

   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Control permissions at the workspace, project, or repo level, and define granular branch‑level, environment‑level, and package permissions —…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”

   proof ↗⚑ flag

   Gitea~partialcommunity7/10

   Gitea Actions provides GitHub Actions-compatible YAML workflows and reuses the Actions ecosystem, which supports building deployment pipelines, and its API/webhooks allow custom deployment automation. However, evidence lacks specifics on deployment-oriented features like environments, secrets management, or runner scaling, and community evidence mostly shows pairing Gitea with an external CI tool (Drone) rather than using Actions itself for deployment. Missing for 10: concrete deployment pipeline examples, environment/secrets support details, independent corroboration of Actions-based deployment success.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [community] “Using Gitea + Drone for several years: stable, fast, and doesn't consume a lot of RAM.”

   proof ↗⚑ flag

2. devops-leadMap incidents to deployments and require change approval before releases

   weight 1 · round to Bitbucket
   Bitbucket✓fullclaimed8/10

   Bitbucket docs explicitly state that incidents can be mapped to deployments and automated change approval processes enabled via integration with Jira Service Management, directly matching the story, and this is reinforced by merge checks/CI-CD policy enforcement features. Missing for 10: independent/hands-on verification of the incident-deployment mapping workflow beyond vendor docs.

   • [claimed-docs] “Enable automated change approval processes and resolve incidents faster by mapping incidents to deployments with Bitbucket and Jira Service …”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”
   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”

   proof ↗⚑ flag

   Gitea—none0/10

   Evidence shows Gitea's PR/code review workflow and Actions CI/CD, but nothing about mapping incidents to deployments or requiring formal change-approval gates before releases (e.g., no incident tracking integration, no deployment-approval workflow beyond generic branch protection mentions). This capability is a fair ask for a CI/CD platform but is simply unevidenced here.

   ⚑ flag

Pipeline authoring

1. developerReuse community-built CI/CD actions or plugins in my pipelines

   weight 2 · round to Gitea
   Bitbucket—none0/10

   The evidence pack describes Bitbucket Pipelines, security integrations like Snyk, and connections to on-prem CI tools, but never mentions a marketplace of community-built Pipes/actions or reusable third-party pipeline plugins that developers can drop into their pipelines.

   ⚑ flag

   Gitea✓fullclaimed8/10

   Gitea Actions is explicitly documented as GitHub Actions-compatible, using standard YAML workflows and allowing reuse of existing Actions plugins from the ecosystem, directly matching the story. Missing for 10: independent hands-on confirmation of reusing specific community actions and marketplace-scale ecosystem evidence beyond vendor docs.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”

   proof ↗⚑ flag

2. developerDefine CI/CD pipelines as code using a YAML syntax

   weight 3 · round to Gitea
   Bitbucket~partialclaimed6/10

   Bitbucket Pipelines is documented as the built-in CI/CD tool supporting hosted/private runners and centralized pipeline visibility, which aligns with a pipelines-as-code model, but the evidence never explicitly states the YAML file syntax (e.g., bitbucket-pipelines.yml) developers use to define pipelines. Missing for 10: explicit mention of YAML config file/syntax, example pipeline definitions, and independent hands-on confirmation of the YAML authoring experience.

   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”
   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”

   proof ↗⚑ flag

   Gitea✓fullcommunity8/10

   Gitea Actions explicitly supports CI/CD pipelines defined in YAML, compatible with GitHub Actions syntax, and Gitea+CI (Drone/Actions) usage is corroborated by community reports. missing for 10: independent hands-on validation specifically of Gitea Actions YAML syntax (most community evidence discusses Drone as external CI rather than native Actions).

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [community] “Using Gitea + Drone for several years: stable, fast, and doesn't consume a lot of RAM.”

   proof ↗⚑ flag

Runners

1. devops-leadRun CI/CD jobs on runners hosted by the platform without managing infrastructure

   weight 3 · round to Bitbucket
   Bitbucket✓fullclaimed8/10

   Docs explicitly state Bitbucket Pipelines provides hosted runners so teams can run CI/CD workflows 'no infrastructure needed', with centralized visibility across pipelines, and also offers private runners as an alternative. Missing for 10: independent/hands-on corroboration of hosted-runner reliability or scale, and no detail on hosted runner resource limits/pricing.

   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”

   proof ↗⚑ flag

   Gitea—none0/10

   Gitea Actions (gitea-docs-2) provides CI/CD workflow support compatible with GitHub Actions syntax, but Gitea is self-hosted software and the evidence never mentions a Gitea-operated hosted runner fleet — users must deploy and manage their own runners as part of self-hosting Gitea. No evidence of a managed/SaaS runner offering exists in this pack.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”

   proof ↗⚑ flag

2. devops-leadGet centralized visibility into CI/CD workflow runs across the organization

   weight 2 · round to Bitbucket
   Bitbucket~partialclaimed6/10

   Docs claim centralized visibility into pipeline status, testing policies, and deployment environments across the org via Bitbucket Pipelines (hosted/private runners), with policy enforcement across teams and repos. However, this is vendor-only marketing copy with no independent/hands-on corroboration of an actual cross-org dashboard or reporting UI, and no detail on how granular or org-wide the visibility truly is. Missing for 10: independent verification of the centralized dashboard's usability/completeness, detail on cross-project rollups, and community evidence confirming it works at scale.

   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”

   proof ↗⚑ flag

   Gitea~partialcommunity4/10

   Gitea Actions provides CI/CD workflow execution compatible with GitHub Actions syntax (gitea-docs-2), which is the prerequisite for any visibility into pipeline runs, and community reports confirm real-world CI usage via Gitea+Drone or Actions (gitea-comm-8). However, the evidence pack contains no mention of an organization-wide dashboard or aggregated view across repos' Actions runs — only per-repo Actions functionality is documented. Missing for 10: evidence of a centralized/org-level CI dashboard, cross-repo run aggregation, notifications rollup, or reporting APIs for workflow status across an organization.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [community] “Using Gitea + Drone for several years: stable, fast, and doesn't consume a lot of RAM.”

   proof ↗⚑ flag

3. devops-leadRun CI/CD jobs on my own self-hosted or private runners

   weight 2 · round to Bitbucket
   Bitbucket✓fullclaimed7/10

   Bitbucket docs explicitly state you can run CI/CD workflows using 'hosted or private runners—or both,' with centralized visibility, directly matching the self-hosted/private runner story, and also supports connecting to on-prem CI/CD tools like Bamboo or Jenkins. Missing for 10: independent/hands-on corroboration of private runner setup or reliability, and detail on runner configuration/scaling.

   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”

   proof ↗⚑ flag

   Gitea~partialcommunity6/10

   Gitea Actions is documented as a native CI/CD system compatible with GitHub Actions YAML workflows, which by design runs on self-hosted runners since Gitea itself is self-hosted (gitea-docs-2). However, the evidence pack lacks explicit runner registration/configuration details, and community reports show long-time Gitea users relying on external CI tools like Drone rather than native Actions (gitea-comm-8, gitea-comm-14), suggesting the built-in CI/CD runner feature is newer/less proven in practice. missing for 10: explicit runner setup/registration docs, hands-on confirmation of self-hosted runner reliability, independent corroboration beyond vendor docs.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [community] “Using Gitea + Drone for several years: stable, fast, and doesn't consume a lot of RAM.”
   • [community] “Migrated from self-hosted Gitlab to Gitea, Nexus and Drone because maintaining Gitlab's size/complexity was too cumbersome; Gitea's UI is a …”

   proof ↗⚑ flag

Chat notifications

1. developerSync repository notifications and activity with chat tools

   weight 1 · round to Gitea
   Bitbucket—none0/10

   No evidence pack item mentions Slack/Teams/chat notification integrations or activity syncing with chat tools; all docs focus on Jira, CI/CD, security scanning, and AI features. Missing for 10: any mention of Slack/Teams integration, chat notification setup, or activity feed syncing to chat tools.

   ⚑ flag

   Gitea~partialclaimed6/10

   Gitea's own marketing explicitly claims syncing with Slack, Discord, MS Teams, Lark via webhooks/integrations, but this is only vendor-stated with no independent/hands-on corroboration of notification sync working in practice. missing for 10: hands-on/community verification of chat notification sync, details on which events sync (issues, PRs, activity) and any setup limitations.

   • [claimed-docs] “Sync seamlessly with tools like Slack, Discord, MS Teams, Lark, and more.”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”

   proof ↗⚑ flag

External ci cd integration

1. devops-leadConnect the platform to external CI/CD tools instead of using its native pipelines

   weight 1 · round to Bitbucket
   Bitbucket✓fullclaimed8/10

   Bitbucket docs explicitly state you can use built-in Pipelines 'or connect Bitbucket Cloud to on-prem CI/CD tools like Bamboo or Jenkins,' directly confirming external CI/CD integration as an alternative to native pipelines. Missing for 10: independent/hands-on corroboration of setting up Jenkins/Bamboo integration and broader detail on other third-party CI/CD tool support beyond Bamboo/Jenkins.

   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”

   proof ↗⚑ flag

   Gitea✓fullcommunity7/10

   Gitea exposes webhooks and a full API explicitly for building custom workflows/integrations, and real-world users confirm pairing Gitea with external CI systems like Drone for years as an alternative to native Actions. This shows the platform is commonly used with third-party CI/CD tools rather than being locked into its own pipeline system. Missing for 10: dedicated first-party documentation on integrating specific external CI/CD tools (e.g. Jenkins, CircleCI) and more than one independent corroborating source.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [community] “Using Gitea + Drone for several years: stable, fast, and doesn't consume a lot of RAM.”
   • [community] “Migrated from self-hosted Gitlab to Gitea, Nexus and Drone because maintaining Gitlab's size/complexity was too cumbersome; Gitea's UI is a …”

   proof ↗⚑ flag

Marketplace extensions

1. developerExtend my stack with third-party apps, actions, and AI models from a marketplace

   weight 2 · round to Bitbucket
   Bitbucket~partialclaimed5/10

   Evidence shows some third-party/AI extensibility — Snyk security scanning integration, ability to connect to on-prem CI/CD tools, and Rovo AI model access in terminal/IDE — but there's no explicit mention of an app marketplace, listing of third-party apps, or an ecosystem of installable actions comparable to a dedicated marketplace story. Missing for 10: explicit marketplace/app directory documentation, breadth of third-party app listings, and independent corroboration of marketplace usage.

   • [claimed-docs] “Run automatic security scans with out-of-the-box integration with Snyk, or connect to other providers. Simply open an existing repository or…”
   • [claimed-docs] “Access the latest models with Rovo — in your terminal or in your IDE.”
   • [claimed-docs] “Use our built-in CI/CD tool, Bitbucket Pipelines, to create powerful, automated workflows. Or connect Bitbucket Cloud to on-prem CI/CD tools…”
   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”

   proof ↗⚑ flag

   Gitea~partialprobed4/10

   Gitea supports extensibility via Actions (reusing GitHub Actions-compatible plugins), API/webhooks, and package registries, but there's no evidence of a curated marketplace for third-party apps or AI models specifically. missing for 10: a dedicated marketplace/app store UI, AI model integrations or marketplace, curated third-party app listings, and independent confirmation of ecosystem breadth.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [claimed-docs] “Gitea supports over 20 different types of public or private software package management, including Cargo, Chef, Composer, Conan, Conda, Cont…”
   • [probe] “official MCP server documented at https://gitea.com/gitea/gitea-mcp”
   • [probe] “official CLI documented at https://gitea.com/gitea/tea”

   proof ↗⚑ flag

Security tool integrations

1. devops-leadInstall third-party security scanning integrations directly from a security tab

   weight 1 · round to Bitbucket
   Bitbucket✓fullclaimed8/10

   Docs explicitly confirm running automated security scans via out-of-the-box Snyk integration installed directly from the Security tab, plus support for connecting other providers, matching the story closely. Missing for 10: independent/hands-on corroboration of the Security tab install flow and breadth of third-party scanner ecosystem beyond Snyk.

   • [claimed-docs] “Run automatic security scans with out-of-the-box integration with Snyk, or connect to other providers. Simply open an existing repository or…”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of a dedicated security tab or marketplace for installing third-party security scanning integrations; Gitea only offers generic webhooks/API and Actions CI compatible with GitHub Actions, not a curated security integrations UI.

   ⚑ flag

Onboarding

1. developerAccess built-in resources to learn the Git version control system

   weight 1 · round drawn
   Bitbucket—none0/10

   No evidence pack items reference built-in Git tutorials, guides, or learning resources for the Git version control system itself; the docs focus on Jira integration, CI/CD, AI review, permissions, and security, not educational content about learning Git.

   ⚑ flag

   Gitea—none0/10

   The evidence pack covers Gitea's own feature docs (repos, CI/CD, issues, packages) but contains no mention of built-in tutorials, guides, or learning resources for the Git VCS itself. This is a plausible axis for a git hosting platform, but no evidence shows Gitea provides such educational content.

   ⚑ flag

Policy enforcement

1. devops-leadRequire automated change approval workflows before code reaches production

   weight 1 · round to Bitbucket
   Bitbucket✓fullclaimed7/10

   Bitbucket docs explicitly describe merge checks, branch permissions, CI/CD policy enforcement, and an explicit 'automated change approval process' integration with Jira Service Management mapping incidents to deployments, directly matching the governance story. Missing for 10: independent/hands-on verification of approval gating in practice and more detail on multi-stage production approval workflows beyond marketing copy.

   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”
   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”
   • [claimed-docs] “Control permissions at the workspace, project, or repo level, and define granular branch‑level, environment‑level, and package permissions —…”
   • [claimed-docs] “Enable automated change approval processes and resolve incidents faster by mapping incidents to deployments with Bitbucket and Jira Service …”

   proof ↗⚑ flag

   Gitea~partialclaimed5/10

   Gitea's docs confirm a pull-request based code review workflow with reviewer comments and Actions-based CI/CD that could gate merges, giving the building blocks for an approval gate, but the evidence pack never documents branch-protection rules requiring N approvals or status checks before merge, which is the core mechanism for enforced pre-production approval. missing for 10: explicit branch-protection/required-reviewer-approval documentation, evidence of blocking merge until CI passes, independent confirmation the workflow is enforced in practice.

   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”

   proof ↗⚑ flag

2. devops-leadEnforce coding standards and CI/CD policies across all teams and repositories

   weight 2 · round drawn
   Bitbucket~partialcommunity6/10

   First-party docs directly claim enforcement of coding standards, CI/CD policies, merge checks, and granular permissions across teams/repos (bitbucket-docs-6, -7, -8, -9), which is exactly the story asked for. However, independent community evidence shows a real gap: an admin reported no way to prevent team members from making repositories public in Bitbucket Enterprise Cloud, undercutting the 'control at scale' claim (bitbucket-comm-19). Missing for 10: independent corroboration that merge-check/CI policy enforcement actually works at scale, and resolution of the reported permission-control gap.

   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”
   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”
   • [claimed-docs] “Run CI/CD workflows across your organization using hosted or private runners—or both, with centralized visibility across pipeline status, te…”
   • [claimed-docs] “Control permissions at the workspace, project, or repo level, and define granular branch‑level, environment‑level, and package permissions —…”
   • [community] “It appears that in bitbucket enterprise cloud, there is no way for an administrator to prevent members of my team from making repositories p…”

   proof ↗⚑ flag

   Gitea~partialcommunity6/10

   Gitea provides building blocks for governance—Actions-based CI/CD (gitea-docs-2), permission management and ACLs (gitea-docs-7), and PR-based code review workflows (gitea-docs-3)—plus API/webhooks for custom policy automation (gitea-docs-4). However, there's no direct evidence of org-wide branch protection templates, mandatory status-check enforcement across all repos, or centralized policy dashboards that a devops-lead would use to enforce standards uniformly; community feedback also notes scaling pain points once organizations grow (gitea-comm-13, gitea-comm-15). Missing for 10: explicit branch-protection/required-checks documentation, organization-wide policy templates, and independent evidence of successful multi-team governance enforcement.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”
   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [community] “Gitea is fine for a one-man show or small company, but once you scale up you start hitting various issues and wish for GitHub again.”
   • [community] “At a startup using self-hosted Gitea without dedicated DevOps required extra maintenance; during SOC-2 audits it was much easier to justify …”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Gitea
   Bitbucket—none0/10

   No evidence describes Bitbucket's REST API coverage or parity with UI features; probes show missing OpenAPI/docs endpoints, and no documentation claims full API-UI parity.

   • [probe] “PROBE llms.txt: HTTP 404 at https://support.atlassian.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”

   proof ↗⚑ flag

   Gitea~partialprobed4/10

   Gitea is documented as having a general-purpose API and webhooks for custom workflows (gitea-docs-4), and community evidence shows some UI-equivalent actions (e.g., creating a private repo purely via git push) work outside the UI (gitea-comm-10). However, there is no evidence of a comprehensive, discoverable API spec (openapi/swagger probes 404'd) or explicit documentation confirming parity across all UI features (Actions, Packages, Issues, etc.). Missing for 10: a published OpenAPI/swagger reference, explicit parity claims/documentation, and evidence that CI/CD, package management, and project boards are fully API-accessible.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [community] “You can create a private repo without using the UI/CLI just by adding a git remote and pushing—Gitea auto-creates it as private.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.gitea.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.gitea.com/openapi.json, https://docs.gitea.com/swagger.json, https://docs.gitea.com/api…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Gitea
   Bitbucket—none0/10

   No evidence of any data export/portability feature or open-format export capability for Bitbucket repos/issues; probes even show missing docs/API endpoints. Since git repos are inherently portable, this axis is fair for a code-hosting product, but nothing in the evidence pack confirms an explicit export-and-leave capability.

   • [probe] “PROBE llms.txt: HTTP 404 at https://support.atlassian.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://support.atlassian.com/bitbucket-cloud.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://support.atlassian.com/openapi.json, https://support.atlassian.com/swagger.json, https://supp…”

   proof ↗⚑ flag

   Gitea~partialcommunity4/10

   As self-hosted, open-source software, Gitea inherently stores data in open git format and gives full server access, which supports 'exporting and leaving,' and it exposes an API for programmatic extraction (gitea-docs-4). However, there is no explicit documented data-export/portability feature, and community reports specifically flag that Gitea's backup-and-restore mechanism is not good and that importing/migrating repos was surprisingly difficult, undercutting confidence in a clean full data exit. Missing for 10: explicit documented full-instance export tool, verified backup/restore reliability, and independent confirmation of smooth migration away from Gitea.

   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”
   • [community] “Complaint about Gitea's backup and restore mechanism reportedly still not being good, cited as a blocker for migrating from Gogs.”
   • [community] “Last time I tried Gitea, migrating existing git repos into it was surprisingly difficult.”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Gitea
   Bitbucket~partialclaimed4/10

   Evidence indicates Bitbucket Data Center/Server exists as a self-hosted deployment option (docs mention migrating code from 'Bitbucket Server or Data Center' to Cloud and trialing Cloud 'for the same user count as your Bitbucket Data Center license'), confirming self-hosting is possible, but no documentation describes setup, feature parity, or AI-native workflows for the self-hosted version. Missing for 10: dedicated self-host installation docs, feature parity details for Data Center, and any independent/hands-on confirmation of self-hosting the core product.

   • [claimed-docs] “Our free app moves your code and users from Bitbucket Server or Data Center to Cloud.”
   • [claimed-docs] “Sign up for a free Bitbucket Cloud Premium trial for the same user count and duration as your Bitbucket Data Center license.”

   proof ↗⚑ flag

   Gitea✓fullcommunity9/10

   Gitea is explicitly designed for self-hosting, with docs confirming easy deployment across OS/architectures (Linux, Windows, macOS, FreeBSD, Kubernetes, x86/arm64) without complex dependencies, and this is heavily corroborated by numerous independent hands-on community reports of running Gitea in production (single binary, Docker, low RAM footprint, VPS deployments, migrations from GitLab/Gogs) across small teams and personal projects. Missing for 10: some community reports note documentation gaps, backup/restore weaknesses, and scaling friction that mildly complicate the self-hosting story at larger scale.

   • [claimed-docs] “It can be easily deployed on various servers without complex configurations or dependencies.”
   • [claimed-docs] “Universally compatible with diverse operating systems and environments, including Linux, Windows, macOS, FreeBSD, and Kubernetes. Compatible…”
   • [community] “Used Gitea to deploy a Git server for 8 users; much simpler than a full Gitlab instance, just one binary to run, and users found the GitHub-…”
   • [community] “Used Gitea (previously Gogs) for a team of 45; setup with Docker was smooth and worked easily with Certbot, but documentation is lacking (ha…”
   • [community] “Put Gitea on a $5 VPS for personal projects; works great, though unsure how secure it is if exposed publicly (uses SSH port-forwarding inste…”
   • [community] “Using Gitea + Drone for several years: stable, fast, and doesn't consume a lot of RAM.”
   • [community] “Migrated from self-hosted Gitlab to Gitea, Nexus and Drone because maintaining Gitlab's size/complexity was too cumbersome; Gitea's UI is a …”
   • [community] “Gitea performs well even on slow, low-resource computers (e.g. Atom x7-E3950 with 16GB RAM), unlike Gitlab which struggles on the same hardw…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Gitea
   Bitbucket—none0/10

   No evidence pack items mention data residency, region selection, or geographic storage controls for Bitbucket; only generic security features like 2FA, IP allowlisting, and encryption are documented.

   ⚑ flag

   Gitea✓fullcommunity7/10

   Gitea is self-hosted software deployable on any server, OS, or cloud region a user chooses (Linux/Windows/macOS/FreeBSD/Kubernetes, easy deployment without complex config), which inherently gives full control over where data resides; community evidence confirms real-world self-hosting on VPS, Docker, and on-prem hardware. Missing for 10: explicit documentation addressing data residency/compliance framing (e.g., GDPR region controls) or multi-region replication features beyond generic self-host deployability.

   • [claimed-docs] “It can be easily deployed on various servers without complex configurations or dependencies.”
   • [claimed-docs] “Universally compatible with diverse operating systems and environments, including Linux, Windows, macOS, FreeBSD, and Kubernetes. Compatible…”
   • [community] “Used Gitea to deploy a Git server for 8 users; much simpler than a full Gitlab instance, just one binary to run, and users found the GitHub-…”
   • [community] “Put Gitea on a $5 VPS for personal projects; works great, though unsure how secure it is if exposed publicly (uses SSH port-forwarding inste…”
   • [community] “Migrated from self-hosted Gitlab to Gitea, Nexus and Drone because maintaining Gitlab's size/complexity was too cumbersome; Gitea's UI is a …”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round to Gitea
   Bitbucket—none0/10

   No evidence in the pack addresses data usage for AI model training, opt-out controls, or privacy commitments regarding Bitbucket/Rovo AI features; the pack only covers unrelated product features and community UX complaints.

   ⚑ flag

   Gitea~partialclaimed4/10

   Gitea is self-hosted software (deployable on your own servers, docs-9/docs-10), which inherently means no vendor cloud service ingests your repository data for AI training since Gitea itself doesn't host your data. However, there is no explicit privacy policy, documentation, or setting addressing AI/ML training data usage, nor any statement about third-party AI integrations respecting this. missing for 10: explicit documentation or policy on AI training data usage, any built-in opt-out/control mechanism, confirmation that bundled features (e.g. any AI-assisted tooling) don't train on repo data.

   • [claimed-docs] “It can be easily deployed on various servers without complex configurations or dependencies.”
   • [claimed-docs] “Universally compatible with diverse operating systems and environments, including Linux, Windows, macOS, FreeBSD, and Kubernetes. Compatible…”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Gitea
   Bitbucket—none0/10

   No evidence in the pack addresses AI data retention/deletion controls specific to Bitbucket's AI features (Rovo, AI code reviewer); only generic security/permission features are mentioned, none about data retention or deletion policies for AI-processed data.

   ⚑ flag

   Gitea~partialclaimed3/10

   Gitea being self-hosted implies the operator controls their own data and infrastructure, and gitea-docs-7 mentions access control and security features, but no evidence explicitly documents data retention policies, repository/account deletion mechanisms, or audit-log retention controls. missing for 10: explicit documentation of data deletion/export features, retention policy settings, GDPR-style data controls.

   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”
   • [claimed-docs] “It can be easily deployed on various servers without complex configurations or dependencies.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Bitbucket—none0/10

   No evidence pack item addresses telemetry opt-out or usage-tracking controls for Bitbucket; all docs focus on unrelated CI/CD, AI code review, and permissions features.

   ⚑ flag

   Gitea—none0/10

   The evidence pack contains no mention of telemetry, usage tracking, or an opt-out setting for Gitea; while self-hosted software could plausibly include such tracking, none is documented here.

   ⚑ flag

External pm sync

1. developerManage external issue tracker items directly within the code hosting UI

   weight 1 · round to Bitbucket
   Bitbucket✓fullclaimed8/10

   Bitbucket docs claim a built-in Jira UI for managing Jira issues directly within Bitbucket, plus opening Jira tickets from the PR screen and automatic status updates via commit issue keys, directly supporting external issue tracker management in the code hosting UI. Missing for 10: independent/hands-on corroboration of this specific Jira UI feature and detail on its scope/limitations.

   • [claimed-docs] “Reduce context-switching by managing your Jira issues in Bitbucket with the built-in Jira UI”
   • [claimed-docs] “when you include your issue key in commits, your Jira issue statuses update automatically”
   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea—none0/10

   Evidence covers Gitea's native issue tracker, PR review, webhooks/API, and integrations with chat tools, but there is no mention of any capability to sync, link, or manage external issue trackers (e.g. Jira) within the Gitea UI.

   ⚑ flag

2. developerAutomatically update linked issue tracker statuses by referencing issue keys in my commits

   weight 2 · round to Bitbucket
   Bitbucket✓fullclaimed7/10

   Bitbucket docs directly state that including a Jira issue key in commits automatically updates the linked Jira issue's status, and Bitbucket's Jira integration also allows opening/viewing tickets from PR screens. missing for 10: independent/hands-on corroboration of the auto-transition behavior and details on configuration (e.g., required smart commit syntax or workflow mapping).

   • [claimed-docs] “when you include your issue key in commits, your Jira issue statuses update automatically”
   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea—none0/10

   The evidence pack confirms Gitea's issue tracking capabilities (branches, tags, milestones, dependencies) but contains no documentation or community report of automatically closing/updating issue status via commit message keywords (e.g., 'fixes #123'), which is the specific capability the story asks about.

   ⚑ flag

Issue tracking

1. developerTrack requirements, features, and bugs using issues with milestones, time tracking, and dependencies

   weight 3 · round to Gitea
   Bitbucket~partialclaimed4/10

   Bitbucket docs mention Jira issue integration (auto status updates on commit, built-in Jira UI in Bitbucket, opening Jira tickets from PRs) which covers basic issue tracking, but this relies entirely on a separate Jira product rather than native Bitbucket issue features, and there is no mention of milestones, time tracking, or dependency tracking anywhere in the evidence. missing for 10: native milestone support, time tracking, dependency linking, and evidence these work without requiring a separate Jira subscription.

   • [claimed-docs] “when you include your issue key in commits, your Jira issue statuses update automatically”
   • [claimed-docs] “Reduce context-switching by managing your Jira issues in Bitbucket with the built-in Jira UI”
   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea✓fullclaimed8/10

   gitea-docs-6 directly confirms issues with milestones, time tracking, due dates, and dependencies for tracking requirements/features/bugs, matching the story closely. Missing for 10: independent hands-on corroboration of these specific project-planning features (community evidence focuses on performance/resource usage, not issue tracking depth).

   • [claimed-docs] “Gitea tracks project requirements, features, and bugs through columns and issues. Issues support features like branches, tags, milestones, a…”

   proof ↗⚑ flag

2. developerManage projects and assign tasks from my mobile device

   weight 1 · round drawn
   Bitbucket—none0/10

   No evidence describes a Bitbucket mobile app or mobile-optimized interface for managing projects or assigning tasks; docs focus on Jira integration, CI/CD, and code review, none of which mention mobile access.

   ⚑ flag

   Gitea—none0/10

   Evidence confirms Gitea has project/task tracking via issues, columns, assignments, milestones (gitea-docs-6), but there is no evidence of a mobile app, mobile-optimized web UI, or any mobile-specific access path for managing projects or assigning tasks.

   • [claimed-docs] “Gitea tracks project requirements, features, and bugs through columns and issues. Issues support features like branches, tags, milestones, a…”

   proof ↗⚑ flag

3. developerOrganize work from high-level roadmaps to everyday tasks using project boards

   weight 2 · round to Gitea
   Bitbucket—none0/10

   No evidence in the pack mentions project boards, roadmaps, backlogs, or task/kanban planning views for Bitbucket itself; only Jira integration for issue status updates is mentioned, which is a separate product. This applicable planning axis has no supporting evidence.

   ⚑ flag

   Gitea~partialclaimed5/10

   Docs confirm Gitea has kanban-style project boards with columns/issues supporting milestones, due dates, dependencies, and time tracking, which covers day-to-day task organization, but there's no evidence of higher-level roadmap features (e.g., cross-repo project views, roadmap timelines) or any community validation of using boards for roadmap planning. Missing for 10: evidence of roadmap/timeline views, cross-project or organization-level board hierarchy, and independent/hands-on confirmation of the project board feature in practice.

   • [claimed-docs] “Gitea tracks project requirements, features, and bugs through columns and issues. Issues support features like branches, tags, milestones, a…”

   proof ↗⚑ flag

Code review

1. ai-native userHave an AI reviewer analyze code changes and suggest fixes during review

   weight 2 · round to Bitbucket
   Bitbucket~partialclaimed6/10

   Bitbucket's own docs explicitly claim an AI code reviewer that reviews changes and suggests fixes (bitbucket-docs-3), directly matching the story, and code review features are documented alongside it (bitbucket-docs-11). However, there is no independent/hands-on evidence corroborating this AI reviewer's real-world behavior or quality, and no detail on how suggestions are surfaced during PR review. missing for 10: independent/hands-on verification of the AI reviewer's accuracy and workflow, detailed documentation of the suggestion/fix mechanism.

   • [claimed-docs] “Our AI code reviewer reviews all code changes and suggests fixes so you can merge faster.”
   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of any AI code reviewer or automated fix-suggestion capability; docs mention only human PR review, webhooks, API, and Actions CI, none of which constitute an AI reviewer feature.

   ⚑ flag

2. ai-native userAssign the initial code review of a pull request to an AI reviewer for faster turnaround

   weight 2 · round to Bitbucket
   Bitbucket~partialclaimed5/10

   Bitbucket docs claim an AI code reviewer that reviews all code changes and suggests fixes to speed merges, which addresses the core idea of AI-driven review turnaround, but there is no evidence describing an explicit 'assign as reviewer on a PR' workflow, configurability, or independent/hands-on confirmation of this feature working. missing for 10: evidence of assigning AI as a designated PR reviewer, setup/configuration details, and independent corroboration of real-world use.

   • [claimed-docs] “Our AI code reviewer reviews all code changes and suggests fixes so you can merge faster.”
   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence Gitea supports assigning AI reviewers or automated AI-based PR review; docs only mention human reviewer workflows (PR/AGit review, comments) and general API/webhook extensibility, with no AI reviewer integration or feature documented.

   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [claimed-docs] “Extend Gitea's functionality with our API and webhooks, creating custom workflows to match your unique needs.”

   proof ↗⚑ flag

3. developerReview code changes online and respond to inline review comments

   weight 3 · round drawn
   Bitbucket~partialclaimed6/10

   Bitbucket's docs claim comprehensive PR code review features including reviewing diffs and commenting from the PR screen (bitbucket-docs-11), which implies inline review comments are supported, but no evidence explicitly confirms responding/threading on inline comments, and community feedback focuses on unrelated UI/browsing complaints rather than confirming this specific workflow. missing for 10: explicit documentation or hands-on evidence of inline comment threads/replies, independent corroboration of the review-comment workflow.

   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea~partialclaimed6/10

   Gitea docs explicitly confirm PR-based code review with online code browsing and inline review comments/feedback (gitea-docs-3), backed by broader repo/collaboration docs (gitea-docs-1). However, there's no independent/hands-on evidence specifically validating the inline comment reply/thread experience, and community evidence focuses on other aspects (performance, deployment) rather than review UX quality. Missing for 10: independent corroboration of inline comment threading/resolution workflow, detail on review approval states, and hands-on account of the review UI experience.

   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [claimed-docs] “Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing …”

   proof ↗⚑ flag

4. developerReview large diffs and view third-party code quality reports directly in the review screen

   weight 2 · round to Bitbucket
   Bitbucket✓fullclaimed8/10

   Bitbucket docs explicitly state the product lets developers 'Review large diffs with ease, view third-party code reports, and open Jira tickets right from the PR screen,' directly matching the story. Missing for 10: independent/hands-on corroboration of this specific feature (community evidence discusses other UI aspects but not this capability).

   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea~partialclaimed3/10

   Gitea's docs confirm online code review with PR/AGit workflows and inline comments (diff review), but there is no evidence of built-in or first-party support for displaying third-party code quality reports (e.g., linting/coverage/security scan annotations) directly in the review screen. Missing for 10: documentation of large-diff handling/optimizations, and any integration surfacing third-party code quality report annotations in the PR diff view.

   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [claimed-docs] “Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing …”

   proof ↗⚑ flag

5. devops-leadEnforce standardized, customizable merge checks before code can be merged

   weight 2 · round to Bitbucket
   Bitbucket✓fullclaimed8/10

   Bitbucket docs explicitly state support for 'standardized, customizable merge checks' to enforce code quality, compliance, and CI/CD policies across teams and repos, backed by branch-level permission controls. Missing for 10: independent/hands-on corroboration of merge-check configuration in practice and detail on granularity of check types beyond marketing copy.

   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”
   • [claimed-docs] “Control permissions at the workspace, project, or repo level, and define granular branch‑level, environment‑level, and package permissions —…”

   proof ↗⚑ flag

   Gitea~partialclaimed4/10

   Gitea's docs show pull-request based code review, CI/CD via Actions, and permission/ACL controls—building blocks for merge gating—but the evidence pack never mentions explicit branch-protection rules, required status checks, or required-approval enforcement that would let a devops-lead standardize and customize merge checks. Missing for 10: explicit branch protection/required status check documentation, evidence of enforceable required reviewers before merge, and independent confirmation these gates actually block merges in practice.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”

   proof ↗⚑ flag

Package registry

1. open-source-maintainerPublish and consume software packages in multiple package formats from the same platform

   weight 2 · round to Gitea
   Bitbucket—none0/10

   No evidence in the pack mentions a package registry or multi-format package management capability (e.g., npm, Maven, Docker, PyPI) in Bitbucket; docs only reference container image/tag permissions in passing without describing a package publishing feature. Missing for 10: any documentation of a package registry, supported package formats, or publish/consume workflows.

   ⚑ flag

   Gitea✓fullclaimed8/10

   Gitea's docs explicitly state built-in package registry support for over 20 formats (Cargo, npm, Maven, PyPI, Container, Helm, NuGet, RubyGems, etc.) hosted natively on the same platform as repos, PRs, and issues, enabling maintainers to publish/consume packages without a separate tool. missing for 10: no independent/hands-on community confirmation of the package registry feature in the evidence pack, and no detail on publish/consume workflow specifics.

   • [claimed-docs] “Gitea supports over 20 different types of public or private software package management, including Cargo, Chef, Composer, Conan, Conda, Cont…”

   proof ↗⚑ flag

Repo management

1. devops-leadControl granular access permissions at the workspace, project, repository, and branch level

   weight 2 · round to Bitbucket
   Bitbucket✓fullcommunity8/10

   First-party docs explicitly state control over permissions at workspace, project, repo, and granular branch/environment/package levels (bitbucket-docs-9), directly matching the story, and is reinforced by broader policy/compliance enforcement claims (bitbucket-docs-6, bitbucket-docs-7). Missing for 10: independent hands-on corroboration of granular branch-level permission enforcement, and one community note (bitbucket-comm-19) suggests admins lack full control over repo visibility, indicating some gaps in enterprise-wide permission enforcement.

   • [claimed-docs] “Control permissions at the workspace, project, or repo level, and define granular branch‑level, environment‑level, and package permissions —…”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”
   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”
   • [community] “It appears that in bitbucket enterprise cloud, there is no way for an administrator to prevent members of my team from making repositories p…”

   proof ↗⚑ flag

   Gitea~partialclaimed5/10

   Gitea docs mention repository/collaborator management, user permission management, and access control lists, implying repo- and branch-level access control is possible, but there's no explicit documentation of workspace/project-level granular permission hierarchies or branch protection rules in the evidence pack. missing for 10: explicit docs on organization/team permission scoping, branch protection rule configuration, and any independent verification of granular access control working as described.

   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”
   • [claimed-docs] “Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing …”

   proof ↗⚑ flag

2. developerSearch across repositories to find code, files, and commits

   weight 2 · round drawn
   Bitbucket—none0/10

   No vendor documentation in the evidence pack describes a code/commit search feature, and community reports explicitly state Bitbucket lacks a search feature ('there isn't even a search feature, let alone browse capability' and 'no search feature by language'), so there is no evidence the story is delivered.

   • [community] “So how do I browse projects hosted on BitBucket? No search feature by language, no Explore feature like GitHub - can't test drive before sig…”
   • [community] “I love bitbucket but I would like to be able to create clusters of related projects by language/tool. Right now there isn't even a search fe…”

   proof ↗⚑ flag

   Gitea—none0/10

   The evidence pack covers repo creation, commit browsing, code review, packages, issues, and security, but no citation explicitly documents a code/file/commit search feature across repositories. Missing for 10: any documentation or community mention of a search function, its scope (code/file/commit), or its limitations.

   ⚑ flag

3. developerCreate and manage Git repositories and browse their commit history

   weight 3 · round to Gitea
   Bitbucket✓fullcommunity6/10

   Bitbucket is fundamentally a Git hosting platform, and community evidence confirms core repo hosting and commit-history browsing (praised commits view with graph, per-repo deploy keys, Mercurial repo hosting) even though some users criticize the web browsing UX and lack of a project explore/search feature. Missing for 10: first-party docs explicitly describing repo creation/management workflow, and resolution of complaints about slow/painful source browsing and missing cross-project browse/search.

   • [community] “The redesigned commits view is 100 times better than Github's ever was - so much more info, and even a graph like in gitx.”
   • [community] “As a daily Bitbucket user, browsing source code via web is painful and slow compared to Github's slicker UI with tree slider navigation.”
   • [community] “So how do I browse projects hosted on BitBucket? No search feature by language, no Explore feature like GitHub - can't test drive before sig…”
   • [community] “I love bitbucket but I would like to be able to create clusters of related projects by language/tool. Right now there isn't even a search fe…”
   • [community] “Bitbucket's deploy key is read-only and can be attached to multiple repos, unlike Github's which is read-write and single-repo only - a much…”
   • [community] “This is disappointing. Bitbucket is the premier place to host free private mercurial repos - there is literally not a single other place for…”

   proof ↗⚑ flag

   Gitea✓fullcommunity9/10

   Gitea's core purpose is Git repo hosting with commit history browsing, code review, and branch management, confirmed by first-party docs and corroborated by extensive hands-on community use (self-hosting for teams, private repo creation, browsing). One minor gap noted by a hands-on report: browsing commit history/Activity on large repos can be slow due to lack of caching. missing for 10: independent benchmark confirming commit history browsing performance at scale, deeper detail on repo creation workflow.

   • [claimed-docs] “Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing …”
   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [community] “Used Gitea to deploy a Git server for 8 users; much simpler than a full Gitlab instance, just one binary to run, and users found the GitHub-…”
   • [community] “You can create a private repo without using the UI/CLI just by adding a git remote and pushing—Gitea auto-creates it as private.”
   • [community] “Used the 'Try Gitea' service to load a large repo's Activity tab for a 1-year period; page load took nearly 90 seconds with no caching, sugg…”

   proof ↗⚑ flag

4. developerPropose, discuss, and merge code changes using a pull or merge request workflow

   weight 3 · round to Gitea
   Bitbucket✓fullclaimed7/10

   Bitbucket docs confirm comprehensive PR/code review features (opening PRs, reviewing diffs, merge checks, opening Jira tickets from PR screen) which directly support the propose/discuss/merge workflow. missing for 10: independent hands-on corroboration of the actual PR discussion/merge UX (community evidence focuses on repo browsing, pricing, and UI gripes rather than PR workflow specifics), and no detail on review comment threading or approval mechanics.

   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”
   • [claimed-docs] “Enforce code quality policies and compliance requirements across the organization with standardized, customizable merge checks.”
   • [claimed-docs] “Be confident in your software delivery by enforcing coding standards, CI/CD policies, and change management workflows across all teams and r…”

   proof ↗⚑ flag

   Gitea✓fullclaimed8/10

   Gitea docs explicitly describe pull request workflow with code review, comments, and AGit workflow support, alongside repo management and merging (gitea-docs-1, gitea-docs-3). Community evidence corroborates real-world usage of Gitea as a git hosting platform for collaboration. Missing for 10: independent hands-on account specifically describing PR review/merge experience (most community evidence focuses on resource usage/ops rather than PR workflow specifics).

   • [claimed-docs] “Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing …”
   • [claimed-docs] “Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedb…”
   • [claimed-docs] “Gitea tracks project requirements, features, and bugs through columns and issues. Issues support features like branches, tags, milestones, a…”

   proof ↗⚑ flag

Access security

1. devops-leadRestrict repository access to specific IP address ranges

   weight 2 · round to Bitbucket
   Bitbucket✓fullclaimed7/10

   Bitbucket docs explicitly state IP allowlisting is a security feature to restrict code access to authorized users, directly matching the story. Missing for 10: detailed documentation on granularity (per-repo vs workspace-wide IP ranges), independent/hands-on confirmation, and enterprise-tier limitations.

   • [claimed-docs] “2FA and IP allowlisting keep your code accessible only by authorized users. All code is encrypted in transit and at rest.”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of IP allow/deny-listing or CIDR-based repository access restriction; docs mention only user permission management and access control lists generically, without any IP-based restriction feature documented or discussed in community threads.

   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”

   proof ↗⚑ flag

2. developerGenerate and manage personal access tokens for authenticating to the platform

   weight 2 · round drawn
   Bitbucket—none0/10

   No evidence pack items mention personal access tokens or app passwords for authentication; only 2FA and IP allowlisting are cited, which do not address PAT generation/management. Missing for 10: any documentation or mention of personal access tokens, app passwords, or token scopes/lifecycle management.

   ⚑ flag

   Gitea—none0/10

   The evidence pack mentions general security/access-control features (gitea-docs-7) and API/webhook extensibility (gitea-docs-4) but never specifically describes personal access token generation or management. Missing for 10: explicit documentation or community confirmation of PAT creation/management UI or API endpoints.

   ⚑ flag

3. developerSet up SSH keys to authenticate and connect securely to the platform

   weight 2 · round drawn
   Bitbucket—none0/10

   The evidence pack contains no first-party documentation describing SSH key setup or authentication for Bitbucket; the only relevant reference is a community complaint (bitbucket-comm-4) describing repeated authentication failures despite adding an SSH key, which does not establish that the feature works as expected. Without any vendor documentation or successful hands-on confirmation, there is no evidence the capability is delivered.

   • [community] “I have to authenticate every time I push to the repo despite adding my SSH key; can't find equivalent to github.user/github.token config for…”

   proof ↗⚑ flag

   Gitea—none0/10

   The evidence pack contains no documentation or community confirmation of Gitea's SSH key management/authentication feature; only a tangential community mention of using SSH port-forwarding (not key setup) appears. Missing for 10: any docs on adding/generating SSH keys, key-based git push/pull authentication, or admin-side SSH config.

   ⚑ flag

4. developerSecure my account with two-factor authentication

   weight 3 · round to Bitbucket
   Bitbucket✓fullclaimed7/10

   Bitbucket docs explicitly state '2FA and IP allowlisting keep your code accessible only by authorized users,' confirming native two-factor authentication support for account security. Missing for 10: no independent/hands-on corroboration of the 2FA setup flow or details on supported methods (e.g., TOTP, SMS, hardware keys).

   • [claimed-docs] “2FA and IP allowlisting keep your code accessible only by authorized users. All code is encrypted in transit and at rest.”

   proof ↗⚑ flag

   Gitea—none0/10

   The evidence pack mentions general security features (permissions, access control lists) but never specifically mentions two-factor authentication, TOTP, or U2F support, so there's no evidence this capability is documented.

   ⚑ flag

Vulnerability scanning

1. ai-native userHave AI automatically generate and apply fixes for detected security vulnerabilities

   weight 2 · round to Bitbucket
   Bitbucket~partialclaimed4/10

   Bitbucket integrates Snyk for automatic security scanning and has an AI code reviewer that 'suggests fixes' for code changes, plus AI-powered pipeline workflows that can automate fixes for some issues, but there is no evidence of AI automatically generating and applying patches specifically for detected security vulnerabilities. Missing for 10: explicit documentation of AI auto-remediation tied to Snyk/security scan findings, evidence of automatic PR creation/application of security fixes, and independent confirmation this works hands-on.

   • [claimed-docs] “Our AI code reviewer reviews all code changes and suggests fixes so you can merge faster.”
   • [claimed-docs] “Trigger AI-powered workflows to automate tedious tasks: clean up feature flags, update docs, draft release notes, fix flaky tests, and more …”
   • [claimed-docs] “Run automatic security scans with out-of-the-box integration with Snyk, or connect to other providers. Simply open an existing repository or…”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of any AI-driven vulnerability detection or automated fix generation/application in Gitea; it offers permission management and ACLs but no security scanning or AI remediation features are documented.

   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”

   proof ↗⚑ flag

2. developerAutomatically receive pull requests that update vulnerable dependencies

   weight 3 · round drawn
   Bitbucket—none0/10

   Evidence only shows Bitbucket offers security scanning via a Snyk integration (bitbucket-docs-12), but there is no mention of automatically generated pull requests to update vulnerable dependencies (a Dependabot-like feature). Missing for full credit: any documentation of automated dependency-update PR creation, PR scheduling/frequency settings, or dependency graph triggers.

   • [claimed-docs] “Run automatic security scans with out-of-the-box integration with Snyk, or connect to other providers. Simply open an existing repository or…”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of a Dependabot-like automated dependency-vulnerability scanning/update feature that opens pull requests; Gitea's evidence covers package registry hosting, CI/CD via Actions, and code review, but nothing about automated dependency vulnerability detection or auto-generated PRs to bump vulnerable dependencies.

   ⚑ flag

3. devops-leadConsolidate static analysis, dependency, secret, and dynamic security scanning into one platform

   weight 3 · round to Bitbucket
   Bitbucket~partialclaimed4/10

   Bitbucket documents an out-of-the-box Snyk integration for automatic security scans and mentions viewing third-party code reports in PRs, but this is a single third-party integration rather than a native unified platform combining static analysis, dependency, secret, and dynamic scanning. Missing for 10: native SAST/secret/DAST scanning tools, evidence of a single consolidated security dashboard, and independent confirmation the integration covers all four scan types.

   • [claimed-docs] “Run automatic security scans with out-of-the-box integration with Snyk, or connect to other providers. Simply open an existing repository or…”
   • [claimed-docs] “Comprehensive code review features to help you find and fix bugs before you deploy. Review large diffs with ease, view third-party code repo…”

   proof ↗⚑ flag

   Gitea—none0/10

   Gitea's evidence covers repo hosting, CI/CD via Actions, code review, packages, and access control, but there is no mention of built-in SAST, dependency/SCA scanning, secret scanning, or DAST features, and community evidence explicitly notes Gitea 'deliberately stays focused on git hosting rather than bundling CI/chat like Gitlab' (gitea-comm-5), implying it does not bundle a security scanning suite like GitLab's.

   • [claimed-docs] “Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a va…”
   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”
   • [community] “Gitea kept OAuth2 support that Gogs dropped, and has more useful features than Gogs overall, but Gitea deliberately stays focused on git hos…”

   proof ↗⚑ flag

4. devops-leadDetect and remediate leaked secrets across the organization's repositories

   weight 2 · round drawn
   Bitbucket—none0/10

   The evidence only mentions generic security scanning via Snyk integration and general permission/2FA controls, with no specific mention of secret detection, leaked credential scanning, or organization-wide remediation workflows. Missing for 10: any documentation of secret-scanning capability, push-protection, or remediation workflow for leaked credentials.

   • [claimed-docs] “Run automatic security scans with out-of-the-box integration with Snyk, or connect to other providers. Simply open an existing repository or…”
   • [claimed-docs] “2FA and IP allowlisting keep your code accessible only by authorized users. All code is encrypted in transit and at rest.”

   proof ↗⚑ flag

   Gitea—none0/10

   No evidence of any secret-scanning, credential-detection, or leaked-secret remediation feature across repositories in Gitea's docs or community reports; only general permission/access-control security mentions (gitea-docs-7) which do not address secret detection.

   • [claimed-docs] “Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure t…”

   proof ↗⚑ flag

Deployment options

1. devops-leadRun my self-hosted instance on my choice of operating system and architecture, including containers

   weight 2 · round to Gitea
   Bitbucket—none0/10

   Evidence confirms a self-hosted Bitbucket Data Center product exists (migration tooling, DC license trials) but contains no documentation of supported operating systems, CPU architectures, or containerized/Docker deployment options.

   • [claimed-docs] “Our free app moves your code and users from Bitbucket Server or Data Center to Cloud.”
   • [claimed-docs] “Sign up for a free Bitbucket Cloud Premium trial for the same user count and duration as your Bitbucket Data Center license.”

   proof ↗⚑ flag

   Gitea✓fullcommunity9/10

   Gitea docs explicitly state cross-platform support for Linux, Windows, macOS, FreeBSD, and Kubernetes, plus multiple architectures (x86, arm64), and easy deployment without complex dependencies. Community evidence corroborates real-world Docker deployments and single-binary installs across varied low-resource hardware, confirming this in practice. missing for 10: independent verification of Windows/macOS/FreeBSD production usage beyond docs (community reports focus mostly on Linux/Docker deployments).

   • [claimed-docs] “It can be easily deployed on various servers without complex configurations or dependencies.”
   • [claimed-docs] “Universally compatible with diverse operating systems and environments, including Linux, Windows, macOS, FreeBSD, and Kubernetes. Compatible…”
   • [community] “Used Gitea to deploy a Git server for 8 users; much simpler than a full Gitlab instance, just one binary to run, and users found the GitHub-…”
   • [community] “Used Gitea (previously Gogs) for a team of 45; setup with Docker was smooth and worked easily with Certbot, but documentation is lacking (ha…”
   • [community] “Gitea performs well even on slow, low-resource computers (e.g. Atom x7-E3950 with 16GB RAM), unlike Gitlab which struggles on the same hardw…”

   proof ↗⚑ flag

2. devops-leadScale my self-hosted installation using reference architectures supporting tens of thousands of users

   weight 2 · round drawn
   Bitbucket—none0/10

   No evidence of Bitbucket Data Center reference architectures, scaling benchmarks, or documentation for supporting tens of thousands of users; evidence only covers Cloud migration and generic feature descriptions.

   ⚑ flag

   Gitea—none0/10

   No evidence in the pack of official reference architectures, HA/clustering guidance, or documented deployments supporting tens of thousands of users; community reports instead note performance issues at scale (slow Activity tab, wishing for GitHub 'once you scale up') rather than confirming large-scale reference architectures.

   • [community] “Used the 'Try Gitea' service to load a large repo's Activity tab for a 1-year period; page load took nearly 90 seconds with no caching, sugg…”
   • [community] “Gitea is fine for a one-man show or small company, but once you scale up you start hitting various issues and wish for GitHub again.”
   • [community] “At a startup using self-hosted Gitea without dedicated DevOps required extra maintenance; during SOC-2 audits it was much easier to justify …”

   proof ↗⚑ flag

3. devops-leadUse migration tooling to move my code and users from another platform or from self-hosted to cloud

   weight 2 · round to Bitbucket
   Bitbucket✓fullclaimed7/10

   Bitbucket documents a free migration app to move code and users from Bitbucket Server/Data Center to Cloud, plus a Cloud Premium trial matching Data Center license user count/duration to ease migration. This directly addresses moving from self-hosted to cloud, though evidence is limited to first-party claims with no independent/hands-on corroboration and no mention of migrating from other platforms (e.g., GitHub/GitLab). Missing for 10: independent verification of the migration tool's reliability, and evidence of tooling for migrating from third-party platforms other than Bitbucket Server/Data Center.

   • [claimed-docs] “Our free app moves your code and users from Bitbucket Server or Data Center to Cloud.”
   • [claimed-docs] “Sign up for a free Bitbucket Cloud Premium trial for the same user count and duration as your Bitbucket Data Center license.”

   proof ↗⚑ flag

   Gitea—none0/10

   The evidence pack contains no vendor documentation describing dedicated migration tooling (e.g., importing from GitHub/GitLab/Bitbucket, bulk user import) for moving code and users from another platform or to a cloud instance. In fact, community reports directly contradict this capability: one user found migrating existing git repos into Gitea 'surprisingly difficult' [gitea-comm-16], and another cites Gitea's backup/restore mechanism as 'still not being good' and a blocker for migrating from Gogs [gitea-comm-20]. Missing for 10: any first-party migration/import documentation, evidence of successful cross-platform user/data migration, and independent confirmation the process works smoothly.

   • [community] “Last time I tried Gitea, migrating existing git repos into it was surprisingly difficult.”
   • [community] “Complaint about Gitea's backup and restore mechanism reportedly still not being good, cited as a blocker for migrating from Gogs.”

   proof ↗⚑ flag

4. devops-leadInstall a self-managed instance of the platform without laborious configuration

   weight 3 · round to Gitea
   Bitbucket—none0/10

   The evidence only mentions migrating from self-managed Bitbucket Server/Data Center to Cloud and trial licensing (bitbucket-docs-15, bitbucket-docs-16), but provides no documentation of an actual self-managed installation process, ease of setup, or reduced configuration effort. No evidence describes install steps, deployment tooling, or admin experience for a self-hosted instance.

   • [claimed-docs] “Our free app moves your code and users from Bitbucket Server or Data Center to Cloud.”
   • [claimed-docs] “Sign up for a free Bitbucket Cloud Premium trial for the same user count and duration as your Bitbucket Data Center license.”

   proof ↗⚑ flag

   Gitea✓fullcommunity8/10

   Docs claim easy deployment without complex configuration or dependencies, and multiple independent community reports corroborate simple single-binary/Docker setups, low resource needs, and successful small-to-mid scale deployments on limited hardware. Missing for 10: more detailed first-party install/config walkthrough evidence and resolution of community complaints about incomplete documentation.

   • [claimed-docs] “It can be easily deployed on various servers without complex configurations or dependencies.”
   • [claimed-docs] “Universally compatible with diverse operating systems and environments, including Linux, Windows, macOS, FreeBSD, and Kubernetes. Compatible…”
   • [community] “Used Gitea to deploy a Git server for 8 users; much simpler than a full Gitlab instance, just one binary to run, and users found the GitHub-…”
   • [community] “Used Gitea (previously Gogs) for a team of 45; setup with Docker was smooth and worked easily with Certbot, but documentation is lacking (ha…”
   • [community] “Gitea is massively less resource hungry than Gitlab; a Gitlab install using 4 cores/8GB RAM/2.3TB disk still had backup rake tasks trigger O…”
   • [community] “Using Gitea + Drone for several years: stable, fast, and doesn't consume a lot of RAM.”
   • [community] “Migrated from self-hosted Gitlab to Gitea, Nexus and Drone because maintaining Gitlab's size/complexity was too cumbersome; Gitea's UI is a …”
   • [community] “Gitea performs well even on slow, low-resource computers (e.g. Atom x7-E3950 with 16GB RAM), unlike Gitlab which struggles on the same hardw…”

   proof ↗⚑ flag