MethodologyPhương pháp
The pipeline pages show what each skill does; this page shows the methodology the latest release wired underneath it. Two pieces: a coverage-grid planning mode that turns "did we think of everything?" into a deterministic, gameable-proof check, and six governance rules that make the harness hold itself to the same evidence standard it forces on your code.Các trang pipeline cho thấy mỗi skill làm gì; trang này cho thấy phương pháp mà bản release mới nhất gắn bên dưới. Hai phần: một chế độ coverage-grid biến "đã nghĩ hết chưa?" thành một phép kiểm tất định, chống-gian, và sáu rule quản trị khiến harness tự bắt chính mình theo cùng chuẩn bằng chứng mà nó ép lên code của bạn.
Coverage-grid planning modeChế độ coverage-grid
Run hs:plan --grid (Workflow Step 6). After phase decomposition it builds a coverage grid from the plan's own content, runs a deterministic invariant + confab + verdict pass, and makes you resolve that verdict before the plan is ready — a required coverage pass, not an optional footnote. It never auto-edits the plan and never locally hard-blocks: local generates, the presence gate enforces existence, and the human resolves the thin cells.Chạy hs:plan --grid (Workflow Step 6). Sau khi phân rã phase, nó dựng một coverage grid từ chính nội dung plan, chạy một lượt invariant + confab + verdict tất định, và bắt bạn giải verdict đó trước khi plan sẵn sàng — một lượt coverage bắt buộc, không phải chú thích tùy chọn. Nó không tự sửa plan và không hard-block tại máy: local sinh, presence gate ép sự tồn tại, con người giải các ô mỏng.
Breadth × depth, on a covering arrayBề rộng × chiều sâu, trên covering array
The coverage metric splits into breadth (are the axis combinations covered at all?) and depth (is each covered cell actually filled with grounded content?). The skeleton is generated on a deterministic covering array at a chosen strength — every pairwise (or higher) combination appears at least once, with no model in the loop for the build.Chỉ số coverage tách thành bề rộng (các tổ hợp trục có được phủ không?) và chiều sâu (mỗi ô được phủ có thực sự được điền nội dung có căn cứ không?). Skeleton sinh trên một covering array tất định ở một strength chọn trước — mọi tổ hợp cặp (hoặc cao hơn) xuất hiện ít nhất một lần, không cần model cho bước build.
Axes come FROM the planTrục đến TỪ plan
The planner axes are feature × layer × lifecycle × risk_class × stakeholder. §features feed the feature axis, §risks feed risk_class — axis values are never hand-typed. Empty features ⇒ the grid cannot run; the engine raises instead of fabricating values, so a grid can't be conjured out of nothing.Trục của planner là feature × layer × lifecycle × risk_class × stakeholder. §features nạp trục feature, §risks nạp risk_class — giá trị trục không bao giờ gõ tay. Features rỗng ⇒ grid không chạy được; engine raise thay vì bịa giá trị, nên không thể phù phép một grid từ hư không.
Pre-registration freezeĐóng băng pre-registration
Timeline is hard: build → freeze → fill. Before the first cell is filled, grid_engine.py preregister freezes the combination-ban rules and stamps them into a ## Grid constraint rules (frozen) body section of plan.md, so you see the rules at Approve. Minting a rule during fill is fraud; an amendment re-generates the whole grid plus a receipt.Trình tự cứng: build → freeze → fill. Trước khi điền ô đầu tiên, grid_engine.py preregister đóng băng các rule cấm-tổ-hợp và đóng dấu vào mục ## Grid constraint rules (frozen) trong plan.md, nên bạn thấy rule lúc Approve. Đúc một rule trong khi fill là gian lận; một amendment sinh lại cả grid kèm receipt.
Anti-confab fill — honest STUBFill chống-confab — STUB thật thà
The @grid-filler subagent reads the skeleton and writes per-cell content under a two-gate contract: gate-1 checks the file's structure, gate-2 is expand_cell's anti-confab validation of each cell's raw content. When it cannot ground a cell, it defaults to an honest STUB — a plausible-but-hollow fill is caught, not shipped.Subagent @grid-filler đọc skeleton và ghi nội dung từng ô theo hợp đồng hai cổng: gate-1 kiểm cấu trúc file, gate-2 là validation chống-confab của expand_cell trên nội dung thô mỗi ô. Khi không căn cứ được một ô, nó mặc định về STUB thật thà — một fill nghe hợp lý nhưng rỗng bị bắt, không ship.
The flow — build → review → emitLuồng — build → review → emit
Three verdicts: pass (clean), needs-detail (advisory findings — some cells still thin), reject (a critical/blocking finding — coverage is badly thin). Resolve every non-pass cell before Red-team: add the missing coverage, or attest it [JUSTIFIED-THIN] (an attested STUB with a reason — a resolved cell, not an empty skeleton one).Ba verdict: pass (sạch), needs-detail (finding advisory — vài ô còn mỏng), reject (finding tới hạn/chặn — coverage mỏng nặng). Giải mọi ô không-pass trước Red-team: thêm coverage thiếu, hoặc attest [JUSTIFIED-THIN] (một STUB có attest kèm lý do — ô đã giải, không phải ô skeleton rỗng).
grid: true, plan_approval.py REFUSES an APPROVED verdict until the coverage-grid artifact exists (parity with plan-graph.yaml), and hs:cook re-checks it at its Phase-DAG preflight via grid_emit_guard.py --require (exit 2 → STOP). This is presence only — it catches "declared grid but emitted nothing", never blocks on a reject verdict. Below-floor coverage surfaces WHICH cells are thin and asks for an explicit human confirm (never a silent pass, never a blind block).
Khi plan đóng dấu grid: true, plan_approval.py TỪ CHỐI verdict APPROVED tới khi artifact coverage-grid tồn tại (ngang plan-graph.yaml), và hs:cook kiểm lại ở Phase-DAG preflight qua grid_emit_guard.py --require (exit 2 → STOP). Đây chỉ là presence — bắt "khai grid nhưng emit rỗng", không bao giờ chặn vì verdict reject. Coverage dưới sàn sẽ nêu ô NÀO mỏng và xin xác nhận người tường minh (không pass câm, không chặn mù).
N/A credit, anchored to the planCredit N/A, neo vào plan
A cell marked N/A earns credit only against a frozen rule whose hash matches the approved active plan — a forged rule:<id> N/A is a hard reject, and without --rules the frozen ruleset is None (0 credit, fail-closed). That closes "mark everything N/A to inflate the denominator".Một ô đánh dấu N/A chỉ được credit theo một rule đã đóng băng có hash khớp plan active đã duyệt — một N/A rule:<id> giả bị hard reject, và không có --rules thì ruleset đóng băng là None (0 credit, fail-closed). Điều đó chặn "đánh N/A hết để thổi mẫu số".
Escalate vs amendmentEscalate vs amendment
Climbing one strength rung changes only difficulty — axes and frozen rules unchanged — so old rows stay valid and are seeded (100% of prior fill survives). Changing an axis, value, or rule changes the question — it is an amendment: fresh-regenerate the whole grid and re-approve. One line: amendment ⇒ redo; escalate ⇒ keep the done work.Leo một nấc strength chỉ đổi độ khó — trục và rule đóng băng không đổi — nên hàng cũ vẫn hợp lệ và được seed (100% fill trước sống sót). Đổi một trục, giá trị, hay rule là đổi câu hỏi — đó là amendment: sinh lại cả grid và duyệt lại. Một dòng: amendment ⇒ làm lại; escalate ⇒ giữ việc đã xong.
build always counts the skeleton's exact row cost and embeds the receipt (shape / strength / count / over / cost-table) — an over-guardrail build REFUSES (receipt only, no grid) unless --allow-oversize. Only the skill prompts: on an interactive breach it echoes the cost-table, then asks four doors — (a) split the plan/phase, (b) run and pay, (c) raise guardrail_rows durably, (d) lower strength this round. The machine chooses none of them; the user is supreme, and the chosen door is recorded.Guardrail 4 cửa. build luôn đếm chính xác row-cost của skeleton và nhúng receipt (shape / strength / count / over / cost-table) — build vượt guardrail sẽ TỪ CHỐI (chỉ receipt, không grid) trừ khi --allow-oversize. Chỉ skill hỏi: khi vượt trong chế độ tương tác, nó echo cost-table, rồi hỏi bốn cửa — (a) tách plan/phase, (b) chạy và trả phí, (c) nâng guardrail_rows lâu dài, (d) hạ strength lượt này. Máy không chọn cửa nào; người dùng tối cao, và cửa đã chọn được ghi lại.Methodology rules in the layer todayRule phương pháp trong lớp luật hôm nay
The harness already forces artifacts to anchor claims in evidence. The rule layer — consolidated to 15 rules after the merge folded the old methodology split into the survivors — carries that discipline in harness/rules/, loaded on demand. Two of the old methodology rules still stand as their own files; the rest of that discipline now lives inside the merged rules and the registers they point at.Harness vốn đã ép artifact neo claim vào bằng chứng. Lớp luật — hợp nhất còn 15 rule sau đợt gộp nhập phần phương pháp vào các rule còn sống — mang kỷ luật đó trong harness/rules/, nạp khi cần. Hai rule phương pháp cũ vẫn đứng thành tệp riêng; phần kỷ luật còn lại nay sống trong các rule đã gộp và các register mà chúng trỏ tới.
anti-tautology-detection
A verification artifact MUST NOT import the application module it verifies — a checker reaching into the code it validates can be self-consistent and still wrong. Uses AST/regex and golden (hardcoded) assertions. Backed by harness/scripts/anti_tautology.py.Một artifact verify KHÔNG được import module ứng dụng mà nó kiểm — một checker thò vào chính code nó validate có thể tự-nhất-quán mà vẫn sai. Dùng AST/regex và golden assertion (hardcode). Nền: harness/scripts/anti_tautology.py.
claim-verification
For a universal / absence / structural claim — "every endpoint requires auth", "no PII in logs" — a shape a behavioral test can't express. Enumerate every match → assert the condition → report PASS/FAIL per match with file:line. Zero matches is SKIPPED, never vacuously PASSED. Engine claim_verify.py, SSOT claim-rules.yaml.Cho một claim phổ quát / vắng mặt / cấu trúc — "mọi endpoint đòi auth", "không PII trong log" — dạng mà test hành vi không diễn đạt được. Liệt kê mọi match → assert điều kiện → báo PASS/FAIL từng match kèm file:line. Không match nào = SKIP, không bao giờ PASS rỗng. Engine claim_verify.py, SSOT claim-rules.yaml.
Discipline folded into the merged rulesKỷ luật gộp vào các rule đã hợp nhất
The regression-sentinel discipline — one test per past incident, never deleted, registered via sentinel_register.py — now rides tdd-discipline. The ADR question ("why this call?") is answered by the DEC ledger: an architecture decision finalized at attestation is recorded with decision_register.py, not remembered. And risk is scored by risk_rubric.py (tier tiny/normal/high_risk) — the same tier the measured review gate reads.Kỷ luật regression-sentinel — một test cho mỗi sự cố quá khứ, không bao giờ xoá, đăng qua sentinel_register.py — nay đi cùng tdd-discipline. Câu hỏi ADR ("vì sao chọn thế?") được sổ DEC trả lời: quyết định kiến trúc chốt ở bước attestation được ghi bằng decision_register.py, không phải nhớ suông. Còn rủi ro được chấm bởi risk_rubric.py (hạng tiny/normal/high_risk) — đúng hạng mà cổng review đo được đọc.
The layer's own contractHợp đồng của chính lớp luật
The always-load pair — harness-contract (≤75 lines: the three posture hooks, actor=attribution, fail-open vs fail-closed) and no-orphan-code — is backed by tests, not trust: the forbidden-wording bans are enforced by test_bug_class_invariants.py, and reachability over four channels stands behind the no-orphan rule.Cặp luôn-nạp — harness-contract (≤75 dòng: ba hook posture, actor=attribution, fail-open vs fail-closed) và no-orphan-code — được test đứng sau, không tin suông: lệnh cấm từ-ngữ bị test_bug_class_invariants.py ép, và khả-tới bốn kênh đứng sau luật không-mồ-côi.
Methodology references across skillsTham chiếu phương pháp xuyên skill
Existing skills gained deeper method references — loaded on demand, they raise the ceiling of each skill without bloating its thin core.Các skill có sẵn được thêm tham chiếu phương pháp sâu hơn — nạp khi cần, nâng trần mỗi skill mà không phình lõi mỏng.
| SkillSkill | Methodology reference addedTham chiếu phương pháp thêm vào |
|---|---|
hs:scenario | ISO 25010 coverage matrix + stakeholder & lifecycle decomposition dimensionsMa trận coverage ISO 25010 + chiều phân rã stakeholder & lifecycle |
hs:security-scan | Deep dependency-risk reference beyond CVE + a 7-stage secret-lifecycle handling checklistTham chiếu rủi ro phụ thuộc sâu hơn CVE + checklist xử lý secret 7 giai đoạn |
hs:contract-test | A schema-drift migration-phase checklistMột checklist migration schema-drift |
hs:plan | Five-hat constructive design elaboration + an ADR-trigger & C4 methodology referenceElaboration thiết kế five-hat + tham chiếu ADR-trigger & C4 |
hs:fix | A "why now" question added to the root-cause diagnosis gateCâu hỏi "vì sao lúc này" thêm vào gate chẩn đoán nguyên nhân gốc |