Rename to `ai-toolkit` and transfer to the Pipefy GitHub org

[gbrlcustodio]

Tracking issue for moving this repo from gbrlcustodio/pipefy-mcp-server to pipefy/ai-toolkit (org handle TBD). Rename + transfer should land in the same window to avoid two URL changes for consumers.

Pre-transfer

• Confirm target org handle and the owner who will accept the transfer
• Sign-off from Pipefy engineering / platform leadership
• Legal / brand review — README disclaimer ("not Pipefy's official integration") needs to come out; license headers updated to reflect org ownership

Transfer mechanics

• Rename pipefy-mcp-server → ai-toolkit
• Transfer ownership to the Pipefy org
• Reconfigure branch protection rules (not all settings carry over on transfer)
• Re-add Actions secrets / environment variables (don't transfer)
• Verify webhooks still resolve

Docs / code sweep

• README CI badge URL (currently gbrlcustodio/pipefy-mcp-server)
• README <owner>/pipefy-labs placeholders in install commands (4 spots) and feedback & issues link
• README release link (/releases/tag/v0.1.0-beta.1)
• Repo description on GitHub
• docs/ internal references
• pipefy-labs umbrella naming in README — keep, replace with "Pipefy AI Toolkit", or drop?
• Grep for any remaining hardcoded gbrlcustodio/pipefy-mcp-server references

Communication

• Notify open contributors before transfer (existing PRs follow automatically, but local remotes need refetching)
• CHANGELOG / release notes entry
• Update external surfaces (MCP registry listings, future PyPI project URLs, blog posts)

Open questions

• Repo rename ≠ package rename. The MCP package is pipefy-mcp-server and the CLI is pipefy-cli — both intentional consumer-facing names. Should they stay (recommended — renaming the package breaks every existing install script) or move to something like pipefy-ai-toolkit-mcp?
• Coincide with v1.0 + PyPI cutover, or do them as separate events?

[gbrlcustodio]

Pre-staged rename PR + transfer sequence

Opened #271 (draft) to handle the docs/code sweep half of this issue. It repoints every github.com / raw.githubusercontent.com owner-path reference to pipefy/ai-toolkit and removes the README disclaimer. Scope is URL paths only; distribution names (pipefy-mcp-server, pipefy-cli, etc.) are deliberately untouched per the open question below.

Why it's a draft, and the merge order. GitHub sets up redirects on rename/transfer, so nothing hard-404s the instant we transfer, but every pipefy/ai-toolkit URL is dead until the org and repo actually exist. Merging #271 before the transfer breaks install.sh, the CI badge, and the bootstrap curl. So:

1. Approve chore(140): repoint github URLs at pipefy/ai-toolkit #271 now, leave it unmerged.
2. Rename + transfer to the pipefy org.
3. Re-add Actions secrets, re-apply branch protection, re-verify webhooks (none of this carries over on transfer, and a PR can't do it).
4. Re-trigger checks on chore(140): repoint github URLs at pipefy/ai-toolkit #271 if branch protection gates on them, then merge.

What the PR does not cover (the actual stabilization risk): the operational mechanics in the "Transfer mechanics" checklist above. Those need a person with org-admin, not a merge.

Self-healing note. Once #260 lands, .mcp.json regenerates its wheel URLs from GITHUB_REPOSITORY on every release, so it self-heals post-transfer. On current main it's still the @latest git form, so #271 fixes it directly; if #260 merges first, drop #271's .mcp.json hunk at rebase.

Still open (not decided in #271):

• Distribution/package renames. Recommend keeping the existing names; renaming breaks every install script.
• The # pipefy-labs README umbrella heading (keep / rename to "Pipefy AI Toolkit" / drop).
• README disclaimer removal is in chore(140): repoint github URLs at pipefy/ai-toolkit #271 on the assumption the org transfer makes it official. If legal/brand wants to keep a disclaimer, flag before merge.