BafGo PortBafGo PortThe short version of how BafGo Port works: no accounts, no server, everything in your repo. The longer answers are below.
A governance layer between your tracker and your AI agents. It writes every requirement down as a rule, ties each rule to the code, tests, and demo that shipped it, and records who approved it. It is a command-line tool plus a .bafgo/ folder in your repo, not a hosted service.
There is nothing to log into because there is no central service. Everything lives in a .bafgo/ folder you commit to your own repo: rules and changes as YAML files, a hash-chained events.jsonl of what happened and when, a generated links.json trace, and a manifest.json of fingerprints. Your repo is the source of truth, and your git history is the audit trail.
Approvals are recorded, not inferred. bafgo approve CH-42 --by dana --reason "fixes the chime" writes the approver's name and reason into events.jsonl, right next to the code. Rejections and verifications are recorded the same way. Who did what, when, and why lives in the repo with the work itself. Add a key (bafgo keygen) and approvals are cryptographically signed, so the name is backed by proof.
No, not without leaving evidence. Each line in events.jsonl embeds the hash of the line before it, forming a chain that breaks if anything is reordered or backdated. manifest.json fingerprints every rule, change, and linked file. Run bafgo manifest --verify to replay the chain, the fingerprints, and any signatures, and confirm nothing drifted.
No. BafGo has no connectors. Your AI agent reads those tools with its own access, then records the work through the CLI with claim, link, and stage. BafGo keeps the trace; the reading is done by your agent with your own credentials.
A rule is one requirement written so it can be checked: a when clause and a then clause, or an exploratory track for design taste that a human judges on a demo. A change is one unit of work that touches one or more rules, moving from open to verified.
It runs the tests you linked to the rule or change. A rule only reaches verified when every linked test passes. A failing test prints its output and leaves the state exactly where it was.
No. Every command is plain text and every file is YAML, so you can draft, edit, link, and approve by hand. Agents make it faster; they are never required.
No. BafGo runs on your machine and writes only to your repo. When you use an AI assist to draft a rule, you bring your own model and your own keys. BafGo never holds, routes, or bills your usage.
Point the scope at the registry once: npm config set @bafgo:registry https://npm.bafgo.com/, then npm install -g @bafgo/cli. In a repo, bafgo init creates the .bafgo/ folder, and bafgo serve opens the overview and gate in your browser.
BafGo flags it. bafgo status and the graph mark broken links, so drift between a rule and its code or tests is visible instead of silent. Whoever picks the work up next repairs the link.
An older set of small, stateless kitchen tools: a timer, converter, recipe tracker, and shopping list. They are kept as a reference and are not part of Port.
Still curious? The walkthrough shows one rule moving from requirement to approved, end to end.