0be354a920
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.
21 lines
1.1 KiB
Markdown
21 lines
1.1 KiB
Markdown
# 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).
|