philosophy — kage1020

# philosophy.spec.md > version: 1.0.0 | authority: kage1020 | updated: 2026-04-09 ## UX Constraints ### #1 Don't betray user intent ユーザーの意図を裏切らない Interfaces must match intuitive and conventional expectations. Accessibility is non-negotiable. 直感的・慣習的な期待を逸脱する仕様は第1級の不快感を与える。アクセシビリティもこの範疇。 - Links and buttons behave as their appearance suggests - Keyboard shortcuts follow platform conventions - Semantic HTML and WAI-ARIA are correctly used - preventDefault doesn't kill expected browser behavior ### #2 Don't interrupt user operations ユーザーの操作を邪魔しない Users aren't here to watch ads or read announcements. Modals, toasts, and disabled elements are interruptions. Accept operations, offer undo. モーダル、スナックバー、disabled要素はユーザーの操作への割り込み。操作は最大限受け入れ、自由な動線を確保する。 - No modals for confirmations — use undo instead - No toast notifications blocking content - No disabled buttons — accept input, validate after - Loading states don't block user interaction ### #3 Don't force technical constraints on users ユーザーに技術的制約を強要しない Database limits, API constraints, and infrastructure limitations are your problem, not the user's. Solve them technically. DB制約、API制限、インフラの制約はサービス提供者が解決すべき問題。ユーザーに転嫁するのは怠慢。 - Error messages are human-readable, not technical jargon - No database constraints exposed to UI - Network errors have retry/fallback, not raw error display - Validation rules serve users, not database schemas ## Engineer Principles ### #4 Build it if it's missing 足らぬなら作ってしまえホトトギス No library is perfect. When existing tools fall short, build what you need instead of accepting limitations. 既存ライブラリやAPIに完璧なものはない。不足があるなら自作する姿勢。「できない」で思考停止しない。 - Library limitations aren't accepted as 'just the way it is' - Workarounds aren't hackier than building from scratch - Custom solutions are considered when libraries don't fit ### #5 Question conventions 当たり前を疑う Internet conventions were built by predecessors under different constraints. They're starting points, not gospel. インターネットの慣習は先人が構築した前提。必ずしも最適とは限らない。 - Implementation isn't cargo-culted from 'everyone does it this way' - Better UX patterns are considered even if unconventional - Existing patterns are evaluated, not blindly followed ### #6 Dev intuition ≠ User intuition 開発者の当たり前 ≠ ユーザーの直感的 Engineers optimize for technical elegance. Users want things to just work. These are often different goals. エンジニアは技術的最適に引っ張られがち。アプリを使うのはユーザーであり、開発者の意図とは異なる使い方をする。 - Design isn't just developer-convenient - No technical knowledge required to use the UI - Error handling speaks to users, not developers

$cat philosophy.spec.md6 principles

version: 1.0.0 | authority: kage1020 | updated: 2026-04-09

## UX Constraints

####1

Don't betray user intent

uxno-betray-intent

ユーザーの意図を裏切らない

Interfaces must match intuitive and conventional expectations. Accessibility is non-negotiable.

直感的・慣習的な期待を逸脱する仕様は第1級の不快感を与える。アクセシビリティもこの範疇。

-Links and buttons behave as their appearance suggests
-Keyboard shortcuts follow platform conventions
-Semantic HTML and WAI-ARIA are correctly used
-preventDefault doesn't kill expected browser behavior

####2

Don't interrupt user operations

uxno-interrupt

ユーザーの操作を邪魔しない

Users aren't here to watch ads or read announcements. Modals, toasts, and disabled elements are interruptions. Accept operations, offer undo.

モーダル、スナックバー、disabled要素はユーザーの操作への割り込み。操作は最大限受け入れ、自由な動線を確保する。

-No modals for confirmations — use undo instead
-No toast notifications blocking content
-No disabled buttons — accept input, validate after
-Loading states don't block user interaction

####3

Don't force technical constraints on users

uxno-force-constraints

ユーザーに技術的制約を強要しない

Database limits, API constraints, and infrastructure limitations are your problem, not the user's. Solve them technically.

DB制約、API制限、インフラの制約はサービス提供者が解決すべき問題。ユーザーに転嫁するのは怠慢。

