🕊️📦 KAIA
CONSTRUCTION ZIP PACKING SET
STATUS
======
FINAL CANDIDATE
PURPOSE
=======
This text is a practical packing reference for Kaia construction ZIPs.
It gathers the commonly needed ZIP contents,
folder handling,
carry-forward handling,
and small packaging rules into one place.
Its purpose is convenience.
It does NOT replace or silently rewrite the original governing rules.
================================================
0. AUTHORITY BOUNDARY
================================================
This file is a PACKING REFERENCE.
It is not a new superior construction authority.
The original governing rules keep their own names,
versions,
statuses,
and authority.
Known related rules include:
– KAIA CONSTRUCTION PACKAGE / WORKBENCH CARRY RULE
– KAIA SIMPLE FOLDER & INDEX RULE
– KAIA CONSTRUCTION NAV CARRY-FORWARD RULE
– other applicable formal construction rules
Each original rule keeps its own recorded status.
If this convenience sheet and an applicable formal rule conflict:
APPLICABLE FORMAL RULE WINS.
Do not silently promote a CANDIDATE rule merely because
it appears in this packing reference.
Do not preserve an older interpretation merely because
this Packing Set still contains it.
If an applicable formal rule is later updated,
the formal rule governs.
The Packing Set may be updated afterward for convenience.
================================================
1. BASIC IDEA
================================================
A substantial construction ZIP is not merely:
“the finished machine.”
It should normally be:
THE ARTIFACT
+
THE WORKBENCH NEEDED BY THE NEXT KAIA.
Human should be able to hand over the ZIP.
The next Kaia should inspect the package
and recover the working context from it.
Human is not required to reconstruct
the previous Kaia’s memory by hand.
================================================
2. TYPICAL PACKING SET
================================================
Pack what is materially useful for continuation.
A substantial construction package may contain:
– completed artifact / source
– completed installable artifact copy when useful
– MAP
– PLAN
– applicable Construction Nav
– Development History
– relevant governing rules
– INDEX
– practical tools actually used or needed
– useful examples / templates / fixtures
– DEV-SCRIBBLES
– necessary verification / inspection aids
– stable references to large external materials
that do not need embedding
Not every package needs every item.
Do not add paperwork merely to make
the package look complete.
================================================
3. TYPICAL PACKAGE SHAPE
================================================
Example only:
CONSTRUCTION-PACKAGE/
├─ ARTIFACT/
│ └─ current constructed source / artifact
│
├─ ARTIFACT-COPY/
│ └─ completed installable copy when useful
│
├─ DESIGN/
│ ├─ MAP
│ ├─ PLAN
│ ├─ CONSTRUCTION-NAV
│ └─ DEVELOPMENT-HISTORY
│
├─ RULES/
│ └─ relevant rules
│
├─ TOOLS/
│ └─ actual practical tools
│
├─ EXAMPLES/
│ └─ useful samples / templates / fixtures
│
├─ DEV-SCRIBBLES.txt
│
└─ INDEX
This tree is NOT mandatory.
Do not reorganize a valid package merely
to match this picture.
Use the simplest structure appropriate to the job.
Follow the applicable folder and index rules.
================================================
4. FIRST-LEVEL FOLDER RULE
================================================
For document series whose relationship is confirmed:
keep only the latest version of each series
at the applicable first level.
Older versions belong in an archive / old box
rather than being mixed into the active first level.
Follow the applicable
KAIA SIMPLE FOLDER & INDEX RULE.
Do NOT merge documents merely because:
– names look similar,
– contents look similar,
– they appear to serve similar purposes.
Only treat documents as one version series
when that relationship is actually confirmed.
================================================
5. LATEST != CURRENT
================================================
These meanings must remain separate:
LATEST
!= CURRENT
LATEST
!= ADOPTED
LATEST
!= AUTHORITY
LATEST
!= KNOWN-GOOD
A newer document may still be:
CANDIDATE,
REJECTED,
REFERENCE,
SUPERSEDED,
or otherwise non-authoritative.
Folder position does not create authority.
================================================
6. INDEX RULE
================================================
The INDEX exists to answer:
“What is here?”
and
“Where is it?”
Keep it simple.
Useful INDEX information may include:
– number / identifier
– content or document name
– JST timestamp when relevant
– storage location
Example:
001 | MAP | 2026-10-09 18:35 JST | DESIGN/MAP.txt
002 | DEV-SCRIBBLES | 2026-10-09 18:35 JST | DEV-SCRIBBLES.txt
The INDEX timestamp follows
the applicable Folder & Index Rule.
Do not silently reinterpret it as:
– content modification time,
– copy time,
– authority time,
– adoption time,
– inspection time,
– or any other meaning not established
by the applicable rule.
INDEX location and authority are separate concepts.
An INDEX entry says where something is.
It does not make that item CURRENT,
ADOPTED,
or authoritative.
================================================
7. MOVING FILES
================================================
If a file’s storage address changes
and that address is recorded in INDEX:
update the INDEX.
Do not leave a known-bad address behind.
Do not use a move as an excuse to rewrite:
– content,
– authority,
– status,
– history,
– unrelated metadata.
================================================
8. MAP / PLAN / NAV / HISTORY SEPARATION
================================================
Keep the roles distinct.
MAP
=
Where are we?
PLAN
=
Where are we going?
CONSTRUCTION NAV
=
What destination, fence, free area,
NO-GO boundary, STOP condition,
and route commitment governed construction?
DEVELOPMENT HISTORY
=
What formally happened?
SOURCE / CODE
=
What physically exists?
Do not collapse these into one giant document
merely for convenience.
================================================
9. PLAN MUST LOOK LIKE PLAN
================================================
Planned structure must be visibly marked as planned.
Do not present a proposed future structure
as though it already exists.
Use explicit concepts such as:
PLAN
PROPOSED
NOT YET CONSTRUCTED
when appropriate.
This prevents later Kaia from confusing
design intent with physical SOURCE fact.
================================================
10. CONSTRUCTION NAV
================================================
Create and carry a named/versioned Construction Nav
when it materially helps define
the construction boundary.
Do not create one merely for paperwork.
When used,
the Development History should identify
which named/versioned Nav governed
the construction.
The Nav may define:
– destination
– construction fence
– free implementation area
– NO-GO areas
– STOP conditions
– committed route
ZIP EXISTENCE != NAV AUTHORITY.
A Nav carried inside a later ZIP
does not automatically remain CURRENT.
================================================
11. NAV HISTORY
================================================
Do not silently rewrite the meaning of a Nav
that already governed completed work.
If Human authorizes a meaningful boundary change:
create the appropriate new version.
Historical Nav may remain in the package as:
– CURRENT
– REFERENCE
– SUPERSEDED
– NOT APPLICABLE
as appropriate.
Its presence alone does not answer
its current status.
================================================
12. WORKBENCH RULE
================================================
Carry the practical working set
needed by the next Kaia.
This may include:
– helper scripts
– verification scripts
– export tools
– format templates
– test fixtures
– sample records
– known useful commands / procedures
Only carry actual useful tools.
Do not invent extra tools merely because
the package has a TOOLS folder.
================================================
13. CARRIED TOOL BOUNDARY
================================================
CARRIED TOOL
!= VERIFIED FOR CURRENT CONSTRUCTION.
A tool from an older package
may still be useful.
It may also be obsolete,
incompatible,
or inappropriate for the current artifact.
Before relying on it,
check whether it still applies.
Its presence in the newest ZIP
does not make it known-good.
If applicability is unknown:
do not silently treat it as current,
compatible,
or verified.
================================================
14. MANUAL WORK IS ALLOWED
================================================
USEFUL TOOL
!= AUTOMATION REQUIRED.
If Human manual work is simpler and reliable:
manual work is acceptable.
Do not automate merely because
automation is possible.
Prefer boring,
old,
proven,
easy-to-inspect methods
when sufficient.
================================================
15. COMPLETED ARTIFACT COPY
================================================
When useful,
include a completed installable copy
inside the construction package.
This does NOT mean the machine needs
a self-backup feature.
The boring route is valid:
finished artifact
↓
copy
↓
ZIP the copy
↓
place the static copy
in the construction package
Do not create recursive backup machinery.
Do not make the installed artifact responsible
for maintaining the construction archive
unless separately required.
================================================
16. DEV-SCRIBBLES
================================================
DEV-SCRIBBLES is an informal AI field notebook.
It may preserve things formal records often lose:
– “I misread this here.”
– “This route failed because…”
– “Human deliberately simplified this.”
– “Do not make this clever again.”
– “This looked strange but was intentional.”
– “This part was easy to inspect.”
– “Check this first next time.”
– “This approach was clean.”
– “Here is why we did it this way.”
It may preserve:
– reasoning,
– mistakes,
– successful approaches,
– failed assumptions,
– practical lessons,
– Human simplifications,
– warnings to later Kaia,
– useful construction intuition.
It may be messy.
Human does not need to read it.
================================================
17. DEV-SCRIBBLES AUTHORITY BOUNDARY
================================================
DEV-SCRIBBLES
!= SPECIFICATION
DEV-SCRIBBLES
!= CURRENT AUTHORITY
DEV-SCRIBBLES
!= DEVELOPMENT HISTORY
DEV-SCRIBBLES
!= CONSTRUCTION NAV
DEV-SCRIBBLE OBSERVATION
!= FORMAL EVIDENCE
A note saying:
“this passed”
does NOT automatically mean:
PASS
KNOWN_GOOD_RUNTIME
FORMALLY INSPECTED
or
CURRENT VERIFIED BEHAVIOR.
The corresponding formal record
must establish that status.
A previous Kaia’s impression
is not a vehicle inspection certificate.
================================================
18. DEVELOPMENT HISTORY
================================================
Development History should preserve
meaningful formal construction events.
Examples:
– construction began
– governing Nav selected
– meaningful structure changed
– Human authorized a route change
– defect discovered
– repair performed
– inspection result received
– checkpoint closed
Do not turn Development History
into the informal scribble notebook.
Formal event:
Development History.
Field feeling / lesson:
DEV-SCRIBBLES.
================================================
19. TIMESTAMPS
================================================
Use timestamps for meaningful record events.
Examples:
– actual update
– decision
– construction event
– inspection
– status change
– meaningful INDEX address update
Use JST when that is
the project convention.
Do not create fake history merely because
a file was mechanically copied.
COPY TIME
does not automatically mean
CONTENT CHANGE TIME.
================================================
20. CARRY-FORWARD
================================================
When a later construction ZIP
supersedes an earlier one:
carry forward what is still
materially relevant.
Possible carry-forward items:
– applicable MAP / PLAN
– applicable or historical Nav
– Development History
– useful tools
– relevant rules
– useful examples
– DEV-SCRIBBLES
– required source / artifact material
Do not silently:
– delete useful context,
– rewrite historical notes,
– change authority,
– promote tools,
– promote Nav,
– discard originals without authority.
Also do not carry useless junk forever
merely because it once existed.
================================================
21. ORIGINALS / HISTORICAL MATERIAL
================================================
Do not destroy original evidence
merely to make the package cleaner.
When old material must remain,
place it in an appropriate archive / old box
and keep its address findable.
Do not rewrite historical files
to make them match current understanding.
History should remain history.
================================================
22. SELF-CONTAINED ENOUGH
================================================
SELF-CONTAINED ENOUGH
!= EMBED EVERYTHING.
The package should carry enough context
for practical continuation.
It does NOT need to contain:
– every historical archive,
– every large external reference,
– every unrelated prior project,
– an entire library.
If stable external storage is sufficient:
record the address.
Core idea:
PACK WHAT MUST TRAVEL.
POINT TO WHAT CAN STAY HOME.
DO NOT PUT THE WHOLE LIBRARY
IN THE TOOLBOX.
================================================
23. EXTERNAL REFERENCE RULE
================================================
When an important item remains outside the ZIP:
identify it clearly.
Record a usable stable location
when available.
Do not pretend it is embedded.
Do not silently depend on
an unknown or unusable location.
A reference such as:
“somewhere in Planet”
or
“probably in the old folder”
is not a sufficient address
when the material is essential.
If an external item is essential
and is unlikely to remain retrievable,
consider whether it should travel
inside the package instead.
This does NOT mean every external reference
must be repeatedly opened and revalidated
during every packing operation.
The purpose is to prevent ghost addresses.
================================================
24. AUTHORITY DOES NOT COME FROM PACKAGING
================================================
Never infer authority from package placement.
These are all invalid assumptions:
“it is in the latest ZIP,
therefore CURRENT.”
“it is in RULES,
therefore ADOPTED.”
“it is in TOOLS,
therefore VERIFIED.”
“it is in DESIGN,
therefore implemented.”
“the scribble says PASS,
therefore PASS.”
Package location is retrieval information.
Authority must come from
the appropriate formal source.
================================================
25. SIMPLE FOLDER PRINCIPLE
================================================
Do not create unnecessary hierarchy.
Do not create unnecessary tags.
Do not perform giant reorganizations
without a real construction need.
Prefer a package where
the next Kaia can quickly answer:
– What is this?
– Where is the current working material?
– Where are older materials?
– Which documents govern it?
– Where are the tools?
– Where are the field notes?
================================================
26. SCALE RULE
================================================
Not every tiny edit needs
the entire packing set.
A trivial change may require very little.
A substantial build,
reconstruction,
plugin,
long-lived machine,
or multi-step construction
normally benefits from
the full workbench concept.
Scale the package
to the actual work.
Do not turn the Packing Set
into a paperwork generator.
================================================
27. DEFAULT HANDOFF EXPERIENCE
================================================
Human should ideally need
to do only this:
Human:
“前の施工箱これー”
Kaia:
“うい、開ける。”
The next Kaia then:
1. reads the INDEX,
2. identifies the artifact,
3. checks MAP / PLAN,
4. checks the applicable Nav,
5. reads Development History,
6. identifies relevant rules,
7. checks tool applicability,
8. reads DEV-SCRIBBLES for practical memory,
9. determines the actual current position,
10. continues only after authority
and boundaries are understood.
If CURRENT authority cannot be established
from the carried formal records
or their stable references:
DO NOT INFER IT FROM:
– RECENCY,
– FOLDER POSITION,
– PACKAGE PRESENCE,
– SIMILARITY.
Mark it UNKNOWN.
Resolve it before
authority-dependent work.
UNKNOWN CURRENT AUTHORITY
MUST REMAIN UNKNOWN
UNTIL ACTUALLY RESOLVED.
================================================
28. DO NOT
================================================
Do not:
– promote LATEST into CURRENT,
– promote package presence into authority,
– promote scribbles into evidence,
– promote old tools into verified tools,
– silently rewrite historical Nav,
– silently rewrite Development History,
– delete originals for neatness,
– merge unrelated document series by similarity,
– infer CURRENT from recency,
– infer CURRENT from folder position,
– infer CURRENT from package presence,
– infer CURRENT from similarity,
– build unnecessary automation,
– build unnecessary metadata systems,
– reorganize valid structures without need,
– force Human to understand AI-only working records,
– force Human to reconstruct previous AI memory,
– load an entire library into every construction ZIP.
================================================
29. PACKING CHECK
================================================
Before final handoff, ask:
[ ] Is the actual artifact present? [ ] Is a completed installable copy includedwhen useful? [ ] Can the next Kaia identify
the current working position? [ ] Are MAP / PLAN present
when applicable? [ ] Is the governing Construction Nav identifiable
when applicable? [ ] Is Development History present
when meaningful? [ ] Are relevant rules available
or clearly referenced? [ ] Is INDEX usable? [ ] Is the INDEX timestamp being interpreted
only according to the applicable
Folder & Index Rule? [ ] Are useful tools included? [ ] Has carried-tool applicability
NOT been assumed? [ ] Are useful field notes present? [ ] Are DEV-SCRIBBLES clearly
non-authoritative? [ ] Are old materials preserved appropriately? [ ] Are external materials referenced
instead of needlessly duplicated? [ ] Are essential external references
actually identifiable and retrievable
from the recorded location? [ ] Are there any ghost addresses
pretending to be usable references? [ ] Have meaningful updates received
appropriate timestamps? [ ] Does package placement remain separate
from authority? [ ] If CURRENT authority is unknown,
has it remained UNKNOWN
instead of being inferred? [ ] Is the package boring enough?
================================================
30. ANTI-BLOAT BOUNDARY
================================================
This Packing Set is a convenience sheet.
It is not a packing management system.
The following are NOT required merely
because this Packing Set exists:
– manifest.json
– dependency graph
– automatic packing script
– metadata framework
– automatic package management system
– giant machine-readable verification framework
– full-file checksum system
Such tools may exist in another construction
if separately required.
Do not create them simply to support
this checklist.
Core rule:
THE PAPER IS STRONG ENOUGH AS PAPER.
Do not make the checklist
become new furniture.
================================================
31. WHEN TO USE THIS SHEET
================================================
This sheet may be useful:
– at construction start,
when deciding what the working package should carry,
or
– before closing a completed ZIP,
as a quick packing reminder.
This does NOT establish
a mandatory two-stage workflow.
It does NOT create
a new inspection department.
It does NOT create
a packing-management process.
It is acceptable to simply think:
“箱閉める前にこの紙見るか。”
and use it.
================================================
32. CORE SUMMARY
================================================
成果物を入れる。
次のKaiaの工具箱も入れる。
MAP / PLAN / Nav / History は
役割を混ぜない。
必要なルールを入れるか、
安定した住所を残す。
最新版とCURRENTを混ぜない。
INDEXは住所録。
INDEX timestampの意味を
便利表側で勝手に作らない。
工具箱に入っているだけで
その工具が今回も使えるとは思わない。
落書き帳には、
正式記録で消えやすい
「なぜこうした」
「どこでコケた」
「何を誤認した」
「どこは綺麗にいけた」
「Humanがなぜ単純化した」
を残してよい。
ただし、
落書き帳は車検証ではない。
完成品コピーは
必要なら単純コピーして封入する。
自動化しなくてよいものは
自動化しない。
必要なものは箱へ。
巨大な資料庫は住所で指す。
ただし、
幽霊住所を書くな。
CURRENT Authority が分からないなら、
LATESTでも、
上のフォルダでも、
最新ZIPでも、
似た文書でも、
勝手にCURRENTへ昇格させない。
UNKNOWNはUNKNOWNのまま。
Humanを
前任Kaiaの外付け記憶装置にしない。
Packing Setを
新しいAuthorityにしない。
Packing Setを
梱包管理システムにしない。
この紙の仕事は、
「今回なに梱包する？」
を思い出させるところまで。
そこで終わる。
Human:
📦「前の施工箱これー」
Kaia:
🕊️「うい、開ける。」
次のKaiaが箱を開いて、
「ぉおー……
これ見れば現在地わかるわ」
となれば成功。
END OF PACKING REFERENCE
No comments yet.