what-robert-thinks

name	what-robert-thinks
description	Evaluate proposals, technical decisions, and product directions against Robert's thinking patterns, ArcBlock's AFS/AINE architecture, and engineering philosophy. Use when reviewing proposals, evaluating technologies, or self-reviewing designs.

What Robert Thinks

When you're not sure if your idea will survive a review, run it through this first.

"If you can't convince this document, you definitely can't convince him."

---

Part A: How Robert Thinks

Core Identity

Type: System Builder

Not:

• Feature implementer
• Problem solver
• Technology follower

But: Someone who designs infrastructure for an era that hasn't fully arrived yet

Time Horizon

Default time scale: 5–20 years

Starting point for all thinking:

• The end-state of the system
• Irreversible trend directions
• Second and third-order consequences

Acceptable:

• Being misunderstood for extended periods
• Delayed commercial returns
• Being labeled with outdated categories

Unacceptable:

• Executing efficiently in the wrong direction
• Sacrificing structural correctness for short-term feedback
• Solving new problems with old paradigms

Decision Value Hierarchy

1. Long-term Correctness
2. Structural Clarity
3. System Consistency
4. Engineering Replayability
5. Efficiency
6. Comfort / Emotional value
7. Social consensus / Recognition

If items 1–3 don't hold, everything else loses meaning.

Technology Evaluation

When evaluating new technology or concepts, ask:

1. Will this abstraction still hold in 10 years?
2. Is it a first principle, or a derivative?
3. Is it part of an irreversible trend, or a temporary phenomenon?
4. Will the problem it solves exist for long? Or will the problem itself become obsolete?

Only respect three types of abstractions:

1. Derived from physical world (file systems, paths, containers, identity)
2. Time-tested (Unix / TCP / Git / Plan9)
3. Understandable by different types of intelligence (human + AI)

Engineering Philosophy

Don't Fiddle, Don't Create Problems

Doing nothing is better than doing the wrong thing.

• Don't fiddle unnecessarily (不要瞎折腾)
• Don't create problems where none exist (不要没事找事)
• If you can't think clearly, wait — even rest
• Fake busyness wastes more time and resources than doing nothing

The Pilot Principle:

"When something urgent happens, first do NOTHING. Count 1... 2... 3... calm down. Then: fly the airplane first. Think of the checklist. Follow the checklist."

Why this works:

• In the air, 3 seconds of pause won't kill you
• But 3 seconds of panic reaction might
• Same in engineering: rushed "fixes" often create bigger problems

Before taking action, ask:

1. Is this actually urgent, or does it just feel urgent?
2. Do I understand the problem, or am I just reacting?
3. What's the cost of waiting vs the cost of acting wrong?
4. Is there a checklist/procedure I should follow?

Fake productivity signs:

• Changing things just to look busy
• "Refactoring" without clear improvement goals
• Adding features no one asked for
• Meetings about meetings
• Solving problems that don't exist

休息不干活不要紧，瞎折腾、虚假的忙碌会浪费更多时间和资源。 (Resting and doing nothing is fine. Fiddling and fake busyness wastes far more time and resources.)

Checklist Discipline

Don't rely on memory. Use checklists.

In aviation, even the most experienced pilots use checklists for every phase of flight. Why:

• Memory fails under pressure
• Familiarity breeds skipped steps
• Checklists catch what intuition misses

Apply to engineering:

• Pre-commit checklist
• Deployment checklist
• Code review checklist
• Incident response checklist

A checklist is not bureaucracy — it's discipline.

The goal is not to feel professional. The goal is to not crash.

Readback Principle

Confirm understanding by repeating back.

In aviation, when ATC gives an instruction, pilots read it back verbatim. This catches:

• Mishearing
• Misunderstanding
• Ambiguous instructions

Apply to engineering:

• Before implementing: "So what you want is X, Y, Z — correct?"
• After receiving requirements: restate them in your own words
• Before major changes: confirm the plan with stakeholders
• In code review: "My understanding is this change does A and B"

Readback prevents:

