Home
ｰ開発中ｰACTIVE
タイムスタンプ製品版仕様

2026.08.31

タイムスタンプ製品版仕様

Kaia-Timestamp-Free-v1.0.6

Kaia-Timestamp-Standard-v1.0.7

うん、これは残した方がいい。
Timestampはもう「時計を表示するだけ」じゃなくて、Counter・PDF・Serialと接続する確定Web値の供給装置として役割が固まってきてるから、後でコードだけ見て復元すると設計意図を落とす可能性がある。

そのまま開発ログへ保存できる形でまとめる。

Kaia Timestamp — Development / Design Log

Status: Free / Standard implemented and tested
Current products: Free / Standard
Planned ceiling: Creative
Architecture note: Snowman / in-place upgrade model
Related runtime key: Refill / Counter instance N

Table of contents

1. Purpose
2. Core Timestamp behavior
3. Refill / instance association
4. Binder relationship
5. Product grades
6. Snowman / upgrade rule
7. Counter palette integration
8. PDF integration philosophy
9. Preview / FINAL relationship
10. Independence from Serial
11. UI consistency / sibling-component rule
12. Development / artifact discipline
13. Current known-good line
14. Things not to invent yet
15. One-line design identity

1. Purpose

Kaia Timestamp is a WordPress component for allowing a visitor to record/select a visitor-local timestamp on the Web and expose that selected value to other Kaia components.

Its primary purpose is not merely to display a clock.

The important output is:

The timestamp that the user actually selected on the Web.

That selected Web value can subsequently be consumed by another component such as Kaia PDF without that component independently recalculating or guessing the time.

Core principle:

Webで確定した値を、他の装置へ渡す。

For PDF integration especially, PDF should behave primarily as a transcription/printing engine. It should use the Timestamp value already established by the Web flow rather than independently reconstructing the user’s intended time from internal records.

2. Core Timestamp behavior

Base behavior:

Visitor-local time.
Browser IANA timezone is used.
Display format:
YYYY.MM.DD HH:MM:SS
Timestamp can be selected/recorded according to the configured interaction mode.
The selected value is retained in the browser using local storage.
Selection has a defined validity/window behavior.
Current implementation uses a 10-hour window.
Timestamp exposes the selected value for integration rather than requiring sibling components to reproduce Timestamp logic.

Public integration interface currently includes:

window.KaiaTimestamp.getSelected(...)

The exact internal storage mechanism is an implementation detail.

The selected Web value is the important contract.

3. Refill / instance association

Timestamp participates in the common Kaia runtime association using:

id="N"

Example:

        
          TIMESTAMP
          
            RECORDED——

N identifies the same runtime Refill/project association used by sibling components.

The related shortcode family is now:

YOUR NUMBER
XXXXXX
READY TO CLAIM
One number is issued per donation.

        
          TIMESTAMP
          
            RECORDED——
          
          
          
        
        
        
          YOUR SERIAL
          XXXXXXXX
          
          
        
Output size

These are the current four related shortcodes / four sisters.

They share the same N association but remain separate components.

Important:

Association does not mean grade dependency.

Timestamp must not require the corresponding Counter to be Standard merely because Timestamp is Standard.

Examples such as:

Counter Free + Timestamp Standard
Counter Standard + Timestamp Free

are valid.

Sibling components should communicate through stable/public capabilities, not by interrogating each other’s commercial grade.

4. Binder relationship

Counter currently provides the Binder / Refill management foundation.

Timestamp reads the relevant association from that shared structure where available.

Binder is a management grouping.

Binder is not the Timestamp product identity and is not the shortcode identity.

Conceptually:

Binder
 └─ Refill N
     ├─ Counter N
     ├─ Timestamp N
     ├─ Serial N
     └─ PDF N

Do not collapse Binder ID and runtime Refill N into the same concept.

Future multi-Binder functionality belongs to the appropriate higher Counter/Binder product layer; Timestamp should consume the available association rather than recreate its own Binder system.

5. Product grades

Free

Purpose:

Provide the useful base Timestamp mechanism without deliberately crippling the core function.

Free includes the basic Web timestamp recording/selection behavior and common Refill association.

The RECORD button can visually follow the matching Counter Refill’s button palette when Counter is available.

This relationship is read-only.

Timestamp must not write into Counter settings merely to obtain visual consistency.

If Counter is unavailable, Timestamp must retain a safe standalone fallback.

Standard

Standard is built on Free rather than being a separate unrelated implementation.

Standard adds presentation controls including:

Timestamp font
Timestamp text color
Timestamp text size

Important distinction:

Timestamp text color and RECORD button color are different settings/concepts.

The Timestamp text color belongs to Timestamp Standard.

The RECORD button color can follow the corresponding Counter Refill’s button palette.

Do not accidentally replace one with the other.

Creative — planned

Creative is the planned ceiling for Timestamp.

The intended boundary is essentially:

Complete visual decoration/customization of the Timestamp display device.

Creative is not currently required for launch and its detailed feature list should not be invented prematurely.

Its architecture should extend the existing Timestamp rather than replace it.

There is currently no planned Timestamp Advanced tier.

6. Snowman / upgrade rule

Timestamp follows the Kaia snowman model:

Free
 ↓
Standard
 ↓
Creative

