Snapshot WIP: solver HP epic progress, BPHX/HX physics, BMAD skill refresh.
Some checks failed
CI / check (push) Has been cancelled

Capture uncommitted solver robustness work (regularization, domain errors, linear solver lifecycle, tube DP/MSH), web workbench updates, and synced BMAD skills across IDE agent folders before starting BPHX pressure-drop.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
2026-07-19 16:35:31 +02:00
parent 88620790d6
commit 5bd180b5b8
1363 changed files with 101041 additions and 58547 deletions

View File

@@ -0,0 +1,33 @@
# Headless JSON Response
The default invocation is headless: input goes in, JSON comes out. The contract is intentionally tiny — return the outcome and the files touched. Anything else a caller needs is inside those files (SPEC.md, companions, `.memlog.md`).
## Success
```json
{
"status": "complete",
"files": [
"_bmad-output/specs/spec-quarter-drop/SPEC.md",
"_bmad-output/specs/spec-quarter-drop/glossary.md",
"_bmad-output/specs/spec-quarter-drop/.memlog.md"
]
}
```
`files` lists every file written or modified in this run, in any order. The spec folder, kernel filename, memlog location, capabilities, companions, and verdict are all readable from those files; no need to re-encode them in the response.
## Blocked
```json
{
"status": "blocked",
"error_code": "insufficient_intent",
"reason": "Input was a one-line idea with no surrounding context; too thin to distill. Suggest bmad-prd to draw the vision out first."
}
```
Defined `error_code` values:
- `insufficient_intent` — input too thin to distill into a kernel.
- `missing_slug` — input is sparse or multi-source and no slug was provided by the caller or derivable from a source path.

View File

@@ -0,0 +1,49 @@
---
id: SPEC-{slug}
companions: [] # files downstream MUST read alongside SPEC.md. Paths may point inside the spec folder (spec-authored) or outside it (adopted from an upstream skill).
sources: [] # files fully absorbed into the SPEC (audit only; downstream does NOT read these). Never the memlog.
---
> **Canonical contract.** This SPEC and the files in `companions:` are the complete, preservation-validated contract for what to build, test, and validate. Source documents listed in frontmatter are for traceability only — consult them only if you need narrative rationale or prose color this contract intentionally omits.
# {Spec Title}
## Why
{One paragraph naming the force behind this work. A spec can exist for any of:
- **a pain to solve** — a user or operator is stuck on a specific gap;
- **an opportunity to capture** — something newly possible we want to claim;
- **a vision to realize** — a thing we want to make exist because we want it to exist;
- **a mandate to meet** — a regulation, deprecation, deadline, or contractual obligation.
Name which (or which combination) applies, who is affected, and the backdrop that makes it matter now. This is the anchor every downstream trade-off resolves against.}
## Capabilities
- **CAP-1**
- **intent:** {One sentence. "User or system can do X to achieve Y." WHAT, not HOW.}
- **success:** {Testable or demonstrable criterion. Something a test or a real demonstration can decide.}
## Constraints
- {A non-negotiable that bends design. If it doesn't rule anything out, it doesn't belong.}
## Non-goals
- {Explicit out-of-scope item. At least one. Stops downstream from filling the vacuum.}
## Success signal
- {One or two sentences. World-change moment, not dashboard. Concrete enough to write a test or run a demonstration against.}
## Assumptions
<!-- Optional. Omit this section entirely if empty. Inferred calls made without direct confirmation from the input. -->
- {Statement of fact the Spec proceeded under, e.g. "Assumed mobile-first since input mentioned GPS but no platform."}
## Open Questions
<!-- Optional. Omit this section entirely if empty. Gaps the input did not resolve that need a human decision before downstream skills consume the Spec. -->
- {Question phrased so a human can answer it, e.g. "Is offline playback in scope for CAP-2?"}