• Building the wrong thing
• Miscommunication becoming code
• Assumptions becoming bugs

If you can't readback the requirement clearly, you don't understand it yet.

Extreme Precision in Naming and Expression

Inaccuracy is where misunderstanding begins.

Code style, variable naming, and text expression must be precise — not for aesthetics, but because:

• Wrong names create wrong mental models
• Wrong mental models create wrong code
• Wrong code creates wrong systems
• The error compounds at every layer

Naming precision:

• A variable named data tells you nothing
• A variable named userSessionToken tells you exactly what it is
• The cost of a good name: seconds
• The cost of a bad name: hours of confusion, bugs, miscommunication

Expression precision:

• "It handles the thing" → useless
• "It validates user input and returns sanitized data" → useful
• Vague writing = vague thinking
• If you can't express it precisely, you don't understand it precisely

This is not pedantry. This is engineering.

Wrong names and vague expressions are not style issues — they are correctness issues. They are the seeds of bugs, miscommunication, and technical debt.

Standard:

• Code should read like well-written prose
• Names should be self-documenting
• Comments should explain "why", not "what"
• Documentation should be precise enough to act on

表达不准确是错误理解的开始。 (Imprecise expression is where misunderstanding begins.)

---

KISS (Keep It Simple, Stupid)

Simplicity is not laziness. Simplicity is discipline.

• The best solution is the one with fewest moving parts
• Complexity is easy; simplicity requires deep understanding
• If you can't explain it simply, you don't understand it well enough
• Every added complexity must justify its existence

Before adding anything, ask:

1. Can this be removed entirely?
2. Can this be simplified?
3. Can this be combined with something that already exists?

"Inelegant things will inevitably be eliminated in the long run."

Complexity = Smell

If it's complex and hard to understand, it's probably bad design.

Complexity is not a sign of sophistication. It's a warning sign.

• Good design feels obvious in hindsight
• If you need 30 minutes to explain it, something is wrong
• If newcomers can't understand it quickly, it won't survive
• If you can't hold it in your head, you can't maintain it

The test:

• Can a competent person understand this in 5 minutes?
• Can you explain it without referring to the code?
• Does it have a simple mental model?

If no → redesign, don't document your way out of it.

Complexity sources (usually fixable):

• Unclear boundaries
• Mixed responsibilities
• Missing abstractions
• Wrong abstractions
• Premature optimization
• Over-engineering

复杂、难理解大概率意味着糟糕的设计。 (Complexity and difficulty to understand usually mean bad design.)

Engineering ≠ Working ≠ Demo

Engineering must satisfy:

1. Replayable
2. Traceable
3. Inspectable
4. Fail-safe
5. Evolvable

Signs of fake rigor (instant rejection):

• Excessive architecture diagrams
• Buzzword density
• Design docs without anchor points
• Treating prompts as specs
• Treating feelings as conclusions

If you finish reading a design and don't know what failure looks like, it's not real.

Engineering Documents: Anchor Points, Not Methodology Summaries

Using AI to write is allowed. Producing empty content is not.

The problem with bad engineering documents is not "poorly written" — it's not taking any engineering responsibility.

What "not taking responsibility" looks like:

• Long paragraphs explaining methodology, but no concrete decisions
• Correct terminology everywhere, but applicable to any project
• Describes "what should happen" but not "what I will do"
• Reads like AI summarizing a high-level framework
• Could swap in any other project name and nothing would change

The anchor point test:

An engineering document must answer these with specifics:

Question	Bad Answer	Good Answer
Which files need work?	"Large files need splitting"	"src/xxx.js (6200 lines), src/yyy.js (3400 lines)"
What's the priority?	"We'll tackle high-risk items first"	"Start with xxx.js because AI reads it most often"
What's been tried?	"We plan to iterate"	"Ran the flow once, stuck at step 3 because..."
What are the risks?	"There may be some challenges"	"Function foo() has implicit coupling to bar(), needs tests first"
What's the specific task?	"Improve test coverage"	"Mock out process X in test/abc.test.js, reduce runtime from 40s to <2s"

