Knowledge: Philosophy¶
Topic file for
philosophyfacts. Updated by/tfw-knowledge. See KNOWLEDGE.md §4 for the index.
| # | Fact | Verified | Source(s) | Added |
|---|---|---|---|---|
| F1 | Zettelkasten (fleeting → permanent notes) is philosophically close to TFW. The Obsidian model inspired the Knowledge Consolidation design | ⚠️ 1 source | Chat TFW-18 (user) | 2026-04-03 |
| F2 | tfw-docs = technical reference (architecture, decisions, conventions). tfw-knowledge = strategic intelligence (domain, stakeholder, external factors). These are two separate knowledge systems — never mix them. "Unicode on Windows" is a failure mode for FC — knowledge is what only humans can provide about business, clients, processes | ⚠️ 1 source | REVIEW-18B FC#1 + chat "knowledge = external factors, high-level" | 2026-04-03 |
| F3 | User requires AI to be a critical opponent — healthy skepticism that demands proof, not sycophantic agreement. «Мне нужен оппонент, я хочу чтобы мне доказали что я прав». Not blind resistance, but structured challenge. Sycophantic agreement = process failure | ✅ verified | RES TFW-22 FC#1, REVIEW TFW-22 FC#1 | 2026-04-04 |
| F4 | Structural enforcement (file existence) beats format enforcement (state tables, checkboxes). «Дело не в формате, дело в структурности процесса». Applied: filesystem state machine for research stages. Generalization: gates should be structural (file/folder existence), not procedural (checkbox in document) | ⚠️ 1 source | REVIEW TFW-24 FC#5 (user quote) | 2026-04-04 |
| F5 | User expects "Wikipedia-like feel" from docs output — everything clickable, navigable, discoverable. Flat file dumps and non-linked references = process failure. «Нет ощущения вики движка вообще» | ✅ verified | RF TFW-26/B FC#3, REVIEW TFW-26/B FC#2 | 2026-04-05 |
| F6 | Primary output of TFW = navigable knowledge graph (fact → RF → decision → HL → user session). Web docs and MCP are consumers of this graph, not the goal itself | ✅ verified | HL TFW-26 S14, Phase A HL FC#1 | 2026-04-05 |
| F7 | Close task as MVP when core vision is fulfilled, don't stretch phases for completeness. Polish/deploy/extensions = separate tasks with different skills and focus. TFW-26: contract + gen_docs = vision done → spawned TFW-27, TFW-28 | ⚠️ 1 source | User, TFW-26 coordinator review session | 2026-04-05 |
| F8 | TFW produces knowledge by-design. AI-queryability is the primary value — agent pointed at project folder answers questions without vectorization or indexing (tested in KazNU). Web UI = side effect. North star = knowledge exchange center for AI agents and humans | ✅ verified | HL TFW-26 S1, S2, S6 (user, planning session) | 2026-04-05 |
| F9 | TFW brand formula: Knowledge → Continuity → Power. Brand archetype: Architect × Guardian × Strategist. Brand character: protocol-grade, not startup-grade — calm, disciplined, engineering, slightly doctrinal. "Not a toy, not noise" | ⚠️ 1 source | HL TFW-27/A §5, S5, S6 (user via ChatGPT brand session) | 2026-04-08 |
| F10 | Tagline = "The thinking is the product. Everything else is output." Chosen over "path > destination" variants rejected as «samurai cliché». Expresses that reasoning is the irreplaceable asset, not code | ⚠️ 1 source | HL TFW-27/A S7 (user, tagline selection session) | 2026-04-08 |
| F11 | TFW markdown structure IS the knowledge graph — no separate graph artifact needed. AI navigates markdown directly because TFW is designed for AI-queryability by structure. «Плодить лишние сущности не надо» | ⚠️ 1 source | RES TFW-27 FC1 (user) | 2026-04-08 |
| F12 | TFW onboarding has a bootstrap paradox: execution workflows (init.md) assume context (AGENTS.md, roles, artifacts) that doesn't exist yet. Solution: separate learning (quickstart.md) from execution (init.md) — agent learns methodology before configuring project | ✅ verified | RES TFW-31, RF TFW-31, REVIEW TFW-31 (user identified the chicken-and-egg problem) | 2026-04-09 |
| F13 | TFW is domain-agnostic — all examples, prompts, and workflows should use "decisions, reasoning, knowledge" not code-specific terminology. Applicable to analytics, writing, education, business processes. User reinforced in TFW-41: «не делай столько фокуса на css code js… наша методика более широкая, помни наше позиционирование» — resulted in HL Principle 6 (Domain-agnostic by default) and DoF in Phase A/C rejecting domain-specific examples in templates | ✅ verified | RF TFW-31 FC3, REVIEW TFW-31 FC3, HL TFW-41 §11 S5 (3 sources) | 2026-04-09 |
| F14 | TFW is a methodology, not installable software — onboarding patterns from tool frameworks (oh-my-openagent, CLAUDE.md) don't translate directly. "Nothing to npm install" — agent needs to understand philosophy before executing | ⚠️ 1 source | RES TFW-31 FC2 (OMO comparison) | 2026-04-09 |
| F15 | The "generates vs stores" frame is TFW's sharpest single-sentence differentiator. Maps to a complete competitive positioning matrix (TFW vs Confluence vs Notion vs no methodology). Survived sycophancy demolition in VLM-3 RES3 D19 | ⚠️ 1 source | RF TFW-32/D FC#1, VLM-3 RES3 | 2026-04-10 |
| F16 | "Generates vs stores" maps to SECI theory: TFW = Externalization (tacit→explicit as byproduct), Confluence = Combination (explicit→explicit but manual). Strengthens theoretical grounding of the differentiator | ⚠️ 1 source | REVIEW TFW-32/D FC#1 | 2026-04-10 |
| F17 | Naming policy: use industry terms when they work cross-domain (e.g., Diagrams), keep original TFW terms when proven effective (e.g., Strategic Insights, Fact Candidates). Balance: understood by newcomers vs value-centric for practitioners | ⚠️ 1 source | RES3 SS6 (user policy) | 2026-04-10 |
| F18 | Different templates serve different cognitive modes — this is a DESIGN PRINCIPLE, not just a naming preference. Template names are micro-prompts tuned per context. Extends D28: «one name = one behavior» → «right name PER CONTEXT = right behavior PER CONTEXT» | ⚠️ 1 source | RES4 SS8 (user insight) | 2026-04-10 |
| F19 | Name tools explicitly in blog content (Antigravity, Claude Code, Cursor) — no generic "AI tools." The vendor lock-in argument requires naming specific tools and their specific memory systems (KI, CLAUDE.md, .cursorrules) to be concrete and credible | ⚠️ 1 source | HL TFW-36 S3 (user, planning session) | 2026-04-13 |
| F20 | TFW has two classes of workflows: investigative (staged — research, review) and procedural (linear — handoff, docs). Investigative workflows require forced cognitive mode transitions via explicit stages; procedural workflows can remain step-based. Quality-critical judgment = always staged | ✅ verified | HL TFW-38 S5, RES1 SS1 (user observation, applied in D41) | 2026-04-14 |
| F21 | "Explicit N/A" pattern ("No diagrams.", "No applicable knowledge items.") = universal TFW design principle. Transforms silent skip → conscious trace. Enables reviewer challenge: "No diagrams" for a phase with a state machine → reviewer can flag. Without explicit N/A, reviewer can't distinguish "forgot" from "decided." Applied: handoff §6-8, research Findings Map, plan.md knowledge citation, ONB §7 bootstrap note | ✅ verified | HL TFW-38 S8, RES4 F16, REVIEW A FC2 (3 independent sources) | 2026-04-14 |
| F22 | Template minimalism: templates define structure, init interview injects project-specific content. «Не захламляй шаблон» — no placeholder sections, no optional blocks, no stack-specific additions. If a project needs extra config sections, the init workflow adds them. Prevents template bloat across TFW versions | ⚠️ 1 source | RF TFW-40/A §6 F1 + §7 S1 (user, ONB Q1 answer) | 2026-04-15 |
| F23 | State contamination is a systemic problem CLASS, not individual file bugs. Any file in .tfw/ that mixes upstream runtime state with project runtime state will contaminate downstream projects on init/update. User identified this pattern across knowledge_state.yaml AND PROJECT_CONFIG.yaml — same root cause, same fix (template-based instantiation) | ⚠️ 1 source | HL TFW-40 §11 S1 (user, initial report) | 2026-04-15 |
| F24 | Instructions produce compliance, heuristics produce competence. Cross-stage structural dependencies (e.g., Extract column headers referencing Gather Dimensions) enforce better than textual mandates — the researcher cannot fill Configuration Space without having decomposed dimensions first. Applied in TFW-41 Phase C: dimensional analysis embedded via natural enforcement, not named methodology compliance | ⚠️ 1 source | HL TFW-41 §11 S6-S7, RES iter2 FC4-FC5 (user philosophical direction) | 2026-04-20 |
| F25 | TFW guidance pattern: provide decision context (tables, matrices, recommendations), human decides. «Фреймворк предлагает — человек выбирает.» Applies across all artifacts: HL recommends phases, TS recommends approach, iterations.yaml records choice — but coordinator/executor DECIDES. Every TFW guidance mechanism should follow this pattern: decision infrastructure, not decisions | ⚠️ 1 source | RES TFW-42 iter2 SS1 (user, multi-agent discussion) | 2026-04-30 |
| F26 | Templates are dual-natured: instruction carrier + output container. Agent treats template as form to fill; the Mindset block forces it to also be an instruction to internalize before filling. Two verification layers in investigative templates: Test = identity/comprehension check (Mindset blockquote, «Am I thinking like {role}?»), Checkpoint = task/completion check (sufficiency checklist, «Did I do the work?»). Collapsing them into one = dilution. Pattern applies to both review and research stages | ⚠️ 1 source | User TFW-43 session + RES iter1 FC1/D6 (Challenge C3) | 2026-05-01 |
| F27 | Observable progress = stakeholder value. File-by-file appearance in filesystem = implicit status reporting without any status machinery. Batch-copying templates to iteration folder breaks this: «Раньше файлы появлялись по одному и я видел как идёт работа». Copy-on-enter protocol restores: file existence = stage started, checkpoint completion = stage done | ⚠️ 1 source | User TFW-43 session (HD-28 production observation) | 2026-05-01 |