34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
---
|
|
status: resolved
|
|
claimed-by: "019fba91-eabf-76ae-b086-a37ac061d6e8"
|
|
claimed-at: "2026-07-31T20:54:32-04:00"
|
|
parent: "[[002-pi-subagents-map]]"
|
|
blocked-by:
|
|
- "[[003-pi-subagents-herdr-compatibility-research]]"
|
|
- "[[004-pi-subagents-pi-extension-ecosystem-research]]"
|
|
- "[[005-pi-subagents-firstmate-and-related-tools-research]]"
|
|
- "[[006-pi-subagents-local-config-inventory-task]]"
|
|
- "[[011-pi-subagents-herdr-pi-integration-research]]"
|
|
- "[[012-pi-subagents-herdr-extension-boundary-research]]"
|
|
- "[[013-pi-subagents-pi-fork-research]]"
|
|
- "[[014-pi-subagents-firstmate-patterns-research]]"
|
|
- "[[019-pi-subagents-herdr-status-projection-prototype]]"
|
|
tags:
|
|
- ticket/grill
|
|
---
|
|
|
|
# Adopt adapt or build decision
|
|
|
|
## Question
|
|
|
|
Given the researched Herdr compatibility model, Pi extension ecosystem, Firstmate-related options, and local configuration constraints, should this effort adopt an existing solution, adapt companion tooling, or build a neutral Pi extension?
|
|
|
|
## Resolution
|
|
|
|
Build a new neutral Pi extension rather than adopting Firstmate, adapting `mjakl/pi-subagent`, or extending `pi-fork` directly.
|
|
The extension should focus on Pi-native subagent behavior first and should not focus on Herdr integration in the initial decision route.
|
|
Subagent types, prompts, and policy remain Pi configuration, not extension-bundled opinion.
|
|
The extension should support both active-branch forked children for context-preserving investigation and fully independent children for adversarial review, red-green refactor checks, code review, and document sanity checks.
|
|
Subagent status should be shown inside Pi for headless/background children.
|
|
Herdr support, if added later, should be optional and adapter-shaped rather than a core dependency.
|