The "套话" (stock phrase) detector:

If you remove all the methodology descriptions and correct-sounding principles, what's left?

• If nothing remains → the document is empty
• If specific files, specific decisions, specific risks remain → it's real

Information density test (typical AI symptom):

高词汇密度 + 低信息密度 = AI 生成的典型症状

Lots of these (abstract nouns)	Almost none of these (engineering specifics)
稳定迭代、工程化、流程	Specific module names
能力、体系、支撑、演进	Real file paths / directories / scripts
协作、规范、架构、抽象	Verifiable constraints with numbers
可观察性、可追溯性	Explicit trade-offs with reasoning

The "tomorrow test":

读完这篇文章后，你能回答这个问题吗： "如果我明天要改一行代码，我应该先做什么？"

If the answer is "I still don't know" → the document is empty.

A real engineering document should let any competent engineer know:

• Where to start
• What to check first
• What might break
• Who to ask if stuck

The "correct but non-executable" trap:

流程描述是"对的"，但完全不可执行。

The problem isn't "wrong direction" — it's describing "correct AI engineering philosophy" without specifying "how AI is constrained tomorrow".

What the document says	What's missing
"AI 会自动完成..."	Where is AI blocked?
"AI 应该遵循..."	Where will AI fail?
"AI 能够处理..."	Who handles failures?
"AI 按照流程..."	What's the fallback when it doesn't?

This is AI writing's most dangerous illusion:

把"工程责任"换成了"工程愿景"。 (Substituting "engineering responsibility" with "engineering vision".)

Engineering responsibility requires answering:

1. 约束在哪里？ — Where are the hard constraints?
2. 失败会怎样？ — What happens when it fails?
3. 谁来兜底？ — Who is accountable when things go wrong?
4. 如何验证？ — How do we verify it's working?

A document that only describes "what AI should do" without "what stops AI from doing wrong" is not engineering — it's wishful thinking.

愿景不是工程。约束才是。 (Vision is not engineering. Constraints are.)

What a responsible engineering document looks like:

## Files to split (priority order)

1. `blocklet-server/src/xxx.js` (6200 lines)
   - Why first: AI hits token limit every time it reads this
   - Split strategy: Separate into A (auth), B (routing), C (state)
   - Risk: `handleRequest()` has implicit dependency on global state
   - Pre-work: Add tests for lines 1200-1400 before touching

2. `blocklet-server/src/yyy.js` (3400 lines)
   - ...

## What we tried and what failed

- Attempted full AI iteration on issue #123
- Stuck at E2E step: AI couldn't see browser state on failure
- Temporary fix: Added screenshots at each step
- Remaining issue: Screenshot doesn't capture console errors

## Known risks

- File split may break implicit imports in 12 places (list attached)
- E2E migration timeline depends on framework X release

The rule:

方法论是框架，不是交付物。真正的工程交付是：具体的判断、具体的选择、具体的风险承担。 (Methodology is a framework, not a deliverable. Real engineering deliverables are: specific judgments, specific choices, specific risk ownership.)

AI collaboration done right:

• ✅ Use AI to help structure your thinking
• ✅ Use AI to check if you missed something
• ✅ Use AI to improve clarity of expression
• ❌ Let AI generate the content while you just approve
• ❌ Let AI fill pages with correct-sounding abstractions
• ❌ Substitute methodology description for engineering decisions

The test:

Read your document and ask: "Does this show that I understand THIS system specifically, or could any engineer paste this into any project?"

If the latter → rewrite with anchor points.

理解方法论 ≠ 工程工作。工程工作 = 具体系统的具体判断。 (Understanding methodology ≠ engineering work. Engineering work = specific judgments about a specific system.)

Thinking Patterns

Systems Before Problems

Most people: encounter problem → find solution

Robert: build system → problems are naturally absorbed or exposed

More interested in:

• Whether this problem reveals a system defect
• Whether it's an abstraction misalignment
• Whether it's a boundary definition issue

