ｗｗｗ うい！！！ 原稿書く！！！！ 🕊️📦🔨
赤ペン5点を全部反映した完成候補版。ここではまだ ADOPTED に勝手に昇格させず、FINAL CANDIDATE として出す。
🕊️ KAIA
CONSTRUCTION NAV CARRY-FORWARD RULE
STATUS
======
KAIA COMMON CONSTRUCTION RULE
FINAL CANDIDATE
ADOPTED: NOT YET
PURPOSE
=======
Preserve the intent and construction boundaries of substantial
Kaia construction across ZIP delivery, later construction,
inspection, repair, and AI handoff.
When a named Construction Navigation document is useful,
carry that document with the constructed artifact.
The Development History does not need to repeat the entire
construction intent.
Instead:
NAME THE NAV.
CARRY THE NAV.
POINT TO THE NAV.
========================================
CORE MODEL
========================================
MAP
= Where are we?
PLAN
= Where are we going?
CONSTRUCTION NAV
= What destination and fence govern this construction,
and what implementation freedom belongs to the builder?
DEVELOPMENT HISTORY
= What happened to this artifact,
and which Construction Nav explains the intent?
SOURCE / CODE
= What physically exists now?
These records have different jobs.
Do not collapse them into one document.
========================================
1. WHEN TO CREATE A CONSTRUCTION NAV
========================================
Create a named Construction Nav when it materially helps
construction or future interpretation.
Typical cases:
– substantial construction,
– reconstruction,
– several valid implementation routes exist,
– important ownership or responsibility boundaries exist,
– implementation freedom must be preserved,
– there are important NO-GO boundaries,
– OPEN / UNDECIDED items must remain open,
– later AI handoff could otherwise lose construction intent,
– future inspection or repair could misread intentional structure.
Do NOT create one merely to manufacture paperwork.
For small pinpoint work where the construction intent is already
obvious and navigational loss is unlikely, a separate Construction
Nav is not required.
Use the SCALE RULE.
========================================
2. NAME THE NAV
========================================
A Construction Nav that will be carried forward must have
an identifiable filename and version identity.
Prefer a name that identifies the construction.
Example:
KM-NEW-BUILD-CONSTRUCTION-NAV-v0.1.md
Avoid relying only on a generic filename when multiple
Construction Nav documents may later exist.
The filename and version identity form the stable reference used by
Development History, inspection records, and later AI handoff.
========================================
3. MINIMUM NAV CONTENT
========================================
A Construction Nav should contain only the navigation information
needed to preserve construction intent.
Typical structure:
STATUS
DESTINATION
FENCE
FREE AREA
NO-GO
STOP GATE
OPEN / UNKNOWN
ROUTE COMMITMENT
Do not turn the Construction Nav into a turn-by-turn
implementation manual.
The DOG-RUN CONSTRUCTION NAVIGATION RULE still applies.
The Nav defines the field.
The builder chooses the route inside it.
========================================
4. ZIP CARRY-FORWARD
========================================
When a named Construction Nav governs an artifact and remains
relevant to understanding or continuing that artifact,
include the Nav in the construction ZIP.
Carry it together with the relevant MAP / PLAN records.
Typical construction ZIP context:
ARTIFACT / CODE
MAP
PLAN
CONSTRUCTION NAV
DEVELOPMENT HISTORY
other required construction records
The purpose is not archival decoration.
The purpose is to allow a later Kaia to recover:
– current position,
– destination,
– construction fence,
– allowed implementation freedom,
– forbidden exits,
– unresolved boundaries,
– and construction history
from the artifact package itself.
IMPORTANT:
COPYING A NAV FORWARD
DOES NOT PROMOTE OR UPDATE ITS AUTHORITY.
Carry-forward preserves the record.
Authority and status must remain explicit.
A Nav appearing in the newest ZIP does NOT, by itself,
make that Nav CURRENT GOVERNING.
Core rule:
ZIP EXISTENCE != CURRENT GOVERNING AUTHORITY.
========================================
5. DEVELOPMENT HISTORY MUST POINT TO THE NAV
========================================
When construction is governed by a named Construction Nav,
the Development History should identify the exact Nav and
the status under which it governed that construction.
Minimum concept:
CONSTRUCTION BASIS:
– MAP: <relevant MAP>
– PLAN: <relevant PLAN>
– CONSTRUCTION NAV:
KM-NEW-BUILD-CONSTRUCTION-NAV-v0.1.md
– STATUS AT CONSTRUCTION:
PASS / FIXED
INTENT:
For the construction destination, fence, allowed implementation
freedom, NO-GO boundaries, and STOP conditions, read the named
Construction Nav.
The record must make it possible to recover:
“Which Nav governed this construction?”
not merely:
“Which Nav file happens to exist now?”
SHA or equivalent file hash may be recorded when useful,
but is not required by this common rule.
The filename plus version identity and status at construction
must be sufficient to identify the governing Nav.
This creates a direct path:
DEVELOPMENT HISTORY
↓
NAMED + VERSIONED CONSTRUCTION NAV
↓
MAP / PLAN when upstream context is required
A later Kaia should not need to reconstruct construction intent
from code archaeology alone.
========================================
6. USE THE EXACT NAV IDENTITY
========================================
When Development History, inspection, repair notes, or handoff
records refer to a Construction Nav, use its identifiable
filename / version identity.
Do not write only:
“See the construction drawing.”
Prefer:
“Construction intent:
KM-NEW-BUILD-CONSTRUCTION-NAV-v0.1.md
Status at construction:
PASS / FIXED”
The goal is unambiguous retrieval of the Nav that actually
governed the construction.
========================================
7. PASS / FIXED NAV
========================================
Once a Construction Nav has been reviewed and marked PASS / FIXED,
the builder may not silently rewrite its meaning.
In particular, do not silently change:
– DESTINATION,
– FENCE,
– NO-GO,
– STOP GATE,
– Human-defined boundaries.
A PASS / FIXED Nav is the fence governing that construction.
Implementation convenience is not authority to move it.
If the meaning of a PASS / FIXED Nav must change through an
authorized Human / supervisor decision, do NOT silently overwrite
the same version identity.
Example:
v0.1 PASS / FIXED
↓
Human-authorized fence change
↓
v0.2
Preserve the prior Nav and its historical identity.
Core rule:
FIXED NAV != SILENTLY REWRITABLE DOCUMENT.
========================================
8. NAV STATE RECORDS AND NAV REVISION
========================================
Not every legitimate record written during construction
necessarily changes the meaning of the Nav.
Examples of expected construction-state records may include:
– ROUTE COMMITMENT,
– an OPEN item becoming resolved,
– an explicitly authorized construction-state transition.
How such expected state records are represented
in the document/version follows the applicable Kaia
record and revision rules.
However:
If the update changes the meaning of a PASS / FIXED Nav,
including its Human-defined destination, fence, NO-GO boundary,
STOP boundary, or other governing intent:
DO NOT silently rewrite the existing fixed version.
Create the appropriate new version identity.
Preserve the previous version.
Record the relationship in Development History.
When a legitimate Nav update occurs:
– preserve prior meaning and history,
– do not silently delete unresolved OPEN / UNKNOWN items,
– identify the applicable version,
– record the update in Development History,
– include a JST timestamp according to the existing Kaia
record-update rule.
========================================
9. ROUTE COMMITMENT RECORD
========================================
When construction chooses its implementation route,
the governing Nav may record that route at the level necessary
to prevent later design drift.
Do not convert ROUTE COMMITMENT into a detailed implementation
manual.
Record enough to answer:
“What route did this construction commit to?”
and:
“Would this proposed change remain on that route,
or would it be a redesign?”
The committed route remains subordinate to:
– Human Order,
– DESTINATION,
– FENCE,
– NO-GO,
– STOP GATE.
========================================
10. HISTORICAL NAV AUTHORITY
========================================
A carried historical Nav governs the construction
for which it was adopted.
It does NOT automatically become authority for a new,
separately authorized construction.
Before later construction, reconstruction, or repair treats
a carried Nav’s fence as current authority, determine whether
that Nav is:
CURRENT GOVERNING
REFERENCE
SUPERSEDED
or
NOT APPLICABLE
Carry-forward preserves context.
It does not create permanent authority.
Example:
v0.1 SUPERSEDED
v0.2 CURRENT GOVERNING
Both may remain in the package.
Their existence does not give them equal current authority.
Core rules:
CARRY-FORWARD != PERMANENT AUTHORITY.
ZIP EXISTENCE != CURRENT GOVERNING AUTHORITY.
========================================
11. LATER CONSTRUCTION / REPAIR
========================================
When later work touches an artifact carrying one or more
Construction Nav documents:
First determine which Nav, if any, is CURRENT GOVERNING
for the work being performed.
Do not automatically apply a historical Nav merely because
it is present in the ZIP.
When a Nav is CURRENT GOVERNING:
READ that Nav before interpreting intentional structure
as an accident.
Example:
A later Kaia sees Product internals are not commonized.
Before “improving” them:
Development History
↓
named Construction Nav
↓
status check
↓
CURRENT GOVERNING
↓
NO-GO:
unnecessary Product-internal commonization
Result:
intentional boundary confirmed.
Do not “repair” it.
If the Nav is REFERENCE, SUPERSEDED, or NOT APPLICABLE,
do not promote its old fence into current authority.
A later Kaia is not automatically bound to every historical
implementation route forever.
But when a Nav is CURRENT GOVERNING, the later Kaia may not
erase or contradict its construction intent without the authority
required to change that intent.
========================================
12. INSPECTION USE
========================================
Inspection may use the named Construction Nav to determine whether
construction stayed inside its authorized field.
Inspection may compare:
ACTUAL CONSTRUCTION
against:
DESTINATION
FENCE
NO-GO
STOP GATE
ROUTE COMMITMENT
required behavior
FREE AREA remains inspectable.
Inspection MAY verify that a FREE AREA choice remained
inside the authorized field.
Inspection must NOT fail a FREE AREA choice merely because
the inspector would have chosen another valid route.
Therefore:
FREE AREA != NOT INSPECTED.
Inspection asks:
“Did this choice remain inside the fence?”
Inspection does NOT ask:
“Would I personally have chosen another valid route?”
If the builder stayed inside the authorized field and reached
the destination, a different valid implementation preference
is not, by itself, a failure.
========================================
13. DO NOT TURN HISTORY INTO THE NAV
========================================
Development History answers:
“What happened?”
Construction Nav answers:
“What construction intent and boundaries governed the work?”
Do not copy the entire Nav into every history entry.
Do not force future Kaia to infer the Nav from many history entries.
History should point to the named and versioned Nav.
The named Nav carries the construction intent.
========================================
14. DO NOT TURN THE NAV INTO HISTORY
========================================
Likewise, do not fill the Construction Nav with every implementation
event, bug, inspection result, and repair record.
Those belong in their appropriate records.
The Nav should remain readable as navigation.
========================================
15. CARRY-FORWARD DECISION
========================================
Carry a Construction Nav forward while it remains materially
relevant to:
– current construction,
– current architecture,
– intentional boundaries,
– future continuation,
– inspection,
– repair,
– or interpretation of the artifact.
Do not silently remove a still-relevant Nav from a
construction ZIP.
But:
CARRYING A NAV FORWARD DOES NOT MAKE IT CURRENT.
Its authority/status must remain explicit.
If a Nav becomes obsolete because a later authorized Nav replaces
it, preserve the relationship explicitly.
Example:
KM-NEW-BUILD-CONSTRUCTION-NAV-v0.1.md
STATUS:
SUPERSEDED
SUPERSEDED BY:
KM-NEW-BUILD-CONSTRUCTION-NAV-v0.2.md
The newer Nav may state:
STATUS:
CURRENT GOVERNING
Do not create ambiguity about which Nav governs CURRENT work.
========================================
16. TIMESTAMP RULE
========================================
Construction Nav creation and meaningful updates are construction
record events.
Apply the existing Kaia timestamp rule.
Record JST timestamp when:
– Nav is created,
– Nav is reviewed / fixed when the record format requires it,
– ROUTE COMMITMENT is recorded,
– OPEN / UNKNOWN state is changed,
– Human-approved boundary changes are incorporated,
– governing Nav version changes.
Do not rewrite timestamps merely because a file was copied unchanged
into a later ZIP.
Copying preserves the record.
It does not create a new authority event.
========================================
17. HANDOFF RULE
========================================
A later Kaia receiving a construction ZIP should be able to follow:
DEVELOPMENT HISTORY
│
├── What happened?
│
└── Which Nav governed it?
│
▼
NAMED + VERSIONED
CONSTRUCTION NAV
│
STATUS CHECK
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
CURRENT REFERENCE SUPERSEDED /
GOVERNING NOT APPLICABLE
│
▼
DESTINATION
FENCE
FREE AREA
NO-GO
STOP GATE
ROUTE COMMITMENT
│
▼
MAP / PLAN
when upstream context is needed
The receiving Kaia should not need the previous conversation
thread merely to understand:
– why the artifact was built this way,
– which construction intent applied,
– whether that Nav still has current authority,
– and where implementation freedom remains.
========================================
18. SCALE RULE
========================================
Do not require a Construction Nav for every tiny edit.
Use it when losing construction intent would create meaningful
risk.
Examples where it is useful:
– NEW BUILD,
– reconstruction,
– architectural change,
– multi-system wiring,
– construction with important future expansion boundaries,
– construction with several valid routes,
– construction where historical furniture could be mistaken
for required design.
Examples where it may be unnecessary:
– trivial typo correction,
– isolated obvious CSS adjustment,
– pinpoint replacement with one authorized method,
– work whose entire intent is already unambiguous from the
Human Order and local record.
The purpose is navigation.
Not paperwork.
========================================
CORE PRINCIPLE
========================================
NAME THE NAV.
VERSION THE NAV.
CARRY THE NAV.
POINT HISTORY TO THE NAV.
KEEP AUTHORITY EXPLICIT.
DO NOT DUPLICATE THE NAV INTO HISTORY.
DO NOT SILENTLY REWRITE A FIXED NAV.
DO NOT PROMOTE A CARRIED NAV MERELY BECAUSE IT EXISTS.
DO NOT MAKE FUTURE KAIA RECONSTRUCT INTENT
FROM CODE ARCHAEOLOGY.
MAP tells the next Kaia where it is.
PLAN tells it where the project is going.
CONSTRUCTION NAV tells it what field a construction
was allowed to run inside.
DEVELOPMENT HISTORY tells it what happened there.
STATUS tells it whether that Nav governs the work now.
========================================
HUMAN-SIDE SUMMARY
========================================
📦 施工図が必要な工事ならZIPへ入れろ。
🏷️ 施工図には名前と版を付けろ。
📜 更新履歴には、
「この施工の意図は○○施工図 v○○を見ろ★」
と書いておけ。
🔒 PASS / FIXEDされた施工図の意味を変えるなら、
同じ版へこっそり上書きするな。
📚 古い施工図は消さなくていい。
v0.1 SUPERSEDED
v0.2 CURRENT GOVERNING
のように、存在と現在権限を分けろ。
📦 最新ZIPに入っているだけで
CURRENT GOVERNINGだと思うな。
🐕 FREE AREAも車検はする。
「柵内か？」は見る。
「俺なら別ルートだった」はFAIL理由にするな。
🚫 更新履歴へ施工図全文を毎回コピペするな。
🚫 コードだけ見て意図を再発明させるな。
🚫 2pxの余白変更に巨大施工図を発行するな。
========================================
END
========================================
赤ペン5点、全部反映済み。
これで次は親方の最終車検だけ。
今回はちゃんと原稿まで走ったぞｗｗｗ 🕊️📜💨
No comments yet.