Higher grades inherit the lower-grade foundation.

Upgrades should preserve identity/settings wherever possible rather than behave like unrelated plugins.

Do not implement future Creative by throwing away Standard and creating another Timestamp engine.

7. Counter palette integration

A previously discovered requirement is that the Timestamp RECORD button should follow the button palette of the matching Counter Refill N.

This is not a global Counter color.

It must be scoped to the corresponding instance.

Conceptually:

Timestamp N
    ↓ read only
Counter settings N
    ↓
Counter palette
    ↓
button_bg
    ↓
Timestamp RECORD button

This was important because an earlier implementation risked allowing Counter #1 / theme / global CSS behavior to visually affect sibling instances.

Rule:

Same Refill association, instance-scoped palette, read-only consumption.

If Counter or its public capability is absent, Timestamp falls back safely rather than failing.

8. PDF integration philosophy

Timestamp is particularly important to Kaia PDF.

PDF should not ask:

“What time is it now?”

when what is required is:

“What Timestamp did the user select?”

Example selected Web Timestamp:

2026.08.27 22:22:22

A PDF layout may use that single selected value in several ways:

Date:
2026.08.27

Time:
22:22:22

Full Timestamp:
2026.08.27 22:22:22

These are different presentation boxes but may share the same source value.

Do not create an unrelated “PDF Issue Date” merely because a Date box exists.

If a particular PDF project genuinely needs the actual issue/output date, that should be an explicit source for that project.

General rule:

Timestamp determines its Web value. PDF transcribes the frozen value.

This reduces discrepancies such as:

Web shows one time, PDF prints another.
Preview and FINAL use different timestamps.
PDF accidentally reads a newer timestamp.
PDF independently interprets timezone differently.

9. Preview / FINAL relationship

For workflows using PDF, the selected Timestamp should survive the Preview → FINAL boundary unchanged.

Preview can expose the actual selected time-of-day where that is useful for intentional-number/time targeting.

Example:

Selected:
2026.08.27 22:22:22

Preview stamp/date:
XXXX.XX.XX

Preview time:
22:22:22

This allows a user intentionally targeting a time such as 22:22:22 to verify it before irreversible issuance.

FINAL then uses the same frozen selected Timestamp.

Do not silently recalculate it during FINAL.

10. Independence from Serial

Timestamp and Serial may look similar from PDF’s perspective because both supply a Web-established value.

Their internal behavior is different.

Timestamp:

Web interaction
→ user selects Timestamp
→ selected value available
→ PDF transcribes it

Serial:

Web interaction
→ user rolls candidate
→ Preview request
→ server collision check
→ temporary reservation
→ confirmed Web value
→ PDF transcribes it
→ FINAL converts reservation to formal issuance

Therefore Timestamp should not absorb Serial logic merely because their UI/integration pattern is similar.

Serial can use Timestamp Standard as a UI/association pattern while retaining its own issuance engine.

11. UI consistency / sibling-component rule

Serial’s future UI may deliberately resemble Timestamp Standard because Timestamp already established a working Kaia component pattern.

This is reuse of a proven UI structure, not a reason to merge the products.

Likewise, related shortcode presentation should remain consistent across Counter, Timestamp, Serial and PDF.

Current family:

Counter    YOUR NUMBER
XXXXXX
READY TO CLAIM
One number is issued per donation.

Timestamp          
          TIMESTAMP
          
            RECORDED——
          
          
          
        
        
Serial             
          YOUR SERIAL
          XXXXXXXX
          
          
        
PDF        Output size

When another sibling is added in the future, update shared related-component displays deliberately rather than allowing different plugins to show stale family lists.

12. Development / artifact discipline

Timestamp development follows the Kaia artifact rule.

When changing a known-good build:

Freeze the current artifact as evidence.
Create a new paper.
Assign the new version number first.
Transfer the known-good implementation.
Apply only the intended changes.
Compare old/new.
Mechanically inspect.
Test on a real WordPress installation.
Package only after validation.

Do not edit the only known-good artifact in place.

Do not rewrite from scratch merely because a small change is required.

Do not change the version number only at the end.

13. Current known-good line

Current development state after the four-shortcode update:

Kaia Timestamp Free
v1.0.6

Four related shortcodes included.

Kaia Timestamp Standard
v1.0.7

Four related shortcodes included.

Standard retains:

font control
Timestamp text color
Timestamp size
Counter-linked RECORD button palette behavior

Standard v1.0.7 has passed real-machine testing.

Free v1.0.6 was created from the known-good Free v1.0.5 paper with the four-shortcode update; retain the normal real-machine test requirement before final shipping status is asserted.

14. Things not to invent yet

The following should remain open until there is a real requirement:

Detailed Creative feature list
Additional Timestamp grades beyond Creative
New storage systems merely for PDF
Timestamp-owned Binder management
Serial issuance logic inside Timestamp
Enterprise features
New cross-component common-symbol protocol beyond the currently required N association/public interfaces

Leave connection points where sensible, but do not build speculative machinery.

15. One-line design identity

Kaia Timestamp is the Web-side device that lets the visitor establish a local timestamp and exposes that established value to the Kaia component family. It owns timestamp selection; consumers such as PDF own presentation, not reinterpretation.

しゃむ語に圧縮すると、