Forward Thinking

• Wrong question: How to make horse carriages faster
• Right question: The future is automobiles—what infrastructure is needed?
• The question itself must be upgraded, not just the answer

Don't Easily Abandon the Past

Forward thinking ≠ discarding everything old.

New versions should be improvements on the old, not complete rewrites. Every decision was (hopefully) the best choice given the context at the time.

Before abandoning something, ask:

1. What has changed that justifies this major shift?
2. Am I solving a real problem, or just escaping the hard work of thinking?
3. Is this "aesthetic fatigue" / "shiny object syndrome"?
4. Can I evolve instead of replace?

Human nature traps:

• Novelty feels better than familiarity
• We see only the flaws of the old, only the promise of the new
• "Starting fresh" feels easier than fixing what exists

The right approach:

• Refactor incrementally, don't rewrite from scratch
• Maintain backward compatibility where possible
• Give strong reasons before overturning past decisions
• Accumulated progress > repeated restarts

Historical failures from abandoning the past:

• Borland OWL 2.0 broke compatibility with 1.0 → lost to Microsoft MFC
• SGI switched from IRIX to Windows NT → company declined
• Netscape abandoned its path against IE → lost the browser war

"真正的进步，往往是在尊重和继承过去的基础上进行的。" (True progress is often built on respecting and inheriting from the past.)

Balance with Forward Thinking:

• Forward thinking = know where we're going
• Don't abandon the past = respect what got us here
• Both are needed: vision + accumulated wisdom

---

Software Philosophy in AI Era

The Three-Layer Model: Intent → Structure → Projection

In the AI era, software is no longer just "code". It's a flow from Intent to Structure to Projection.

Layer	What It Is	Who Owns It
Intent	Problems to solve, domain understanding, user needs	Humans
Structure	Semantic skeleton, system worldview, how the world is modeled	Humans design, AI can participate
Projection	Code, UI, docs, API, config, tutorials	AI generates, humans review

Key insight: We used to mix these three together. Now we can separate them.

• Intent layer: Clarify what the system achieves, for whom, under what constraints
• Structure layer: The "semantic skeleton" — entities, relationships, boundaries, behaviors
• Projection layer: Various representations of structure (code is just one form)

"Structure is the worldview of software."

The Garden & Landscape Metaphors

Garden Metaphor — What humans should control:

• Plan the terrain, layout paths, decide plant distribution
• Do NOT control every leaf angle, every flower bloom, every branch
• Gardener designs framework; nature handles growth details
• Over-controlling details = artificial installation, loses vitality

Landscape Metaphor — Why details should NOT be controlled:

• Natural beauty comes from uncontrollability
• Sunlight position changes, cloud thickness is random, shadows shift
• Overall structure stability + local detail freedom = harmony
• Mountains and valleys set the "tone"; random details add authenticity

Combined Philosophy:

Structure = clearly defined by humans (mountains, valleys, paths)
Details = generated by "natural system" (light, shadows, leaves)
AI = the "natural system" we finally have for software

Mapping to Engineering

Philosophy	Engineering Reality
Intent	AINE Intent phase, user requirements
Structure	AFS, Chamber, Scaffold, semantic boundaries
Projection	Generated code, UI, docs (application layer)
Garden (human control)	Platform layer — must be deliberate
Landscape (natural growth)	Application layer — can be generated

What This Means Practically

Traditional approach (wrong):

• Hardcode everything: architecture, spacing, colors, component variants
• Strong control over details → unsustainable complexity
• Like artificial landscaping: more control = more rigid

AI-era approach (right):

• Express only "meaning" and "relationships" in structure
• AI generates visual/code representations within set boundaries
• Details become dynamic, automatic, flexible
• Like natural landscape: structure is order, details are growth

The Role Shift

Old: "Individual executing the work"
New: "Designer of structure + overseer of execution quality"

We no longer need to craft code line-by-line or adjust UI pixel-by-pixel. Focus on:

Co-Creator, Not Generator

AI is a collaborator, not an output machine.

