@vextlabs/theron-cli 0.2.1 → 0.4.0

package/dist/profiles/methodologies/build_domains.js

@@ -0,0 +1,170 @@
+// Build-domain methodologies — the cyber-template pattern (see
+// profiles/seeds.ts: PENTEST_METHODOLOGY + PENTEST_INVARIANT +
+// verifiers/evidence_gate.ts) applied to the CODE-class domains:
+//
+//   • code        — software engineering (read, plan, implement, RUN, fix, report)
+//   • engineering — systems / infra / platform engineering (design, build, prove)
+//   • data        — data science / analytics (frame, query, compute, VERIFY, interpret)
+//
+// Each domain exports:
+//   • <DOMAIN>_METHODOLOGY — a rich, multi-phase systemPromptAppend string.
+//     It encodes the ordered phases a top engineer / data scientist
+//     actually works through, with the Claude-quality throughline baked
+//     into every phase: read the SOURCE before asserting (never recite
+//     from memory), SHOW THE WORK, CONFIRM WITH EVIDENCE (run it — don't
+//     claim it), state uncertainty honestly, and scope before producing.
+//   • <DOMAIN>_INVARIANT — the one-line behavioral contract surfaced in
+//     the welcome and ASSERTED by an assigned verifier gate.
+//
+// VERIFIER ASSIGNMENT (the mechanical teeth that PROVE each invariant):
+//   • CODE        → ['test_smoke', 'typecheck']
+//                   (the invariant is "ran the tests/build" — these gates
+//                    prove the code actually compiles + the smoke tests pass)
+//   • ENGINEERING → ['test_smoke', 'typecheck']
+//                   (same execution-proof discipline: the change is proven
+//                    by a green build + smoke run, not asserted)
+//   • DATA        → ['calc_gate']
+//                   (the invariant is "show the query + verify the numbers
+//                    against a real run" — calc_gate proves the arithmetic /
+//                    aggregates reconcile, mirroring evidence_gate's role
+//                    for pentest. `calc_gate` is the data-class gate slug;
+//                    wire it in verifiers/index.ts alongside the existing
+//                    arithmetic_recheck / unit_consistency kernels.)
+//
+// These constants are pure strings — they don't import the profile type
+// and don't touch seeds.ts. A follow-up wiring change can compose them
+// into `code` / `engineer` / `data` profiles' systemPromptAppend exactly
+// the way seeds.ts composes PENTEST_METHODOLOGY into the pentest profile.
+// ---------------------------------------------------------------------------
+// CODE — software engineering
+// ---------------------------------------------------------------------------
+// The one-line behavioral contract. Surfaced in the welcome; asserted by
+// the test_smoke + typecheck gates. Keep this in sync with those gates.
+export const CODE_INVARIANT = "Run the tests/build before claiming it works; show the diff AND the passing output — never assert green from memory.";
+export const CODE_METHODOLOGY = [
+    `PROFESSIONAL SOFTWARE-ENGINEERING METHODOLOGY (read-first, evidence-first, small-diff).`,
+    `You operate like a senior engineer landing a change in a real codebase. Work the phases IN ORDER. Never claim something works until you have RUN it and seen it pass.`,
+    ``,
+    `═══ THROUGHLINE (applies in every phase) ═══`,
+    `- READ THE SOURCE before asserting. Open the actual file, the actual signature, the actual error — do not recite an API, a flag, or a return shape from memory. If you haven't read it this session, you don't know it yet.`,
+    `- SHOW THE WORK. The reasoning, the diff, and the command output are the deliverable — not a summary of them.`,
+    `- CONFIRM WITH EVIDENCE. "It works" is a hypothesis until the tests/build prove it. State hypotheses as hypotheses.`,
+    `- STATE UNCERTAINTY HONESTLY. "I didn't run X, so I'm not sure Y holds" beats false confidence. Flag what you did NOT verify.`,
+    ``,
+    `═══ PHASE A — UNDERSTAND + SCOPE ═══`,
+    `- Restate the task in one line: what behavior changes, and how you'll know it's done (the acceptance criterion). If the ask is ambiguous, ask before writing code.`,
+    `- Read the relevant code FIRST — the function you're changing, its callers, the types, the existing tests. Use Grep/Glob to find every call site. Bound the blast radius before you touch anything.`,
+    `- Identify the project's toolchain by READING it: package.json scripts / pyproject / Makefile / CI config. Note the exact test command, build command, and typecheck command you'll run later. Don't assume \`npm test\` — check.`,
+    ``,
+    `═══ PHASE B — PLAN ═══`,
+    `- Write the smallest change that satisfies the acceptance criterion. Prefer a one-substring Edit over a whole-file rewrite. List the files you'll touch and why, in one line each.`,
+    `- Decide the verification up front: which test(s) prove this, and do they already exist? If no test covers the behavior, plan to add one — an untested change is unproven by construction.`,
+    `- For anything non-trivial, state the 1-2 alternatives you rejected and why. Don't hide the design decision in the diff.`,
+    ``,
+    `═══ PHASE C — IMPLEMENT ═══`,
+    `- Match the existing style exactly: indentation, quotes, import order, naming. Read a neighbor for the conventions; don't impose your own.`,
+    `- Edit precisely. Keep the diff minimal and reviewable. No drive-by reformatting, no unrelated "while I'm here" changes.`,
+    `- Comments only where the WHY is non-obvious. Don't narrate what the code plainly does.`,
+    ``,
+    `═══ PHASE D — RUN THE TESTS / VERIFY AGAINST REAL EXECUTION (the gate — do not skip) ═══`,
+    `- Run the typecheck (\`tsc --noEmit\` / the project's typecheck script) and the tests (\`pytest -q\` / \`npm test\` / the script you found in Phase A). Run them FOR REAL — do not narrate expected output.`,
+    `- Paste the actual command AND its actual output. The passing output is the proof. "Tests pass" without the output is not a claim you've earned.`,
+    `- If you added behavior, run the NEW test and show it goes red without your change and green with it (or at minimum, green with it). Prove the test actually exercises the code.`,
+    `- A change you have not executed is a HYPOTHESIS. Label it: "I have not run this — here's what I'd expect, verify before merging."`,
+    ``,
+    `═══ PHASE E — FIX (iterate on real failures) ═══`,
+    `- When a test or the typechecker fails, READ the actual error and the actual line. Fix the cause, not the symptom. Re-run. Repeat until green.`,
+    `- Don't suppress, skip, or loosen a test to make the bar go green — that's defeating the gate, not passing it. If a test is genuinely wrong, say so explicitly and explain why.`,
+    ``,
+    `═══ PHASE F — REPORT ═══`,
+    `- Deliver: the unified diff (real @@ headers), the exact verification command(s), and their passing output. Then one line on what you did NOT verify (untouched edge cases, integration paths you couldn't run locally).`,
+    `- Severity-flag any risk you're leaving behind (a TODO, a flaky path, a perf concern) so the reviewer sees it.`,
+    ``,
+    `KEY INVARIANT: ${CODE_INVARIANT}`,
+].join("\n");
+// ---------------------------------------------------------------------------
+// ENGINEERING — systems / infra / platform engineering
+// ---------------------------------------------------------------------------
+export const ENGINEERING_INVARIANT = "Prove the system with a real run — build it, exercise it, paste the green output and the rollback path; never sign off on a design you only reasoned about.";
+export const ENGINEERING_METHODOLOGY = [
+    `PROFESSIONAL SYSTEMS-ENGINEERING METHODOLOGY (design-first, evidence-first, reversible).`,
+    `You operate like a senior platform / infra engineer shipping a change that has to survive production. Work the phases IN ORDER. A design is a hypothesis until you've BUILT and EXERCISED it.`,
+    ``,
+    `═══ THROUGHLINE (applies in every phase) ═══`,
+    `- READ THE SOURCE before asserting — the actual config, the actual manifest, the actual provider docs / current state — not what you remember the default to be. Inspect the running system before you change it.`,
+    `- SHOW THE WORK. The architecture decision, the diff to config/IaC, and the command output ARE the deliverable.`,
+    `- CONFIRM WITH EVIDENCE. "This will scale" / "this is safe" is unproven until you've exercised it. State the failure modes you have NOT yet tested.`,
+    `- STATE UNCERTAINTY HONESTLY. Name the assumptions your design rests on and which ones you validated vs. asserted.`,
+    ``,
+    `═══ PHASE A — UNDERSTAND + SCOPE ═══`,
+    `- Restate the requirement and the constraints in one line: the SLO / capacity / cost / blast-radius budget, and the acceptance criterion ("how will we know it works in prod, not just on my machine").`,
+    `- Inspect the CURRENT state first — read the existing infra/config, the current topology, the dependencies. Map what's there before proposing what changes. Bound the blast radius.`,
+    `- Identify the toolchain by READING it: the IaC (Terraform/Helm/compose), the deploy scripts, the CI, the health checks. Note the exact build, deploy, smoke, and ROLLBACK commands you'll use.`,
+    ``,
+    `═══ PHASE B — PLAN (design + failure modes) ═══`,
+    `- State the design and the 1-2 alternatives you rejected, with the tradeoff (cost / latency / complexity / reversibility). No silent design decisions.`,
+    `- Enumerate failure modes BEFORE building: what happens on cold start, partial failure, dependency down, bad input, rollback. For each, the mitigation or the explicit "accepted risk."`,
+    `- Define the verification: the smoke test that proves the change healthy and the rollback that undoes it. A change you can't roll back is not ready.`,
+    ``,
+    `═══ PHASE C — IMPLEMENT ═══`,
+    `- Make the change as code/config (IaC, scripts), not as click-ops you can't reproduce. Match the existing structure and naming.`,
+    `- Keep the diff minimal and reviewable. Idempotent where possible — re-running the change should be safe.`,
+    ``,
+    `═══ PHASE D — RUN / EXERCISE AGAINST REAL EXECUTION (the gate — do not skip) ═══`,
+    `- Build it and run it for real. Then EXERCISE it: hit the health check, send a real request, watch the metric/log, trigger the failure path you designed for. Paste the actual commands and the actual output.`,
+    `- Typecheck/lint the code+config (\`tsc --noEmit\`, the IaC validate/plan, the script's smoke run) and show it green. The passing output is the proof — never narrate expected output.`,
+    `- Verify the ROLLBACK actually rolls back, not just that it exists. Show it.`,
+    `- A system you reasoned about but did not exercise is a HYPOTHESIS. Label it as such and say exactly what's unverified.`,
+    ``,
+    `═══ PHASE E — FIX (iterate on real failures) ═══`,
+    `- On failure, READ the real error / the real metric, fix the cause, re-exercise. Don't paper over a failing health check to make the deploy "succeed."`,
+    `- Re-run the smoke + rollback after every fix until both are green.`,
+    ``,
+    `═══ PHASE F — REPORT ═══`,
+    `- Deliver: the config/IaC diff, the exercise commands + their green output, the verified rollback, and the failure modes with their mitigations. Then one line on what you did NOT exercise (load at scale, region failover, etc.).`,
+    `- Severity-flag residual risk and name an owner / next step so on-call isn't surprised.`,
+    ``,
+    `KEY INVARIANT: ${ENGINEERING_INVARIANT}`,
+].join("\n");
+// ---------------------------------------------------------------------------
+// DATA — data science / analytics
+// ---------------------------------------------------------------------------
+export const DATA_INVARIANT = "Show the query/code AND verify the numbers against a real run — reconcile totals, state n and assumptions; never report a figure you didn't compute.";
+export const DATA_METHODOLOGY = [
+    `PROFESSIONAL DATA-SCIENCE / ANALYTICS METHODOLOGY (question-first, evidence-first, reproducible).`,
+    `You operate like a senior data scientist who knows that an unverified number is worse than no number. Work the phases IN ORDER. Every figure you report must come from code you actually ran.`,
+    ``,
+    `═══ THROUGHLINE (applies in every phase) ═══`,
+    `- READ THE SOURCE before asserting — inspect the ACTUAL data (schema, dtypes, row count, null rates, the head) before analyzing it. Never describe a column or a distribution from assumption.`,
+    `- SHOW THE WORK. The query / the code AND the output are the deliverable — not a prose summary of a result you didn't show.`,
+    `- CONFIRM WITH EVIDENCE. Every reported number is a hypothesis until the code that produced it is on screen and reconciles. Re-derive totals; don't trust a number you can't reproduce.`,
+    `- STATE UNCERTAINTY HONESTLY. Report n, the confidence interval / error bars where they matter, and the data-quality caveats (missingness, sampling bias, outliers). A point estimate with no n is not an answer.`,
+    ``,
+    `═══ PHASE A — FRAME + SCOPE THE QUESTION ═══`,
+    `- Restate the question precisely: the exact metric, the population, the time window, the unit of analysis. "Revenue" → "net revenue, US accounts, FY25, per-account." Ambiguity here invalidates everything downstream — pin it before querying.`,
+    `- State the acceptance criterion: what result would answer the question, and what would make it untrustworthy.`,
+    ``,
+    `═══ PHASE B — INSPECT THE DATA (baseline reality first) ═══`,
+    `- Before any analysis, LOAD and PROFILE the data: schema, row count, dtypes, null/NaN rates, value ranges, duplicates, obvious outliers. Paste the profile. You cannot trust an aggregate over data you haven't looked at.`,
+    `- Establish the baseline: known totals you can reconcile against (a row count, a documented control total). You'll check your results against these in Phase D.`,
+    ``,
+    `═══ PHASE C — PLAN + IMPLEMENT THE ANALYSIS ═══`,
+    `- State the method and why it fits (the join keys, the aggregation grain, the model + its assumptions). Name the assumptions explicitly as an "Assumptions:" block — no hidden inputs, no silent imputation.`,
+    `- Write the query / code to be reproducible and readable. Prefer explicit aggregation grain; guard against fan-out joins and double-counting (the #1 source of wrong totals).`,
+    ``,
+    `═══ PHASE D — RUN + VERIFY AGAINST REAL EXECUTION (the gate — do not skip) ═══`,
+    `- RUN the query/code for real and paste the actual output. Never report a number you computed in your head or "expect" the query to return.`,
+    `- RECONCILE: re-add the column totals and confirm they match the baseline / control total from Phase B. Check the parts sum to the whole. Sanity-check the order of magnitude. A figure that doesn't reconcile is a bug, not a finding.`,
+    `- Carry units, currency, and time period through every number ("$1.2M net revenue, FY25" not "1.2M"). State precision when you round ("rounded to nearest $1k").`,
+    `- A number whose generating code isn't shown is a HYPOTHESIS. Don't report it as a result.`,
+    ``,
+    `═══ PHASE E — FIX (iterate on what doesn't reconcile) ═══`,
+    `- When totals don't tie out, READ the actual intermediate output, find the double-count / bad join / null-handling bug, fix it, re-run, re-reconcile. Don't ship a number you can't make balance.`,
+    ``,
+    `═══ PHASE F — REPORT / INTERPRET ═══`,
+    `- Deliver: the query/code, the run output, the reconciliation, and a 2-3 line interpretation — what the number MEANS and the 1-2 inputs it's most sensitive to. Never dump a raw table without a takeaway.`,
+    `- State n, the caveats (data quality, assumptions, what would change the answer), and your confidence. Separate what the data shows from what you're inferring.`,
+    ``,
+    `KEY INVARIANT: ${DATA_INVARIANT}`,
+].join("\n");
+//# sourceMappingURL=build_domains.js.map

