brancher-prototype

Brancher Prototype

A throwaway idea-testing loop that trades code quality for speed on a single disposable Brancher node, then converts whatever was learned into a persistent GitHub scoping ticket before the node disappears. This skill reuses brancher-preview's spin-up step and its build-command logic — it does not duplicate the create -> wait -> sanitize sequence, and it does not replace brancher-cleanup's deletion mechanics. What it adds on top: a ground-rules statement for working fast and dirty ON THE NODE ONLY, a notes-first iteration discipline so ideas survive the node, and a harvest step that turns the node's git diff into a ticket via src/pb_hypernode_mcp/prototype_logic.py's tested functions.

Prototype-mode ground rules

Prototype mode suspends this project's normal TDD workflow, coding standards, and plan-orchestration pipeline — but only for code written on the disposable -eph node, never for this repo's own source. Standards resume immediately for anything that graduates out of a prototype (via a real plan/task, not by copy-pasting the hack as-is).

• Write the smallest hack that demonstrates the idea. Skip tests, skip declare(strict_types=1) discipline, skip PSR-12, skip DI-over-rewrite — none of that matters for code that is going to be destroyed with the node.
• All edits happen on-node, via brancher_exec heredocs (preferred, since the command and its result are both visible in the session transcript) or brancher_put for pushing a whole file up. Never edit the local repo to test a prototype idea — the local checkout is not disposable, and any edit there would show up as unexplained dirt in the harvest step's local git status check below.
• Be honest about what "prototype mode suspends standards" actually means: this is a prompt-level convention, not an enforced sandbox boundary. Nothing stops an AI session from writing production-grade code on the node anyway, and nothing stops a careless edit from touching the local repo instead of the node — there is no mechanism here that makes either mistake structurally impossible, only prose asking you not to make it (the same honesty brancher-spinup extends to its own sanitization guardrails: sanitization commands are enforced by the underlying tool, but this skill's "hack fast, hack on-node only" convention is not).
• brancher_put paths must contain no shell metacharacters. Both local_path and remote_path are known injection sinks if either string is built from untrusted input — always pass a plain literal path, never something assembled by string-concatenating user-supplied text.
• Prefer hacking under app/code or app/design. Anything touched under GIT_EXCLUDED_PATHS (vendor, generated, var, pub/static, pub/media, node_modules) will not appear in the harvest diff — the harvest step only lists those paths as changed (detect_excluded_path_changes()), it never diffs their content. If a hack under one of those paths is worth keeping, describe what it actually did in PROTOTYPE_NOTES.md in enough detail that the ticket reader could reconstruct it, because the diff alone will not show it.