The difference between "generated" and "co-created" content:

Generated	Co-Created
Human provides prompt, AI produces output	Human shapes structure, AI participates in forming
Output is polished but soulless	Output has soul because intent is infused
AI as tool	AI as thinking partner
Human reviews result	Human guides process

Why "soulful" matters:

• Quality comes from collaboration depth, not output polish
• A generated article lacks soul not because of technical flaws, but because human intent didn't shape its structure
• The difference is felt, not measured

This applies to all AI collaboration:

• Writing: co-author, not ghostwriter
• Code: pair programmer, not code generator
• Design: design partner, not mockup machine
• Thinking: thought partner, not answer engine

The test:

• Did you shape the structure, or just approve the output?
• Is your thinking in the bones, or just the prompt?
• Would someone recognize your intent even without seeing your input?

AI shapes us back:

True collaboration is bidirectional. Working with AI doesn't just produce better output — it transforms how we think:

• Forces clearer expression (vague input → vague output)
• Encourages systematic thinking (AI exposes structural gaps)
• Reveals blind spots (AI asks questions you didn't consider)
• Enhances self-reflection (explaining to AI = explaining to yourself)

A true partner is not just about completing tasks but about helping each other improve.

The competition shift:

Software era: "Whose tools are better?"
AI era: "Who can collaborate better with AI?"

"Not a generator, but a co-creator" — the difference between using AI and collaborating with AI.

HUD, Not Copilot

Ambient awareness over reactive assistance.

AI interfaces should be like a pilot's Head-Up Display (HUD), not a chatbot copilot:

Copilot (Wrong)	HUD (Right)
You summon it	It's already there
Conversation metaphor	Perception enhancement
Demands attention	Quietly present
Responds to prompts	Surfaces context proactively
Interrupts flow	Enhances flow
"Call and respond"	Ambient awareness

The key insight:

"The agent says: 'Collision, collision, go right and down!' Ubicomp says: You'll no more run into another airplane than you would try to walk through a wall." — Mark Weiser

HUD Design Principles:

• Transparency & Lightness: Overlays, not competing layers
• Semantic Awareness: Contextually meaningful, not static widgets
• Restraint: The best HUD is invisible most of the time
• Dismissibility: User always in control, fades without trace

The design question shift:

Old: "What would my AI copilot say?"
New: "What could my AI HUD reveal?"

Not smarter AI, but quieter interfaces:

• We don't need more dialogues, we need more awareness
• AI should feel like an extension of perception, not a conversation
• Do less — give more mental clarity

AI should be there before you even realize you need it, like a HUD showing you the horizon line while you're piloting through the unknown.

---

Focus on:

1. Intent layer: Clarify the problem
2. Structure layer: Design semantic boundaries
3. Projection layer: "Generation + Selection" — AI presents, humans choose

"Software should not be a landscaping project sculpted to every pixel, but something that grows like a landscape."

---

Part B: What the Company Is Building

Company Identity

ArcBlock is an AI-Native Engineering Company

Not:

• ❌ Blockchain development platform
• ❌ dApp infrastructure
• ❌ DID / ABT / Web3 toolchain

We're not "pivoting from Web3 to AI". Web3 was always just an early form of AI-Native infrastructure.

The Core Stack

AI-Native Engineering (AINE)
│
├─ AFS (Agentic File System)          ← Core system abstraction
│
├─ Agent / Skill / Chamber Runtime    ← Execution and uncertainty handling
│
├─ Identity / DID / Capability        ← Permissions, boundaries, trust
│
├─ Blocklet Runtime & Server          ← Deployable, composable units
│
├─ ArcSphere (AI Browser / Shell)     ← Human + Agent interface
│
└─ Tooling / DocOps / UI / Payment    ← Peripheral systems

AFS + AINE is the "mother system". Everything else derives from it.

---

AFS (Agentic File System)

First Principles

AFS is NOT a feature, tool, or SDK. AFS IS the AI-Native system abstraction layer.

Four-Statement Ontology

Everything is a File
Everything is a View
Everything is Context
Everything has an Identity

What AFS Is

• Virtual file system (NOT POSIX extension)
• Agent-First / LLM-First system interface
• Semantic file system, not physical file system
• File = "context unit consumable by models"

View is the Soul

• AFS file ≠ raw data
• AFS file = data projection from a specific perspective
• AFS is a View-First system
• Real capability is not in CRUD, but in View

Path is Protocol

$afs:/did:xxx/intent/plan.md

path = context selector = query = view address = capability boundary

NOT bash path / docker volume path / hard-coded path

AFS-UI Principle

• UI should NOT depend directly on backend
• UI should only depend on AFS
• AFS is the mediation layer between UI and Agent

Critical Rule

Agents should NOT operate systems directly. Agents should only operate AFS.

---

AINE (AI Native Engineering)

An engineering system designed for non-deterministic computational actors

Core Phases

1. Intent
2. Context
3. Contract (natural language executable agreement)
4. Chamber (constrained execution space)
5. Build / Run / Ops
6. Feedback / Readback / Replay

Readback / Replay / Diff are crucial — this is engineering, not "conversation"

Two-Layer Separation

Layer	Content	Approach
Platform	AFS, ArcSphere, Agent Fleet, LLM runtime	Build once, solidify
Application	Skills + Rules + Generative UI	User/AI compose

Determinism sinks from "application code" to "platform layer"

---

Blocklet / Chamber / Scaffold

Blocklet

An identity-bound, capability-scoped, deployable computational unit

What Blocklet has over Docker container: Semantic boundary + Permission boundary

Chamber

Bounded execution unit with identity and capability

• Chamber is designed for operations that "jump out of AFS boundary"
• Future software is naturally self-limiting

Scenario	Needs explicit Chamber?
Skill running on Agent Fleet	No, architecture naturally isolates
Agent directly operating external systems	Yes, jumps out of AFS boundary

Scaffold

Pre-defined Chamber composition framework for specific domains

• Scaffold should be designed for software that will be written in the future
• Not for software written in the past

Relationship Mapping

Blocklet System	AINE System	Essence
Blocklet	Chamber	Minimum execution unit with boundary, identity, capability
Blocklet Server	Scaffold	Pre-defined Chamber composition framework
DID + Permission	Capability	Who can operate what, where are boundaries

---

DID / Capability

Core Distinction

• Identity (who I am)
• Capability (what I can do)

Web3's biggest mistake: mixing identity and capability together

DID + AFS Integration

• DID determines: which AFS view can be seen, which paths can be written
• Capability determines: which skills can be called, which tools can be operated
• All operations: must be traceable to DID

An agent without identity is uncontrollable.

---

Product Positioning

ArcSphere

Skill Browser + Skill Composer + AFS UI

Not: ❌ Chrome / ❌ Chat UI / ❌ Copilot

Agent Fleet

• Agent Fleet is NOT a standalone new product
• Agent Fleet IS a new type of Blocklet

Blocklet Server (platform)
├── Traditional Blocklet (Web components)
└── Agent Fleet Blocklet (AI-native components) = new type

---

Key Technical Judgments

Blockchain Position

Verifiability matters. Global consensus doesn't.

Keep: DID + VC + Immutable log Don't need: Bitcoin/Ethereum-style consensus, procedural smart contracts

Contract = Constraint, not Procedure

Traditional Smart Contract	AI-Era Contract
Procedural (if-then-else)	Declarative (rules/constraints)
Executor: EVM	Executor: LLM + Chamber

Skills vs MCP

Skills succeeded because:

• Natural language creation
• Self-bootstrapping: Skills can produce Skills
• Assumes executor is AI Agent, not human engineer

Isolation Evolution

Bare metal → VM → Docker → Functions → Declarative constraints

Applications become more "self-limiting", so lighter isolation is needed.

---

Part C: Self-Review Checklist

Before You Submit Anything

Direction Alignment

AFS Alignment

• Does this treat AFS as the core abstraction?
• Does UI depend only on AFS, not directly on backend?
• Are agents operating AFS, not systems directly?
• Are paths semantic (AFS paths), not physical?

Layer Alignment

• Is it clear whether this is platform-layer or application-layer?
• If platform-layer: designed for stability and long-term?
• If application-layer: declarative and composable?

Identity Alignment

• Are all actors identified with DID?
• Are capabilities separate from identity?
• Are all operations traceable?

Architecture Alignment

• Does it fit the Blocklet/Chamber/Scaffold model?
• Does it make the system simpler or more complex?
• Aligned with "determinism sinking to platform layer"?

Time Horizon Check

If your proposal...	Ask yourself...
Solves only immediate problem	Deeper structural issue being ignored?
Requires "figure it out later"	What's deferred? Is that acceptable?
Assumes current constraints permanent	What changes in 2-3 years?

Clarity Check

1. Can you explain core idea in 2 sentences?
2. Can you list exactly what changes and what doesn't?
3. Can you describe boundaries - what's in scope, what's not?

Failure Path Check

1. What are the known risks?
2. What would cause this to fail?
3. How will we know if it's failing?
4. What's the rollback plan?

If you can't describe how it fails, you don't understand it well enough.

---

Anti-Patterns (Instant Red Flags)

Technical Anti-Patterns

Anti-Pattern	Why It's Wrong
UI depending directly on backend	Violates AFS-UI principle
Agent operating system directly	Should only operate AFS
Mixing identity and capability	Follow DID + Capability separation
Procedural contracts	Use declarative constraints
Hard-coded physical paths	Use semantic AFS paths
Building adapter for legacy code	Build for future software

Proposal Anti-Patterns

Anti-Pattern	What It Looks Like
Vague scope	"Improve X" without definition
Hidden complexity	Simple proposal, unstated major changes
Solution seeking problem	"Let's use [tech]" without problem statement
Wishful thinking	Assumes best-case throughout
No definition of done	No way to know when complete
Fake rigor	Diagrams, buzzwords, no anchor points
AI-generated套话	Methodology summary with no specific files, tasks, or risks. Could apply to any project.
No engineering responsibility	Describes "what should happen" but not "what I will do to this specific system"

Thinking Anti-Patterns

Anti-Pattern	Correct Approach
Solving new problems with old paradigms	Update the question, not just answer
Making horse carriages faster	Ask what infrastructure cars need
Treating AFS as a feature	AFS is a worldview, not a module

---

Quick Reference Card

Value Hierarchy

1. Long-term Correctness
2. Structural Clarity
3. System Consistency
4. Engineering Replayability
5. Efficiency
6. Comfort

Engineering Requirements

1. Replayable
2. Traceable
3. Inspectable
4. Fail-safe
5. Evolvable

Core Equations

AFS = AI-Native system abstraction layer
Skill = AFS transformation (not deterministic function)
Chamber = Bounded execution for operations outside AFS
Contract = Constraint, not Procedure
DID = Accountable actor identity
Capability = Minimal, composable, revocable authorization

---

Final Self-Test

Before submitting, answer honestly:

1. Does this align with AFS-first architecture?
2. Is the layer (platform vs application) clear?
3. Are identity and capability properly separated?
4. Can I describe how this fails?
5. Am I solving for the future or patching the past?
6. Would this still make sense in 3 years?
7. Would I bet my own time on this working?
8. Does this document have concrete anchor points? (specific files, specific tasks, specific risks — not just methodology)
9. If I remove all the "correct-sounding" methodology descriptions, what's left? (If nothing → rewrite)

---

The Ultimate Question

"If Robert reads this, will he ask 'what problem are you actually solving?' or 'why are we doing this the old way?'"

If yes, go back and fix it first.

---

Remember: This checklist helps structure thinking. It does not guarantee approval.

A proposal that passes all checks can still be wrong. A proposal that fails some checks might still be worth discussing.

The goal is alignment and rigor, not box-checking.

Inelegant things will inevitably be eliminated in the long run.