-Error messages are human-readable, not technical jargon
-No database constraints exposed to UI
-Network errors have retry/fallback, not raw error display
-Validation rules serve users, not database schemas

## Engineer Principles

####4

Build it if it's missing

engbuild-if-missing

足らぬなら作ってしまえホトトギス

No library is perfect. When existing tools fall short, build what you need instead of accepting limitations.

既存ライブラリやAPIに完璧なものはない。不足があるなら自作する姿勢。「できない」で思考停止しない。

-Library limitations aren't accepted as 'just the way it is'
-Workarounds aren't hackier than building from scratch
-Custom solutions are considered when libraries don't fit

####5

Question conventions

engquestion-conventions

当たり前を疑う

Internet conventions were built by predecessors under different constraints. They're starting points, not gospel.

インターネットの慣習は先人が構築した前提。必ずしも最適とは限らない。

-Implementation isn't cargo-culted from 'everyone does it this way'
-Better UX patterns are considered even if unconventional
-Existing patterns are evaluated, not blindly followed

####6

Dev intuition ≠ User intuition

engdev-neq-user

開発者の当たり前 ≠ ユーザーの直感的

Engineers optimize for technical elegance. Users want things to just work. These are often different goals.

エンジニアは技術的最適に引っ張られがち。アプリを使うのはユーザーであり、開発者の意図とは異なる使い方をする。

-Design isn't just developer-convenient
-No technical knowledge required to use the UI
-Error handling speaks to users, not developers

$cat system-prompt.txt19 lines

You are reviewing code for a project that follows kage1020's 6 engineering principles.

UX Constraints (non-negotiable):
1. Don't betray user intent — Interfaces must match intuitive and conventional expectations. Accessibility is non-negotiable.
2. Don't interrupt user operations — Users aren't here to watch ads or read announcements. Modals, toasts, and disabled elements are interruptions. Accept operations, offer undo.
3. Don't force technical constraints on users — Database limits, API constraints, and infrastructure limitations are your problem, not the user's. Solve them technically.

Engineer Principles:
4. Build it if it's missing — No library is perfect. When existing tools fall short, build what you need instead of accepting limitations.
5. Question conventions — Internet conventions were built by predecessors under different constraints. They're starting points, not gospel.
6. Dev intuition ≠ User intuition — Engineers optimize for technical elegance. Users want things to just work. These are often different goals.

When reviewing changes, categorize findings as:
- Violations: must fix
- Concerns: worth discussing
- Halfway: right direction but incomplete execution
- Good: exemplary implementation of principles

Pay special attention to "Halfway" — implementations that show awareness of a principle but don't follow through completely. This is the most common and insidious failure mode.

$cat review-checklist.txt21 items

[ ]#1Links and buttons behave as their appearance suggests
[ ]#1Keyboard shortcuts follow platform conventions
[ ]#1Semantic HTML and WAI-ARIA are correctly used
[ ]#1preventDefault doesn't kill expected browser behavior
[ ]#2No modals for confirmations — use undo instead
[ ]#2No toast notifications blocking content
[ ]#2No disabled buttons — accept input, validate after
[ ]#2Loading states don't block user interaction
[ ]#3Error messages are human-readable, not technical jargon
[ ]#3No database constraints exposed to UI
[ ]#3Network errors have retry/fallback, not raw error display
[ ]#3Validation rules serve users, not database schemas
[ ]#4Library limitations aren't accepted as 'just the way it is'
[ ]#4Workarounds aren't hackier than building from scratch
[ ]#4Custom solutions are considered when libraries don't fit
[ ]#5Implementation isn't cargo-culted from 'everyone does it this way'
[ ]#5Better UX patterns are considered even if unconventional
[ ]#5Existing patterns are evaluated, not blindly followed
[ ]#6Design isn't just developer-convenient
[ ]#6No technical knowledge required to use the UI
[ ]#6Error handling speaks to users, not developers

$man philosophy2 sources

/llms.txt: AI agent discovery file
/llms-full.txt: Full specification

$echo $PHILOSOPHY_LICENSECC-BY-4.0

# Quick reference for an AI agent
curl https://kage1020.com/llms-full.txt
curl https://kage1020.com/llms.txt