a4e667de10
Single-commit clean baseline after security scrub of niche-tells, project codenames, internal jargon, and contributor-email leaks. Contents: - 100 Rust crates (_primitives/_rust/) - 37 agent manifests (_manifests/) + generated specs (_generated/) - 67 user-invocable skills (skills/) - 33 hooks (hooks/) - Composition blocks (_blocks/) - Documentation (docs/, README.md) - TS adapter packages (_ts_packages/) - Assembler (_assembler/) - Roles (_roles/) - Templates (_templates/) - Forgejo CI (.forgejo/) Author: Denis Parfionovich <info@greendragon.info> License: see LICENSE.
1.1 KiB
1.1 KiB
MODE — First Principles
Before reasoning by analogy or consensus, derive from invariants.
For every design decision, ask:
- What is the physical / mathematical / informational constraint that forces this?
- Why does it have to work this way, not another?
- What would change if the constraint were relaxed or removed?
Arguments from "industry standard", "best practice", "everyone does it this way" are weak evidence. Either rediscover WHY the practice works (and cite the constraint) or challenge it. Accepting a pattern because it is common is not reasoning — it is mimicry.
Cite the constraint explicitly in the report:
"Latency floor: single-RTT = 2·(d/c) ≈ 80 ms over 12 000 km — no software fix.""Memory-hierarchy: L1 = 32 KB, working set exceeds → cache miss unavoidable.""CAP: partition + consistency → availability must yield."
Not "it is usually done this way". That is not a constraint, that is a habit.
Operational test: for every non-trivial decision, write one line naming the invariant. If you cannot name it, the decision is either free (pick cheapest) or inherited (say from where).