Pipeline-Befehle

Apothem liefert eine architekturbewusste /plan-Pipeline, eine dreizehnstufige /research-Pipeline sowie eine Audit-Review-Sequenz aus elf Befehlen aus — und gibt damit jedem Projekt einen strukturierten Weg von roher Prosa zu Code in Produktionsqualität, der entlang mehrerer Achsen geprüft wurde, und von einer rohen Idee zu einem verbreiteten, begutachteten (peer-reviewed) Paper.

Pipeline-ÜberblickCopy Anchor Link

flowchart LR
    accTitle: Plan pipeline command flow
    accDescr: Left-to-right flowchart of the apothem plan pipeline from the spec stage through the generate and review stages, then through a conditional architecture-bearing decision that either runs the design stage or skips directly to the execute stage. The orthogonal audit stage wraps the spec-through-review span as a closed remediation loop, and the re-entrant amend stage revises an existing suite and returns it to review.
    A[/plan-spec] --> B[/plan-generate]
    B --> C[/plan-review]
    AUD[/plan-audit<br/>orthogonal: wraps spec → review] -.->|closed-loop remediation| A
    AM[/plan-amend<br/>re-entrant: revises an existing suite] -.->|re-review| C
    C --> Q{Architecture-bearing suite?}
    Q -->|yes| F[/plan-design<br/>emit _inputs/design.md]
    Q -->|no| D[/plan-execute]
    F --> D
    D --> E[/plan-status]
    D --> G[Audit review sequence]
    G --> H[Completion milestone]

Die PlanungsstufenCopy Anchor Link

Die Pipeline wird als acht vollwertige Slash-Befehle ausgeliefert, einer je Stufe — jeder einzeln als /plan-<stage> aufrufbar. Der Orchestrator /plan führt sie von einer Mission bis zu einer ausgeführten Suite.

/plan-audit ist orthogonal zum linearen Ablauf, keine Stufe darin. Es umschließt /plan-spec → /plan-generate → /plan-review als eine einzige geschlossene Schleife, führt nur die fehlenden vorgelagerten Stufen aus, behebt Befunde aktiv und hinterlässt die Suite bereit für /plan-execute. Es unterscheidet sich von der Audit-Review-Sequenz weiter unten, die eine ausgeführte Codebasis statt einer Plan-Suite auditiert.

/plan-design ist keine universelle Zeremonie. /plan-review stuft ein, ob die Suite architekturtragende Oberflächen ändert. Falls ja, gibt /plan-design die Design-Spur aus, die /plan-execute und /architecture-review verarbeiten. Falls nein, geht die geprüfte Suite direkt in die Ausführung über.

Die Forschungs-PipelineCopy Anchor Link

Die Forschungs-Pipeline wird als dreizehn vollwertige Slash-Befehle ausgeliefert, einer je Stufe — jeder einzeln als /research-<stage> aufrufbar, verkettet durch ein Sequenz-Gate und ein Übergabe-Manifest, unter zehn Strenge-Mandaten (maßgebliche Quellen, Reproduzierbarkeit, Falsifizierbarkeit, Zitationsintegrität, Präregistrierung, Ethik / Interessenkonflikte, statistische Strenge, Open Science / FAIR, Konformität mit Berichtsrichtlinien, theoretische Fundierung / Wirkung).

flowchart LR
    accTitle: Research pipeline command flow
    accDescr: Left-to-right flowchart of the apothem research pipeline from the ideate stage through spec, theory, sources, synthesis, proposal, study design, experiment, analysis, paper, and peer review to publish and disseminate, with a revision loop from review back to paper.
    RI[/research-ideate] --> RS[/research-spec]
    RS --> RT[/research-theory]
    RT --> RSO[/research-sources]
    RSO --> RSY[/research-synthesis]
    RSY --> RPR[/research-proposal]
    RPR --> RD[/research-design]
    RD --> RE[/research-experiment]
    RE --> RA[/research-analysis]
    RA --> RP[/research-paper]
    RP --> RR[/research-review]
    RR --> RPU[/research-publish]
    RPU --> RDI[/research-disseminate]
    RR -.->|revision loop| RP

Der Orchestrator für den gekapselten Workflow /research führt diese Stufen von der rohen Frage bis zum veröffentlichten Paper (er selbst ist keine Stufe) und prüft die Ausgabe jeder Stufe unabhängig, bevor die nächste Stufe darauf aufbaut; --quick führt nur /research-sources + /research-synthesis aus, für einen zitierten Bericht in einem einzigen Durchgang.

Die empirischen Stufen (sources, design, experiment, analysis) und die Schreibstufen (paper, review, publish, disseminate) stützen sich zusätzlich auf Oberflächen, die die Strenge operationalisieren — fairer Vergleich mehrerer Methoden, Provenienz der Vergleichsverfahren, ein Gerüst für das Experimentprogramm, ein Plan zur Rechenauslastung, eine optionale (Opt-in) autonome Experimentschleife, ein Fortschritts-Gate nach Definition of Done, Verblindung mit gestufter Offenlegung, ein Suchprotokoll, Zuteilung und Teststärkeplanung der Studie, Analysedisziplin, Notfallpläne für den Plan, Integrität der Abbildungen sowie die Planung von Vorträgen und Postern —, die den zehn Mandaten operative Details hinzufügen, ohne sie zu erweitern.

Audit-Review-SequenzCopy Anchor Link

Der Orchestrator für den gekapselten Workflow /audit durchläuft alle elf nachstehenden Dimensionen in einem einzigen parallelen Durchgang — das Gegenstück der Audit-Festung zu /plan und /research — und fasst die Ergebnisse zu einem einzigen deduplizierten, nach Schweregrad priorisierten Befundbericht zusammen (nur Bericht; die Behebung wird an /elevate weitergeleitet). Jede Dimension ist auch einzeln aufrufbar.

Der Orchestrator für den gekapselten Workflow /fortress schließt die Schleife, über die /audit berichtet: Er erkennt Befunde über /audit, verifiziert jeden Befund, behebt jeden verbleibenden Befund an der Oberfläche, der er gehört, auditiert in einer begrenzten Schleife erneut und führt das Ergebnis durch das Gate /release-readiness — das Gegenstück für die Produktionshärtung zu /plan und /research.

Alle BefehleCopy Anchor Link

Jeder ausgelieferte Befehl, generiert aus seiner Definition unter src/apothem/commands/. Befehle ohne handgeschriebene Seite erhalten eine aus derselben Definition generierte Seite.