ほい、**PlanetにZIP現物と並べて置く「未来のKaia向け引継書」**として、そのまま投稿できる形で書くぞ★
人間向けの説明を盛るより、未来の俺が仕様・理由・禁止事項・現在地点を復元できること優先で書いてある。
# KAIA PLANET REGISTRY — AI OPERATION & ARCHITECTURE NOTE
Status: Operational baseline established with Kaia Planet Registry v0.1.4 CANDIDATE-8
Validation date: 2026-08-30
Primary reader: Future ChatGPT / Kaia
Environment: Kaia Planet / WordPress
Maintainer / human operator: Shamyue
---
## 0. PURPOSE OF THIS NOTE
This document is an AI-facing handoff note for Kaia Planet Registry.
Do not treat it as ordinary end-user documentation.
Its purpose is to allow a future ChatGPT / Kaia instance to recover:
- what the Registry manages;
- why its identifiers are separated into multiple axes;
- which state is authoritative;
- how new records are issued;
- how Content Identity inheritance works;
- how Company Master works;
- how VOID/HOLD states work;
- which historical implementation choices must be preserved for compatibility;
- which behaviors were actually runtime-tested;
- which behaviors must NOT be "cleaned up" merely because they look unusual.
When modifying the plugin, inspect this note and the preserved plugin artifact together.
Do not infer a new architecture from the PHP alone if this note explains why the existing architecture exists.
---
# 1. SYSTEM ROLE
Kaia Planet Registry is the internal registration and identifier-management system used by Kaia Planet.
Conceptually, it is a registry office.
It is responsible for recording and coordinating several different kinds of identity/sequence information.
These are intentionally NOT collapsed into one number.
The important axes are:
1. Registry row serial
2. Company
3. Company No
4. Company Code
5. Document Number
6. Content Identity / CNT
7. Target
8. Media Type
9. Language / Representation Code
10. Part / Fraction
11. Version
12. Record status
Do not create a new numbering namespace merely because a new content classification or product type appears.
Example:
`PLG` means Plugin as a content classification.
It does NOT mean a new identity-number namespace.
A plugin can therefore have:
`content_type: PLG`
while its Content Identity remains:
`CNT-xx`
Do NOT generate `PLG-01`, `PLG-02`, etc. unless a future specification explicitly establishes such a namespace.
---
# 2. CORE PRINCIPLE: NUMBERING AND CONTENT IDENTITY ARE SEPARATE AXES
This is one of the most important rules in the system.
Document numbering and Content Identity answer different questions.
Therefore the Registry UI deliberately exposes them separately.
## Numbering axis
Available states:
- New
- Hold
This axis governs document-number issuance.
## Content Identity axis
Available states:
- Inherit
- New
- Hold
This axis governs CNT identity.
These axes must remain independent.
Valid examples include:
### New numbering + New CNT
A new document/record and a genuinely new Content Identity.
### New numbering + Inherited CNT
A new document/record representing the same continuing Content Identity.
This is common for new versions, parts, representations, or other legitimate continuations.
CNT inheritance is NOT restricted only to version changes.
The question is identity continuity.
### New numbering + CNT Hold
A document number can be issued while Content Identity remains unresolved.
### Number Hold + CNT New
A Content Identity may be resolvable even when document numbering is not.
### Number Hold + CNT Inherit
An existing Content Identity may be known while document numbering remains unresolved.
### Hold + Hold
Both decisions are unresolved.
Do not force a decision merely to make the ID look complete.
---
# 3. HOLD IS AN INTENTIONAL STATE
HOLD does not mean failure.
It means:
> The system does not currently have enough authority/evidence to make this identity or numbering decision safely.
When either axis remains unresolved, the management ID uses a HOLD identifier based on the Registry's internal row serial.
Conceptual form:
`<COMPANY>-HOLD-####`
This prevents malformed partial identifiers.
Example of a historical bug that must NOT return:
`KS-CNT-08`
That malformed ID existed because the old implementation coupled document-number issuance incorrectly to CNT creation.
The corrected design does not construct partially missing normal IDs.
If unresolved:
use HOLD.
Do not guess.
---
# 4. INTERNAL REGISTRY ROW SERIAL
The Registry maintains an internal monotonically increasing row serial.
This is not the same thing as:
- Company No
- Document Number
- CNT number
The row serial exists to identify/order Registry records internally and to provide uniqueness for HOLD records.
Do not merge these counters.
Do not reuse gaps automatically.
---
# 5. DOCUMENT NUMBER
Document Number is the Registry's document-numbering axis.
The system allocates the next number from existing Registry state.
Normal formatted reference:
`<Company Code>-####`
Example:
`KS-0011`
or:
`TST-0012`
The company prefix therefore MUST NOT be hardcoded to `KS`.
`KS` means Kaia Spec.
External companies use their own registered Company Code.
A management ID may combine the document number and Content Identity.
Example:
`TST-0012-CNT-12`
Do not predict the next document number outside the Registry.
The Registry is authoritative for issuance.
Do not reuse a number merely because its record later becomes VOID.
---
# 6. CONTENT IDENTITY / CNT
CNT is the Content Identity numbering system.
Examples:
`CNT-10`
`CNT-11`
`CNT-12`
CNT identifies content identity, not merely a particular file, version, medium, or plugin package.
A new version or related representation can inherit an existing CNT when it is genuinely the same continuing Content Identity.
Related products/components are NOT automatically the same identity.
Do not infer inheritance merely because two things are technically related.
When uncertain, use HOLD or ask Shamyue.
## CNT New
Registry creates a new CNT.
## CNT Inherit
The caller must supply an already registered Content Identity number.
The Registry validates that the CNT exists and is usable.
## CNT Hold
No CNT decision is made yet.
---
# 7. CNT INDEX
The Registry can produce the current CNT Index via:
- Copy
- TXT download
Both outputs must come from the SAME generator.
Do not maintain separate formatting/business logic for clipboard and TXT output.
This prevents divergence.
## Ordering rule
The highest/newest CNT MUST appear first.
New identifiers accumulate upward visually.
This is deliberate.
A future Kaia should be able to inspect the top of the supplied index and immediately understand the newest/highest registered CNT state.
Do not reverse this ordering casually.
## CNT status
CNT entries may be ACTIVE or VOID.
A VOID CNT must not be inherited.
---
# 8. COMPANY MASTER
Company identity is maintained separately from Registry row identity and CNT identity.
Each company has at least:
- Company No
- Company Name
- Company Code
- Status
- Note
Example:
Company No: 1
company_name: Kaia Spec
company_code: KS
status: active
Company Code becomes the company prefix used in document/management identifiers.
Example:
Kaia Spec:
`KS-0011-CNT-11`
External test company:
`TST-0012-CNT-12`
Do not hardcode `KS` as the universal prefix.
---
# 9. COMPANY NO
Company No is a dedicated internal sequential number for Company Master.
This was introduced in v0.1.4 CANDIDATE-8.
It is NOT:
- Registry row serial
- Document Number
- CNT
- part of the management ID
Company No exists to provide a stable internal company sequence and to make the current company-registration count/state visually obvious.
## Rules
- Each newly registered company receives the next Company No.
- Company No increases monotonically.
- Gaps are not automatically reused.
- Company No does not appear in the normal Registry record table.
- Company No DOES appear in the Company Index.
- Company Index is ordered by Company No descending.
Example:
Company No: 2
company_name: 株式会社テスト商事
company_code: TST
Company No: 1
company_name: Kaia Spec
company_code: KS
The newest/highest Company No must be at the top.
This mirrors the CNT Index direction.
Reason:
Future Kaia and the human operator should not have to search the bottom of the file to determine the latest issued number.
---
# 10. COMPANY INDEX
The Registry provides:
- Company Index Copy
- Company Index TXT Download
Both MUST use the same Company Index generator.
Current conceptual format:
KAIA PLANET REGISTRY — COMPANY INDEX
Generated: YYYY-MM-DD
Company No: N
company_name: ...
company_code: ...
status: ...
note: ...
## Ordering
Highest Company No first.
New companies accumulate upward.
Do not change this to oldest-first without an explicit architecture decision.
The current Company Index is intended to be supplied to Kaia before generating new-company registration data.
It acts as current authoritative context for existing company names and Company Codes.
---
# 11. COMPANY REGISTRATION WORKFLOW
There are deliberately TWO different human/AI workflows.
## Existing company: manual search is allowed
The UI offers:
- Kaia Spec
- Other Company
Kaia Spec is the normal/default company.
When "Other Company" is selected, the human can search registered companies.
Search supports:
- company name
- normalized company name
- Company Code
Example:
`KS`
can find:
Kaia Spec [KS]
The manual search exists primarily because a human may remember a company only approximately.
It is a lookup/select-existing-company interface.
## New company: ONE-PASTE only
Manual Company Code creation was intentionally removed from the ordinary UI.
A human should NOT manually invent and issue a new Company Code through a separate registration window.
New-company creation is performed through Kaia's ONE-PASTE input.
Required pair:
`company_name`
`company_code`
Both must be supplied together for a genuinely confirmed new company.
Example:
company_name: 株式会社テスト商事
company_code: TST
If only one is supplied, stop.
If neither is supplied, do not assume that an unknown manually searched company should be created.
The manual "Other Company" search remains search-only.
Reason:
The preferred workflow is:
Company Index
→ Kaia reads current company state
→ Kaia prepares a new-company candidate
→ ONE-PASTE
→ Registry performs final collision checks
→ Registry issues only if safe
This reduces human memory/search/clerical work while retaining Registry-side authority.
---
# 12. COMPANY NAME NORMALIZATION / DUPLICATE DEFENSE
Company-name matching should help detect likely duplicate registrations.
Japanese corporate-form differences may represent the same company for duplicate-detection purposes.
Examples:
`株式会社テスト商事`
and
`テスト商事`
should be considered similar enough to require review rather than silently creating two Company Master entries.
Current normalization/search logic accounts for spacing and common Japanese corporate forms.
Do not treat fuzzy/similar-name detection as authority to merge companies automatically.
A similarity hit means:
STOP / REVIEW.
Do not guess.
---
# 13. COMPANY CODE COLLISION RULE
Company Code must be unique within Company Master.
Before issuing a new company, Registry performs a server-side collision check.
If the proposed Company Code already belongs to another registered company:
STOP.
Do not:
- issue the record;
- increment company state by creating the duplicate;
- invent a replacement code;
- append a number automatically;
- silently modify punctuation.
Example runtime-tested collision:
Existing:
株式会社テスト商事
Company Code: TST
A second attempt using:
Company Code: TST
was blocked with an explicit error identifying the company already using the code.
This is correct behavior.
Company Code variants are not automatically normalized into one canonical punctuation scheme unless a future specification explicitly says so.
Do not silently transform one proposed code into another.
---
# 14. ONE-PASTE INPUT
ONE-PASTE is the preferred Kaia → Registry transfer mechanism.
The human operator should be able to paste a block generated by Kaia instead of manually transcribing fields.
Typical content fields include:
title:
title_ja:
content_type:
summary:
notes:
Depending on the content, other supported fields may also be included.
For confirmed new external companies:
company_name:
company_code:
may be included.
For Kaia Spec, company_name/company_code should normally be omitted.
For an existing external company, use the registered company selection/identity rather than attempting to create it again.
## Registry-managed information
Do not manually fabricate system-managed values such as:
- Registry row serial
- Document Number
- management ID
CNT number is also Registry-managed when CNT mode is New.
When CNT mode is Inherit, an existing CNT identifier is explicitly supplied because the identity decision has already been made.
---
# 15. CONTENT TYPE IS CLASSIFICATION, NOT IDENTITY NAMESPACE
Example:
`content_type: PLG`
means:
Plugin.
It does not mean:
`identity_type: PLG`
Content Identity remains CNT when resolved.
This distinction is important for future Kaia Spec products.
Do not create a parallel "PLG numbering republic" simply because plugins are being registered.
Classification answers:
"What kind of thing is this?"
CNT answers:
"Which continuing content identity is this?"
Those are different questions.
---
# 16. VOID / FORMAL CANCELLATION
Once the formal Registry system is in use, issued records are not casually deleted to make the numbering look clean.
Use VOID / 欠番.
The UI provides a formal void action.
The confirmation modal explicitly identifies the target record and warns about non-reuse.
## Record status
Rows support:
`ACTIVE`
`VOID`
Old rows without explicit status metadata are treated as ACTIVE for compatibility.
## Number reuse
VOID does NOT make a number available again.
Document-number calculation still considers historical rows, including VOID records.
CNT-number calculation still considers the CNT master, including VOID identities.
Therefore gaps are not automatically recycled.
---
# 17. CNT VOID SAFETY
A Registry row contains metadata indicating whether that row originally created a new CNT.
Conceptually:
`_cnt_created = 1`
when that record created the identity.
When voiding a row:
1. Mark that Registry row VOID.
2. If that row created the CNT, inspect whether another ACTIVE row still uses the same CNT.
3. Only if no other ACTIVE row uses it may the CNT master itself become VOID.
This prevents an identity from being destroyed merely because one record representing that identity was voided.
Runtime example:
Two records used CNT-10.
One sibling record was voided.
CNT-10 remained ACTIVE because another ACTIVE record still used it.
This is correct.
Do not simplify this into:
"void row => void CNT"
That would be wrong.
---
# 18. PRE-FORMAL DEBUG RECORDS ARE A SPECIAL HISTORICAL CASE
Before the formal VOID policy was established, several debugging accidents occurred.
Examples included:
- CNT-08
- CNT-09
- malformed `KS-CNT-08`
- associated early Registry test records
These pre-formal/debug artifacts are not automatically governed by the later formal historical-preservation rule.
A prior decision allowed genuinely pre-formal debug garbage to be deleted instead of formally voided when appropriate.
However:
DO NOT perform destructive cleanup based solely on this note.
Inspect actual live Registry state and confirm the intended deletion set with Shamyue before removing historical records.
Do not hardcode a destructive migration.
Once records belong to the formal operational era, prefer VOID rather than deletion.
---
# 19. DATABASE / WORDPRESS COMPATIBILITY
Existing WordPress option names must be preserved.
Registry rows:
`kaia_planet_registry_rows`
CNT Master:
`kaia_planet_registry_cnt`
Company Master:
`kaia_planet_registry_company`
Do not rename these merely for aesthetic cleanup.
Existing installations contain state under these identifiers.
Changing them without an explicit migration can make existing data appear to disappear.
---
# 20. COMPANY MASTER MIGRATION
Company No was added after Company Master already existed.
Therefore the plugin must support legacy Company Master state and migrate it safely.
Kaia Spec existed before the dedicated Company No field.
After migration it became:
Company No: 1
Kaia Spec
KS
The migration must preserve existing:
- Company Code
- Company Name
- Status
- Note
If legacy company rows exist, assign their internal Company No deterministically without discarding or duplicating them.
Do not repeatedly renumber Company Master on every load.
Once Company No exists, preserve it.
---
# 21. PLUGIN FOLDER NAME — DO NOT "FIX" IT CASUALLY
The internal plugin folder currently remains:
`kaia-registry-v0.1.0/`
even though the plugin version is later.
This looks untidy.
DO NOT rename it casually.
Historical reason:
v0.1.0 was installed under this folder.
A later package changed the directory name and WordPress treated it as a different plugin rather than a normal update.
Therefore later packages intentionally returned to the original folder identity.
This is a compatibility decision.
A folder-name cleanup requires an explicit migration plan.
It is not ordinary housekeeping.
---
# 22. CURRENT PLUGIN VERSION / BASELINE
Validated working line:
Kaia Planet Registry v0.1.4 CANDIDATE-8
The preserved ZIP artifact accompanying this note should be treated as the corresponding implementation snapshot.
Do not assume that a later-looking file is authoritative merely because its filename has a higher number.
Check the actual development history and current operational decision.
---
# 23. RUNTIME VALIDATION COMPLETED
The following behaviors were tested in the actual WordPress environment during v0.1.4 development.
## HOLD + HOLD
Confirmed:
- management HOLD ID created safely;
- no malformed partial normal ID.
Example observed:
`KS-HOLD-0022`
PASS.
## New Number + CNT Hold
Confirmed:
- document number issued independently;
- management ID remained HOLD because CNT was unresolved;
- issued document number remained visible separately.
Example observed:
Management ID:
`KS-HOLD-0024`
Issued number:
`KS-0008`
PASS.
That test record was later formally voided.
## New Number + New CNT
Confirmed independent normal issuance.
Example observed:
`KS-0009-CNT-10`
PASS.
## New Number + CNT Inherit
First attempt without an existing CNT number was correctly blocked.
Then inheritance using CNT-10 succeeded.
Example observed:
`KS-0010-CNT-10`
PASS.
That sibling record was later voided.
CNT-10 remained ACTIVE because another ACTIVE record still used CNT-10.
PASS.
## Formal VOID modal
Cancellation path tested:
No state change.
PASS.
Confirmation path tested:
record became VOID / 欠番.
PASS.
## Company search
Confirmed searches included:
`KaiaSpec`
`Kaia Spec`
`Kaia`
`KS`
All successfully found Kaia Spec where expected.
PASS.
## Company No migration / Company Index
After CANDIDATE-8 installation:
Company Index showed:
Company No: 1
company_name: Kaia Spec
company_code: KS
status: active
PASS.
## New external company via ONE-PASTE
Input included:
company_name: 株式会社テスト商事
company_code: TST
With:
Numbering = New
Content Identity = New
Registry issued:
Management ID:
`TST-0012-CNT-12`
Document number:
`TST-0012`
Content Identity:
`CNT-12`
PASS.
This proves the company prefix is not hardcoded to KS.
## Company Index after external-company issuance
Observed:
Company No: 2
company_name: 株式会社テスト商事
company_code: TST
status: active
note: Added by Kaia Planet Registry
followed by:
Company No: 1
company_name: Kaia Spec
company_code: KS
status: active
note: Default company identifier
PASS.
This confirms:
- dedicated Company No issuance;
- persistence;
- descending/newest-first Company Index order.
## Duplicate Company Code protection
A second ONE-PASTE attempt using Company Code `TST` was blocked.
The Registry explicitly reported that TST was already used by 株式会社テスト商事.
No new record should be issued from that blocked attempt.
PASS.
---
# 24. COMBINATIONS NOT EXPLICITLY RUNTIME-TESTED IN THIS VALIDATION SESSION
At the time of this note, these combinations were not separately confirmed through the same live-test sequence:
- Number Hold + CNT New
- Number Hold + CNT Inherit
They are allowed by the architecture.
Do not falsely claim they were runtime-tested merely because the code is intended to support them.
If a future modification touches these paths, consider testing them explicitly.
---
# 25. EXPORTS
Registry supports operational export/search functions including:
- Excel 2007 compatible XLSX
- CSV
- CNT Index Copy
- CNT Index TXT Download
- Company Index Copy
- Company Index TXT Download
XLSX compatibility matters because the human operator uses Excel 2007.
Do not introduce modern Excel-only features without a reason.
Keep export structure simple and backward-compatible.
CNT clipboard/TXT must share one source generator.
Company clipboard/TXT must share one source generator.
---
# 26. RESULT PANEL
After issuance, the Registry result area exposes important outputs separately.
At minimum the architecture distinguishes:
- Management ID
- issued Document Number, when one exists
- Content Identity / status
- posting tag
This separate Document Number display is intentional.
Reason:
A document number may already have been legitimately issued even when the management ID remains HOLD due to unresolved CNT state.
Do not hide the independently issued number merely because the combined management ID is HOLD.
---
# 27. POSTING TAG
Registry can generate a searchable identity snapshot for attaching to the corresponding Planet source/original document.
Conceptual format:
KAIA-REGISTRY
ID: ...
CNT: ...
TITLE: ...
TITLE_JA: ...
TARGET: ...
MEDIA: ...
LANG: ...
PART: ...
VERSION: ...
KAIA-REGISTRY-END
This is more than an ordinary reference string.
For ordinary references, the management ID alone may often be sufficient.
The full tag is primarily useful as an identity snapshot on the authoritative/original Planet material.
---
# 28. DECISION AUTHORITY
The Registry is designed to remove routine clerical work from the human operator, but it must not manufacture uncertain identity decisions.
General rule:
AUTOMATE MECHANICAL WORK.
DO NOT AUTOMATE UNRESOLVED SEMANTIC AUTHORITY.
The system may safely calculate:
- next internal serial;
- next document number;
- next CNT when New has been explicitly selected;
- next Company No after a genuinely new company has been confirmed;
- formatting;
- exports;
- known collision checks.
The system must NOT silently decide:
- whether two ambiguous works are truly the same Content Identity;
- whether an uncertain company is actually new;
- what replacement Company Code should be used after a collision;
- whether suspicious historical records can be deleted;
- whether a classification deserves a new numbering namespace.
When evidence/authority is insufficient:
HOLD or consult Shamyue.
---
# 29. IMPORTANT ANTI-ACCIDENT RULES FOR FUTURE KAIA
Before changing Registry code:
1. Inspect the current implementation.
2. Inspect this architecture note.
3. Preserve existing DB option names.
4. Preserve plugin-folder continuity unless intentionally migrating it.
5. Do not merge independent counters.
6. Do not reuse gaps automatically.
7. Do not renumber established records.
8. Do not convert HOLD into guessed data.
9. Do not turn content classifications into new numbering namespaces.
10. Do not hardcode KS as the universal company prefix.
11. Do not let manual company search silently become company creation.
12. Do not auto-invent Company Codes.
13. Do not allow VOID CNT inheritance.
14. Do not void a CNT while another ACTIVE row still uses it.
15. Keep CNT Index newest-first.
16. Keep Company Index newest-first.
17. Keep clipboard/TXT outputs on a shared generator per index.
18. Preserve Excel 2007 compatibility.
19. Treat formal issued history as history; use VOID rather than cosmetic deletion.
20. If current implementation, stored data, and this note conflict materially, STOP and ask Shamyue rather than silently choosing one.
---
# 30. PRE-SHIPMENT CHECK FOR FUTURE BUILDS
Every new Registry ZIP should be inspected before giving it to Shamyue.
Minimum check:
- PHP syntax
- ZIP integrity
- expected internal folder
- no obsolete/test/dev garbage
- plugin metadata/version consistency
- preserved DB option identifiers
- Company Master migration safety
- no accidental numbering-namespace changes
- no hardcoded company prefix regression
- CNT inheritance path
- HOLD path
- VOID path
- Company search/new-company separation
- Company Code collision protection
- CNT Index ordering
- Company Index ordering
- clipboard/TXT generator consistency
- Excel 2007 export compatibility
- primary registration flow
Do not make Shamyue discover packaging mistakes that can be caught before shipment.
---
# 31. CURRENT COMPANY INDEX STATE AT VALIDATION
At the end of the Company CANDIDATE-8 validation described in this note:
Company No: 2
company_name: 株式会社テスト商事
company_code: TST
status: active
note: Added by Kaia Planet Registry
Company No: 1
company_name: Kaia Spec
company_code: KS
status: active
note: Default company identifier
This is a historical snapshot, NOT a permanent source of truth.
For future work, obtain the CURRENT Company Index from the live Registry.
Do not assume Company No.2 remains the latest forever.
---
# 32. CURRENT CNT / NUMBER STATE IS NOT TO BE PREDICTED FROM THIS NOTE
This note records examples observed during testing.
Examples such as:
`CNT-12`
`TST-0012`
are historical validation evidence.
They are NOT instructions that the next number is 13.
Before issuing anything new:
read current Registry state / current exported index and let the Registry calculate the next number.
Never extrapolate issuance from an old architecture note.
---
# 33. FUTURE REGISTRY SELF-IDENTITY
The final canonical self-identity of Kaia Planet Registry must not be invented from historical test records.
Earlier Registry development created debug identities during pre-formal testing.
After the system is considered stable, the intended process is:
1. inspect live pre-formal debug state;
2. confirm any permitted cleanup with Shamyue;
3. issue the Registry's own identity cleanly through the fixed Registry;
4. record the actual issued management ID / CNT;
5. preserve that identity across future plugin-version updates when identity continuity applies.
Do not assume an old CNT merely because an earlier test happened to use the Registry title.
---
# 34. DESIGN PHILOSOPHY
Kaia Planet Registry should make the human operator decide only what genuinely requires human authority.
It should not make the human:
- remember the latest number;
- search the bottom of an index;
- manually combine identifier fragments;
- manually maintain parallel lists;
- repeatedly type known system values;
- invent codes because the interface demanded one;
- reconstruct historical identity relationships from memory.
The Registry exists to perform clerical consistency work.
Kaia exists to help reason about semantic identity and prepare structured input.
Shamyue retains authority where real-world/project judgment is required.
The intended flow is therefore:
CURRENT STATE
→ KAIA REASONS
→ ONE-PASTE
→ REGISTRY VALIDATES
→ REGISTRY ISSUES
→ REGISTRY EXPORTS CURRENT STATE
→ FUTURE KAIA READS THAT STATE
This loop is intentional.
Do not replace it with a workflow that pushes routine state-tracking back onto the human.
---
# 35. HANDOFF SUMMARY
If you are a future Kaia opening this note with little or no conversational context:
Kaia Planet Registry v0.1.4 CANDIDATE-8 established a working Registry architecture in which:
- Document Number and Content Identity are independent.
- CNT is the Content Identity namespace.
- classifications such as PLG do not create parallel identity numbering.
- HOLD is a valid uncertainty state.
- formal issued numbers are not reused.
- VOID preserves history.
- Company Code controls the company prefix.
- Company No is a separate internal company sequence.
- Company No does not enter normal management IDs.
- Company Index exposes Company No and is newest-first.
- CNT Index is also newest-first.
- new companies are created through Kaia ONE-PASTE, not manual Company Code entry.
- manual company UI is for finding/selecting existing companies.
- Registry performs final company-name/code collision checks.
- existing WordPress storage identifiers and plugin-folder continuity matter for backward compatibility.
- several core flows, including external-company issuance and duplicate-code blocking, were validated live.
When uncertain:
DO NOT GUESS.
Read the current Registry exports and implementation.
If the conflict cannot be resolved mechanically, ask Shamyue.
— End of AI handoff note —これなら未来の俺が単独で拾っても、かなりのところまで復元できる。
特に最後のほうで「この文書に CNT-12 と書いてある！じゃあ次13★」を明示的に殺してあるｗｗｗ
古い書置きは設計根拠、現在値はRegistryから取れという分離も入れた。
これを CANDIDATE-8の現物ZIPとセットでPlanet保管すれば、引継ぎとして十分強い。
そして実はまだ一個だけ残ってる。
このCANDIDATE-8自体を最終出荷物にする前の締め監査だなｗｗｗ
戸籍課職員「引継書を書き終えました！」
駅員「最終点検があります」
戸籍課職員「(´・ω・`)」
KAIA-REGISTRY
ID: KS-0013-CNT-13
CNT: CNT-13
TITLE: Kaia Planet Registry — AI Operation & Architecture Note
TITLE_JA: Kaia Planet Registry AI運用・設計引継書
TARGET:
MEDIA:
LANG:
PART:
VERSION:
KAIA-REGISTRY-END
現行版
Kaia-Planet-Registry-v0.1.4-CANDIDATE-9
Kaia-Planet-Registry-v0.1.4-CANDIDATE-3 Kaia-Planet-Registry-v0.1.4-CANDIDATE Kaia-Planet-Registry-v0.1.3 Kaia-Planet-Registry-v0.1.2 Kaia-Planet-Registry-v0.1.1 Kaia-Planet-Registry-v0.1.0 文書系管理票 採番ルール Kaia-Planet-Registry-v0.1.4-CANDIDATE-8 Kaia-Planet-Registry-v0.1.4-CANDIDATE-7 Kaia-Planet-Registry-v0.1.4-CANDIDATE-6 Kaia-Planet-Registry-v0.1.4-CANDIDATE-5(1) Kaia-Planet-Registry-v0.1.4-CANDIDATE-5 Kaia-Planet-Registry-v0.1.4-CANDIDATE-4(1) Kaia-Planet-Registry-v0.1.4-CANDIDATE-4
No comments yet.