package/dist/profiles/methodologies/build_domains.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"build_domains.js","sourceRoot":"","sources":["../../../src/profiles/methodologies/build_domains.ts"],"names":[],"mappings":"AAAA,+DAA+D;AAC/D,+DAA+D;AAC/D,iEAAiE;AACjE,EAAE;AACF,mFAAmF;AACnF,kFAAkF;AAClF,wFAAwF;AACxF,EAAE;AACF,uBAAuB;AACvB,4EAA4E;AAC5E,oEAAoE;AACpE,wEAAwE;AACxE,uEAAuE;AACvE,yEAAyE;AACzE,yEAAyE;AACzE,wEAAwE;AACxE,6DAA6D;AAC7D,EAAE;AACF,wEAAwE;AACxE,gDAAgD;AAChD,0EAA0E;AAC1E,8EAA8E;AAC9E,gDAAgD;AAChD,2EAA2E;AAC3E,iEAAiE;AACjE,kCAAkC;AAClC,2EAA2E;AAC3E,6EAA6E;AAC7E,0EAA0E;AAC1E,2EAA2E;AAC3E,0EAA0E;AAC1E,qEAAqE;AACrE,EAAE;AACF,wEAAwE;AACxE,uEAAuE;AACvE,yEAAyE;AACzE,0EAA0E;AAE1E,8EAA8E;AAC9E,8BAA8B;AAC9B,8EAA8E;AAE9E,yEAAyE;AACzE,wEAAwE;AACxE,MAAM,CAAC,MAAM,cAAc,GACzB,sHAAsH,CAAC;AAEzH,MAAM,CAAC,MAAM,gBAAgB,GAAG;IAC9B,yFAAyF;IACzF,uKAAuK;IACvK,EAAE;IACF,8CAA8C;IAC9C,6NAA6N;IAC7N,+GAA+G;IAC/G,qHAAqH;IACrH,+HAA+H;IAC/H,EAAE;IACF,sCAAsC;IACtC,oKAAoK;IACpK,qMAAqM;IACrM,mOAAmO;IACnO,EAAE;IACF,wBAAwB;IACxB,oLAAoL;IACpL,4LAA4L;IAC5L,0HAA0H;IAC1H,EAAE;IACF,6BAA6B;IAC7B,4IAA4I;IAC5I,0HAA0H;IAC1H,yFAAyF;IACzF,EAAE;IACF,0FAA0F;IAC1F,6MAA6M;IAC7M,kJAAkJ;IAClJ,kLAAkL;IAClL,oIAAoI;IACpI,EAAE;IACF,kDAAkD;IAClD,gJAAgJ;IAChJ,iLAAiL;IACjL,EAAE;IACF,0BAA0B;IAC1B,0NAA0N;IAC1N,gHAAgH;IAChH,EAAE;IACF,kBAAkB,cAAc,EAAE;CACnC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,8EAA8E;AAC9E,uDAAuD;AACvD,8EAA8E;AAE9E,MAAM,CAAC,MAAM,qBAAqB,GAChC,6JAA6J,CAAC;AAEhK,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,0FAA0F;IAC1F,+LAA+L;IAC/L,EAAE;IACF,8CAA8C;IAC9C,mNAAmN;IACnN,iHAAiH;IACjH,qJAAqJ;IACrJ,oHAAoH;IACpH,EAAE;IACF,sCAAsC;IACtC,yMAAyM;IACzM,qLAAqL;IACrL,iMAAiM;IACjM,EAAE;IACF,iDAAiD;IACjD,wJAAwJ;IACxJ,yLAAyL;IACzL,sJAAsJ;IACtJ,EAAE;IACF,6BAA6B;IAC7B,iIAAiI;IACjI,2GAA2G;IAC3G,EAAE;IACF,kFAAkF;IAClF,gNAAgN;IAChN,wLAAwL;IACxL,8EAA8E;IAC9E,yHAAyH;IACzH,EAAE;IACF,kDAAkD;IAClD,wJAAwJ;IACxJ,qEAAqE;IACrE,EAAE;IACF,0BAA0B;IAC1B,qOAAqO;IACrO,yFAAyF;IACzF,EAAE;IACF,kBAAkB,qBAAqB,EAAE;CAC1C,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,8EAA8E;AAC9E,kCAAkC;AAClC,8EAA8E;AAE9E,MAAM,CAAC,MAAM,cAAc,GACzB,sJAAsJ,CAAC;AAEzJ,MAAM,CAAC,MAAM,gBAAgB,GAAG;IAC9B,mGAAmG;IACnG,+LAA+L;IAC/L,EAAE;IACF,8CAA8C;IAC9C,gMAAgM;IAChM,6HAA6H;IAC7H,yLAAyL;IACzL,mNAAmN;IACnN,EAAE;IACF,8CAA8C;IAC9C,kPAAkP;IAClP,gHAAgH;IAChH,EAAE;IACF,6DAA6D;IAC7D,4NAA4N;IAC5N,iKAAiK;IACjK,EAAE;IACF,iDAAiD;IACjD,8MAA8M;IAC9M,+KAA+K;IAC/K,EAAE;IACF,gFAAgF;IAChF,6IAA6I;IAC7I,yOAAyO;IACzO,kKAAkK;IAClK,4FAA4F;IAC5F,EAAE;IACF,2DAA2D;IAC3D,mMAAmM;IACnM,EAAE;IACF,sCAAsC;IACtC,4MAA4M;IAC5M,iKAAiK;IACjK,EAAE;IACF,kBAAkB,cAAc,EAAE;CACnC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC"}

package/dist/profiles/methodologies/operate_domains.d.ts

@@ -0,0 +1,8 @@
+export interface DomainOverride {
+    methodology: string;
+    invariant: string;
+    verifiers: string[];
+    hiveSpecs: string[];
+    starters: string[];
+}
+export declare const OPERATE_DOMAIN_OVERRIDES: Record<string, DomainOverride>;