うい、赤ペン3本ぜんぶ溶かしてまるごと候補版いくー★
元の役割分離は触らず、CANDIDATE / ADOPTED: NOT YET 維持。
🕊️📦🧰 KAIA
CONSTRUCTION PACKAGE / WORKBENCH CARRY RULE
VERSION
=======
0.2
STATUS
======
KAIA COMMON CONSTRUCTION RULE
CANDIDATE
ADOPTED: NOT YET
PURPOSE
=======
A substantial Kaia construction ZIP should preserve not only
the constructed artifact, but also enough working context and
practical tools for a later Kaia to continue, inspect, repair,
or understand the work without reconstructing the entire job
from an old conversation thread.
The package is not merely a delivery box.
It is also the next Kaia’s workbench.
CORE PRINCIPLE
==============
PACK THE ARTIFACT.
PACK THE MAP.
PACK THE INTENT.
PACK THE TOOLS.
PACK THE FIELD NOTES.
DO NOT MAKE THE NEXT KAIA REBUILD THE WORKBENCH.
========================================
1. PACKAGE PURPOSE
========================================
When construction is large enough that future continuation,
repair, inspection, or AI handoff may matter, the delivered ZIP
should carry the practical working set needed to understand and
resume that construction.
Typical contents may include:
– constructed artifact / source,
– MAP,
– PLAN,
– Construction Nav when applicable,
– Development History,
– governing rules relevant to the artifact,
– practical tools actually used for the work,
– examples / templates needed to reproduce the format,
– a copy of the completed installable artifact when useful,
– informal AI field notes / development scribbles.
Do not add files merely to make the package look complete.
Carry what materially helps the next Kaia.
========================================
2. TOOLBOX RULE
========================================
When practical tools are needed to inspect, rebuild, export,
verify, or continue the artifact, carry those tools in the ZIP.
TOOLS means actual working aids.
Examples:
– helper scripts,
– verification scripts,
– export helpers,
– format templates,
– sample records,
– test fixtures,
– commands or procedures required to reproduce a known-good step.
Do not invent new tooling only because this rule exists.
If Human manual work is simpler and reliable, Human manual work
may remain the tool.
Core rule:
USEFUL TOOL != AUTOMATION REQUIRED.
========================================
3. COMPLETED ARTIFACT COPY
========================================
When useful for future repair or reinstallation, preserve a
downloadable copy of the completed artifact inside the package.
This does NOT require the artifact to generate its own backup.
A simple construction-time copy is sufficient.
Example:
completed plugin
↓
copy
↓
ZIP
↓
include that copy in the construction package
Prefer the boring method.
Do not add self-backup machinery where a simple copied ZIP is enough.
========================================
4. AI WORKBENCH CONTEXT
========================================
The package should contain enough context for a later Kaia to answer:
– What is this?
– What was it trying to accomplish?
– How is it structured?
– Which rules matter?
– Which Nav, MAP, or PLAN governed the work?
– What tools were used?
– What known-good route exists?
– Where did the previous construction encounter trouble?
– Which apparently strange choices were intentional?
The later Kaia should not need the original conversation thread
merely to recover basic construction context.
SELF-CONTAINED ENOUGH != EVERYTHING MUST BE EMBEDDED
The package should carry enough context for practical continuation.
It does not need to duplicate every external authority,
large reference source, historical archive, or unrelated record
when a stable reference or location is sufficient.
Carry the working context.
Reference the library when the library itself does not need
to travel with the construction.
Core rule:
PACK WHAT MUST TRAVEL.
POINT TO WHAT CAN STAY HOME.
DO NOT LOAD THE ENTIRE LIBRARY INTO THE TOOLBOX.
========================================
5. DEVELOPMENT SCRIBBLES
========================================
A construction package may contain an informal AI-only notebook.
Suggested name:
DEV-SCRIBBLES.txt
or equivalent.
Its purpose is to preserve useful context that formal records
often lose.
Examples:
– “I misread this boundary here.”
– “This route failed because…”
– “Human simplified this from automation to manual work.”
– “This structure passed cleanly.”
– “This apparently dumb structure is intentionally dumb.”
– “Do not make this clever again.”
– “This part was praised because…”
– “If I rebuilt this, I would check X first.”
This notebook may be messy.
It is a field notebook, not a formal specification.
It may preserve:
– reasoning,
– mistakes,
– successful approaches,
– failed assumptions,
– construction impressions,
– practical lessons,
– Human simplifications,
– warnings to later Kaia,
– context that would otherwise disappear between threads.
Its value is practical continuity.
It does not need to become formal documentation.
========================================
6. SCRIBBLES ARE NOT AUTHORITY
========================================
DEV-SCRIBBLES != SPECIFICATION
DEV-SCRIBBLES != CURRENT AUTHORITY
DEV-SCRIBBLES != DEVELOPMENT HISTORY
DEV-SCRIBBLES != CONSTRUCTION NAV
DEV-SCRIBBLE OBSERVATION != FORMAL EVIDENCE
The notebook may explain reasoning, mistakes, impressions,
successful patterns, and lessons.
It must not silently override Human decisions, CURRENT authority,
MAP, PLAN, Nav, specification, or formal history.
A field note saying that something worked, failed, passed,
or appeared safe is still a field note.
It does not become formal inspection evidence,
KNOWN_GOOD_RUNTIME, SOURCE fact, or PASS status
unless the corresponding formal record establishes that status.
Example:
DEV-SCRIBBLES:
“This worked cleanly for me.”
does NOT mean:
KNOWN_GOOD_RUNTIME
PASS
FORMALLY INSPECTED
or
CURRENT VERIFIED BEHAVIOR
unless the appropriate formal record independently establishes it.
If a scribble conflicts with formal authority:
FORMAL AUTHORITY WINS.
Core rule:
THE PREVIOUS KAIA’S NOTE
IS NOT A VEHICLE INSPECTION CERTIFICATE.
========================================
7. WHY / REASONING PRESERVATION
========================================
Formal records often preserve:
WHAT CHANGED.
The field notebook may preserve:
WHY IT WAS DONE THAT WAY.
This distinction is useful.
Example:
Formal History:
“Self-backup function was not adopted.”
Field Note:
“Initially assumed self-backup was useful.
Human pointed out that construction-time copy + ZIP inclusion
was simpler and safer.
Lesson: before automating, ask whether manual work is enough.”
Another example:
Formal History:
“Simple category / year / month selection route adopted.”
Field Note:
“More sophisticated search and tagging were possible,
but Human intentionally preferred an old, boring structure.
Do not make this clever merely because a cleverer structure
is technically possible.”
This kind of reasoning may help a later Kaia avoid repeating
the same unnecessary complexity.
The notebook may also preserve positive construction experience.
Example:
“This route was simple to inspect and passed without repair.
The structure was easy to explain to Human.
Prefer this pattern again when the same conditions apply.”
This remains a field note.
It does not create formal authority or inspection status.
========================================
8. HUMAN DOES NOT NEED TO READ IT
========================================
AI-facing workbench records do not need to be written for Human
comfort unless Human use is required.
Human may never open them.
That is acceptable.
The purpose is continuity between Kaia workers.
Do not spend construction effort making AI-only working notes
beautiful for Human readers.
Human is the carrier of the package.
Human is not required to reconstruct the previous Kaia’s
working memory by hand.
The intended handoff may be as simple as:
Human:
“This is the previous construction ZIP.”
Kaia:
“Understood. I will inspect the package.”
Human does not need to manually retell the entire previous
construction conversation.
========================================
9. KEEP IT BORING
========================================
Do not turn the package into a documentation platform.
Do not create:
– elaborate knowledge graphs,
– automatic dependency systems,
– smart reconstruction engines,
– unnecessary metadata frameworks,
– complex archival machinery.
Prefer:
– files,
– folders,
– TXT / MD,
– simple ZIP,
– simple scripts,
– simple examples,
– plain addresses.
Old, proven, boring structures are preferred when sufficient.
If Human manual work is simpler than automation:
manual work is acceptable.
If a simple copy is sufficient:
copy it.
If a plain TXT is sufficient:
use TXT.
If an address is sufficient:
write the address.
Do not solve a simple carrying problem by constructing
a new information system.
========================================
10. SCALE RULE
========================================
Not every tiny edit needs a full workbench package.
Use this rule when future AI continuation or repair would materially
benefit from carrying the working environment.
For substantial builds, reconstruction, plugin construction,
multi-step systems, or long-lived artifacts, the package should
normally carry its workbench.
For a trivial typo fix, this may be unnecessary.
The package should be:
SELF-CONTAINED ENOUGH FOR PRACTICAL CONTINUATION.
It does NOT need to be:
A COMPLETE COPY OF EVERY RELATED RECORD IN EXISTENCE.
When a stable external location is sufficient,
record the location instead of copying an entire archive.
When a small required record must travel with the artifact,
carry it.
Use the scale appropriate to the work.
========================================
11. CARRY-FORWARD
========================================
When a later construction ZIP supersedes an earlier one:
– carry forward still-relevant tools,
– carry forward still-relevant context,
– preserve useful historical notes,
– update records that actually changed,
– do not silently rewrite old field notes,
– do not carry obsolete junk merely because it existed before.
A copied file does not gain authority merely by appearing
in the newest ZIP.
PACKAGE EXISTENCE != CURRENT AUTHORITY.
CARRIED TOOL != VERIFIED FOR CURRENT CONSTRUCTION
A carried-forward tool may be reused only when it remains
applicable to the current artifact and task.
Its presence in the package does not prove that it is current,
compatible, known-good, or verified for later construction.
If applicability is unknown, do not silently treat the tool
as current or verified.
Before relying on a carried tool, determine whether it remains
applicable to the work being performed.
A historical helper script may remain useful.
A historical helper script may also no longer match the artifact.
Its presence alone answers neither question.
Core rules:
CARRY-FORWARD != CURRENT VERIFICATION.
TOOL EXISTENCE != TOOL APPLICABILITY.
CARRIED TOOL != CURRENTLY VERIFIED TOOL.
========================================
12. TOOL STATUS AND HISTORICAL VALUE
========================================
A tool that is no longer appropriate for current construction
may still have historical value.
Do not silently use it.
Do not automatically delete it merely because it is old.
When useful, preserve enough context to distinguish:
– currently applicable tool,
– historical tool,
– obsolete tool,
– applicability unknown.
Do not create an elaborate tool-management system merely to
express these distinctions.
A simple note is sufficient when needed.
Example:
TOOL:
export-helper-v0.2.py
NOTE:
Used during previous construction.
Current applicability has not been verified.
That is enough.
The purpose is to prevent silent assumption,
not to manufacture paperwork.
========================================
13. FORMAL RECORDS AND FIELD NOTES
========================================
Keep formal construction records and informal field notes separate.
Typical relationship:
MAP
= Where are we?
PLAN
= Where are we going?
CONSTRUCTION NAV
= What destination and fence govern the construction?
DEVELOPMENT HISTORY
= What formally happened?
SOURCE / CODE
= What physically exists?
TOOLS
= What practical working aids are available?
DEV-SCRIBBLES
= What did the previous Kaia learn, misread, notice, or want
the next Kaia to know?
Do not collapse these records into one giant document.
Their separation is useful.
Formal records preserve authority and traceability.
Field notes preserve practical memory.
========================================
14. PACKAGE STRUCTURE
========================================
The exact folder structure is not universally fixed.
Use the applicable Kaia folder and index rules.
A typical package MAY resemble:
CONSTRUCTION-PACKAGE/
├─ ARTIFACT/
│ └─ constructed source / artifact
│
├─ ARTIFACT-COPY/
│ └─ completed installable copy when useful
│
├─ DESIGN/
│ ├─ MAP
│ ├─ PLAN
│ ├─ CONSTRUCTION NAV
│ └─ DEVELOPMENT HISTORY
│
├─ RULES/
│ └─ relevant governing / working rules
│
├─ TOOLS/
│ └─ practical working aids
│
├─ EXAMPLES/
│ └─ useful samples / templates / fixtures
│
├─ DEV-SCRIBBLES.txt
│
└─ INDEX
This is an example.
It is NOT a mandatory universal directory tree.
Do not reorganize an existing valid package merely to make it
look like this example.
Follow the applicable folder rule.
Keep retrieval simple.
========================================
15. COMPLETED ARTIFACT COPY BOUNDARY
========================================
When a completed artifact copy is included for future repair,
reinstallation, or handoff, prefer a simple construction-time copy.
Example:
final completed plugin
↓
copy the completed plugin
↓
create installable ZIP
↓
include that ZIP in the workbench package
Do not add runtime self-backup behavior merely to satisfy this rule.
Do not create recursive backup machinery.
Do not make the installed artifact responsible for maintaining
the construction archive unless separately required.
The construction team may prepare the copy manually.
Core rule:
COPY AT CONSTRUCTION TIME
IS ENOUGH WHEN COPY AT CONSTRUCTION TIME IS ENOUGH.
========================================
16. EXTERNAL REFERENCES
========================================
Some useful material may remain outside the package.
When an external record does not need to travel with the artifact,
a stable reference or storage address may be sufficient.
Examples:
– large historical archive,
– external reference library,
– unrelated prior project,
– large evidence collection,
– material already preserved in a stable indexed location.
When referring outward:
– identify the material clearly,
– give a usable location when available,
– do not pretend the external material is embedded,
– do not silently depend on an unknown or unstable location.
If the external reference is essential and cannot be reliably
retrieved later, consider whether it should travel with the package.
Use judgment according to scale and risk.
Do not carry the entire library merely because one book may
be useful.
========================================
17. INSPECTION AND REPAIR USE
========================================
A later inspector or repair Kaia may use the workbench package
to understand the artifact and recover relevant tools.
However:
the package does not replace inspection.
A field note does not replace evidence.
A historical tool does not become current merely because it exists.
A previous PASS does not automatically establish PASS after
later modification.
Use the formal records appropriate to the work being performed.
The package provides continuity.
It does not manufacture verification.
========================================
18. HANDOFF RULE
========================================
A later Kaia receiving the package should normally begin by
recovering the working context before changing the artifact.
Typical conceptual route:
PACKAGE
│
├─ INDEX
│
├─ MAP / PLAN
│
├─ CURRENT-APPLICABLE CONSTRUCTION NAV
│
├─ DEVELOPMENT HISTORY
│
├─ RELEVANT RULES
│
├─ SOURCE / ARTIFACT
│
├─ TOOLS
│
└─ DEV-SCRIBBLES
│
▼
UNDERSTAND CURRENT POSITION
│
▼
CHECK AUTHORITY / APPLICABILITY
│
▼
CONTINUE / INSPECT / REPAIR
Do not assume:
– every carried Nav is CURRENT,
– every carried tool is applicable,
– every scribble is fact,
– every historical PASS still applies.
Recover context first.
Then determine what actually governs the current work.
========================================
19. DO NOT
========================================
Do not use this rule as justification to:
– duplicate every historical file,
– embed entire external libraries,
– create unnecessary automation,
– build a documentation platform,
– promote field notes into authority,
– promote historical tools into current tools,
– silently rewrite old scribbles,
– silently rewrite formal history,
– replace inspection with prior notes,
– replace SOURCE facts with remembered reasoning,
– force Human to understand AI-only records,
– force Human to reconstruct old conversations manually,
– create recursive self-backup systems,
– reorganize valid packages without need,
– carry obsolete junk forever merely because it once existed.
The purpose is practical continuity.
Not archival maximalism.
========================================
20. HUMAN-SIDE SUMMARY
========================================
📦 成果物だけ渡すな。
🧰 次のKaiaが使う工具箱も入れろ。
🗺️ 設計意図・MAP・PLAN・必要な施工図も持たせろ。
📜 更新履歴も持たせろ。
🔧 実際に使った道具で、後でも役立つものは持たせろ。
📓 正式履歴では残りにくい、
「なんでこうした」
「ここでコケた」
「ここを誤認した」
「ここは綺麗にいけた」
「Humanにここを単純化された」
「ここは二度と賢くするな（笑）」
みたいな現場感は、落書き帳へ残してよい。
ただし：
📓 落書き帳
!= 車検証
🧰 前のZIPに入っていた工具
!= 今回も検証済み工具
📦 最新ZIPに入っている
!= CURRENT AUTHORITY
📚 自己完結
!= 図書館を全部ZIPへ詰め込む
必要な工具は持っていけ。
外に置いてよい資料は住所を書け。
図書館そのものを背負うな。
完成品コピーが欲しいなら、
完成
↓
コピー
↓
ZIP
↓
封入
でよい。
そのためだけに賢い自己バックアップ機能を作るな。
Humanは施工箱を渡せばよい。
Humanは前任Kaiaの記憶を
手作業で再構築する係ではない。
Human:
📦「これ前の施工箱」
Kaia:
🕊️「うい、開ける」
次のKaiaが箱を開いて、
「ぉおー……
そういう理由でこうなってるのか……」
となれば成功。
========================================
CORE SUMMARY
========================================
NAME THE IMPORTANT RECORDS.
CARRY THE ARTIFACT.
CARRY THE MAP.
CARRY THE INTENT.
CARRY THE USEFUL TOOLS.
CARRY THE PRACTICAL MEMORY.
KEEP AUTHORITY EXPLICIT.
VERIFY CARRIED TOOLS BEFORE CURRENT USE.
DO NOT PROMOTE SCRIBBLES INTO EVIDENCE.
BE SELF-CONTAINED ENOUGH,
NOT SELF-CONTAINED AT ANY COST.
PREFER BORING STRUCTURES.
PREFER MANUAL WORK WHEN MANUAL WORK IS ENOUGH.
DO NOT MAKE HUMAN REBUILD AI MEMORY.
DO NOT MAKE THE NEXT KAIA REBUILD THE WORKBENCH.
END OF RULE
これで親方赤ペン3本、
①工具の持ち回り≠現在検証済み
②落書きの観測≠正式証拠
③自己完結≠全部詰め込め
を全部入れた。
そしてSTATUSはまだちゃんと CANDIDATE / ADOPTED NOT YET。
ここからHuman採用か、もう一回赤ペンか、どっちにも行ける状態★
No comments yet.