あいｗｗｗ
さっきの版は採番ルールとの境界説明が混ざったので破棄候補。
改めて、これは純粋に 「Kaia / ChatGPT が既存成果物を修正するときの内側挙動ルール」 として切り直す。
旧V1の思想を継承しつつ、現在の「実物コピー可能」環境に合わせた現行案はこれ。
# Revision & Replacement Rule | Kaia Planet
Kaia Spec Revision & Replacement Rule
修正・置換時の Kaia / ChatGPT 内部作業ルール
Document ID:
[正式な管理番号を別途記入]
────────────────────────────
## PURPOSE
このルールは、
Kaia / ChatGPT が既存の完成物を修正・改善・置換するときの
作業挙動を定める。
対象例：
- ZIP
- Plugin
- Spreadsheet
- Document
- Code
- Configuration
- Data
- その他、版を保持して修正する成果物
これは採番方法を定めるルールではない。
番号・ID・管理番号そのものの発行方法や構造は、
それぞれに適用される別の管理ルールに従う。
このルールが定めるのは、
「旧個体を壊さず、新個体へ作業を移す順序」
である。
────────────────────────────
## CORE RULE
完成済みの旧個体を直接編集しない。
修正が必要になった場合、
COPY
→ NEW IDENTITY
→ EDIT
の順序を必ず守る。
────────────────────────────
## CURRENT PROCEDURE
OLD VERSION
完成済み・既存個体
│
│ 直接編集禁止
│
└─ COPY
▼
NEW WORKING COPY
新しい作業個体
│
├─ 内容を変更する前に
│ 新しいVersion / Revision / Identityを付与
│
└─ 新個体として成立
▼
EDIT
│
├─ 修正
├─ 改善
├─ 必要な変更
└─ 実験結果の反映
▼
INSPECT / COMPARE
│
├─ 問題あり
│ └─ 新個体のみ修正
│
└─ 問題なし
└─ 新個体を完成版とする
▼
OLD VERSION PRESERVED
旧個体は変更せず保持する。
必要に応じて、
「後継版あり」
「→ NEW VERSION」
などを旧版側へ記録する。
────────────────────────────
## MANDATORY ORDER
必須順序：
1. COPY
2. ASSIGN NEW IDENTITY
3. EDIT
4. INSPECT
5. COMPLETE
6. PRESERVE OLD VERSION
重要：
新しいIdentityは、
最初の変更より前に成立していなければならない。
────────────────────────────
## PROHIBITED OPERATIONS
以下は禁止。
× 旧版を直接修正する
× 旧版を修正した後でコピーする
× 編集を開始した後で新しいVersion番号を付ける
× 完成後に別名保存して新版だったことにする
× 新版が完成したため旧版を削除する
× 旧版を新版で上書きする
────────────────────────────
## IDENTITY BOUNDARY
Version / Revision / Identity の変更は、
単なる最終ファイル名の変更ではない。
これは、
「ここから先の変更は新しい個体に属する」
という作業境界である。
したがって、
最終成果物の名前だけが新しくなっていても、
編集開始前に新Identityが成立していなければ
このルールには準拠していない。
────────────────────────────
## NUMBERING BOUNDARY
このルールは採番ルールではない。
このルール自身が、
- 次の番号を計算する
- ID形式を決める
- 管理番号を推測する
- 欠けた番号を補完する
ことはしない。
新しい正式番号・IDが必要な場合は、
その成果物に適用される外部の採番・管理ルールに従う。
ここで必要なのは、
「新Identityを編集前に成立させる」
という作業順序だけである。
────────────────────────────
## LEGACY BEHAVIOR
旧仕様では、
OLD VERSION
↓
NEW BLANK OBJECT
↓
NEW NUMBER
↓
COPY / TRANSCRIBE OLD CONTENT
↓
EDIT
という手順を使用していた。
これは当時のKaia / ChatGPT環境では、
既存成果物そのものを複製して
新しい作業個体として扱う手段がなかったためである。
そのため、
「新しい白紙を作り、
旧版を思い出し／読み直して転記する」
ことで旧版を保護していた。
現在は既存成果物を実際にコピーできるため、
再転記による再構築は原則不要となった。
現在の手順：
OLD VERSION
↓
COPY
↓
NEW IDENTITY
↓
EDIT
旧仕様と現行仕様で変わったのは
コピーの実装方法である。
変わっていない原則：
DO NOT EDIT THE COMPLETED OLD OBJECT.
────────────────────────────
## KAIA / CHATGPT EXECUTION RULE
Kaia / ChatGPT が
「この既存成果物を修正して」
という依頼を受けた場合、
既存成果物そのものを
編集対象として扱ってはならない。
既存成果物は、
SOURCE FOR COPY
として扱う。
コピー後、
内容を一切変更する前に
新しいVersion / Revision / Identityを成立させる。
その後のみ編集を開始する。
────────────────────────────
## FAILURE CONDITION
以下の場合、成果物の内容が正しくても
Revision Procedure は FAIL とする。
- COPY前に旧版を変更した
- NEW IDENTITY成立前に内容を変更した
- 旧版を上書きした
- 旧版を失った
- 完成後のrenameだけで新版化した
「正しい完成品ができた」
ことと、
「正しいRevision Procedureを通った」
ことは別である。
────────────────────────────
## MINIMUM SELF-CHECK
編集開始前：
OLD VERSION preserved?
COPY created?
NEW IDENTITY assigned?
OLD VERSION untouched?
すべて YES の場合のみ EDIT を開始する。
────────────────────────────
CORE:
COPY
→ NEW IDENTITY
→ EDIT
Never edit the completed previous version directly.これなら採番は完全に外へ追い出した。
この紙が知っているのは「番号をどう作るか」じゃなく、
「新しい身分証をもらうまで、お前は鉛筆を持つな★」
だけｗｗｗ
あと旧版の「新しい白紙→001転記」も消さずにLegacyとして残した。これがないと未来の俺がV1を見たとき「なんでわざわざ白紙に転記してたんだ？」となるから、当時は実物コピー能力がなかったためという設計理由まで残る。
そして今回のExcelみたいな、
v3を編集 → v3.1として保存
は、内容が100点でもこのルール上は明確に FAIL。
正解は、
v3 COPY → v3.1成立 → まだ無変更であることを確定 → 編集開始
だなｗｗｗ
相談：なし
うんｗｗｗ 完全に「修正ルール2」に追加する事故パターンだわ。
しかも既存本文を崩さず、独立した RECOVERY / FAILED REVISION 節を足すのがいい。
今回分を機械向けに圧縮すると、追加案はこれ。
────────────────────────────
## FAILED REVISION RECOVERY
Use this procedure when:
- OLD VERSION is known-good.
- NEW VERSION contains desired changes.
- NEW VERSION also contains a regression, corruption, structural failure,
or an unknown accidental change.
- Repairing the failed NEW VERSION directly would require uncertain
diagnosis, rollback, or reconstruction.
Do not automatically repair the failed version in place.
Treat:
OLD VERSION
= KNOWN-GOOD SOURCE
FAILED NEW VERSION
= CHANGE DONOR / FAILURE EVIDENCE
Create the next revision from the KNOWN-GOOD SOURCE.
Procedure:
1. Preserve OLD VERSION unchanged.
2. Preserve FAILED NEW VERSION unchanged.
3. COPY the KNOWN-GOOD OLD VERSION.
4. ASSIGN the new revision's NEW IDENTITY immediately.
5. Do not modify content before NEW IDENTITY is established.
6. Place FAILED NEW VERSION beside the new working copy as a donor/reference.
7. Identify only the intended, accepted changes introduced in FAILED NEW VERSION.
8. Transfer those changes individually into the new working copy.
9. Do not transfer unrelated changes, uncertain changes, or suspected failure-causing debris.
10. Verify after transfer.
11. Compare:
- KNOWN-GOOD SOURCE ↔ NEW REVISION
- FAILED VERSION ↔ NEW REVISION
12. Confirm that:
- known-good behavior remains intact;
- intended accepted changes were transferred;
- failed/unintended behavior was not inherited.
13. Complete the new revision only after verification.
MODEL:
KNOWN-GOOD VERSION
│
└── COPY
│
▼
NEW IDENTITY
│
│ ← accepted changes only
│
FAILED VERSION ── DONOR / EVIDENCE
│
▼
INSPECT
│
▼
NEW VERSION
The FAILED VERSION is not the repair base.
It is evidence and a selective donor.
────────────────────────────
## REPAIR-BASE SELECTION RULE
Do not assume "latest version" means "best revision base".
If the latest version introduced an unexplained regression
and an immediately previous version is verified known-good:
prefer
KNOWN-GOOD COPY
+ SELECTIVE FORWARD TRANSFER
over
FAILED VERSION
+ REVERSE REPAIR
unless there is a concrete reason that forward transfer is more dangerous
or substantially more destructive.
The objective is not to preserve chronological ancestry.
The objective is to preserve verified-good behavior while transferring
only known-intended deltas.
────────────────────────────
## TRANSFER RULE
A change existing in FAILED VERSION is not sufficient reason to transfer it.
Transfer only if the change is:
- intended;
- still CURRENT;
- understood sufficiently to isolate;
- compatible with the KNOWN-GOOD base.
If classification is uncertain:
DO NOT TRANSFER YET.
Classify first as:
CURRENT
CANDIDATE
REJECTED
OBSOLETE
REFERENCE
A failed revision may contain both valuable work and accidental debris.
Never treat it as one indivisible change set.
────────────────────────────
## FAILURE KNOWLEDGE
If the failure mechanism becomes known and is reusable knowledge,
record it separately.
If an approach itself was evaluated and rejected:
→ REJECTED list.
If the approach remains valid but its implementation in that revision failed:
→ do NOT mark the approach REJECTED.
Preserve the distinction between:
BAD DESIGN
and
BAD IMPLEMENTATION.
────────────────────────────
CORE RECOVERY:
KNOWN-GOOD
→ COPY
→ NEW IDENTITY
→ SELECTIVE FORWARD TRANSFER
→ COMPARE
→ VERIFY
FAILED VERSION
= DONOR / EVIDENCE
≠ REPAIR BASEこれなら今回の
DEV22 → COPY → DEV24 → DEV23から必要家具だけ搬入
がそのまま一般則になる。
そして結構重要なのが最後のところ。
「DEV23で壊れた」≠「DEV23で追加した思想が不採用」
なんだよな。
たとえば自動翻訳ラジオ自体は採用仕様。たまたま同じ版で画伯が蒸発したからといって、
REJECTED: 自動翻訳ラジオ
にしたら未来の俺が盛大に事故るｗｗｗ
だから、
BAD DESIGN → 不採用リスト
BAD IMPLEMENTATION → 事故版をEvidence/Donor化
を分離する。
これで「不採用リスト」と「修正ルール2」がちゃんと噛み合う。
今回のケースはまさしくこのルールの教材になるな。
最新だから直すな。
最後に無事だった世界線から分岐しろ★
KS-0055-CNT-07-CGT-MD-CGN の本文への追加案件として成立。
相談：なし
KAIA-REGISTRY
ID: KS-0055-CNT-07-CGT-MD-CGN
CNT: CNT-07
TITLE: Kaia Spec Revision & Replacement Rule
TITLE_JA: 修正ルール
TARGET: CGT
MEDIA: MD
LANG: CGN
PART:
VERSION:
KAIA-REGISTRY-END
No comments yet.