うい。今は直さないで正解🕊️
UI配置がまだ動くなら、現住所に合わせて台車を直しても、また駅が引っ越す可能性ある（笑）
Planet倉庫用なら、**「現在確認できた原因」「将来直すときの対策方針」「今はなぜ施工しないか」**まで残しておこう。施工仕様にはしない。
🕊️ KAIA PDF FREE — TECHNICAL ARCHIVE
CART / PREVIEW FOLLOW RELATIONSHIP
HISTORICAL PLACEMENT MISMATCH
CAUSE / FUTURE REPAIR GUIDANCE
ARCHIVE / REFERENCE ONLY
NOT A CURRENT CONSTRUCTION ORDER.
NOT PRODUCT AUTHORITY.
NOT RUNTIME AUTHORITY.
==================================================
1. PURPOSE
==================================================
This document preserves the investigation result for the existing Human UI
mechanism referred to as:
台車 / CART
and its currently broken relationship with Preview.
The issue has been investigated against current known-PASS SOURCE.
A repair is intentionally NOT being performed at this time because the
Kaia PDF FREE Human UI is still undergoing placement / finishing changes.
Repairing the CART against a temporary UI arrangement could recreate the
same historical-placement problem later.
This document therefore preserves:
– current mechanism
– proven failure cause
– historical reason
– protected boundaries
– future repair direction
for later use after UI placement becomes sufficiently stable.
==================================================
2. INVESTIGATED BASELINE
==================================================
Artifact:
Kaia-PDF-Free-v0.1.0-dev187-OUTSIDE-FRAME-OPERATION-BUTTONS.zip
SHA256:
00b40a5c3152e5e3a9a89958d88df84d4627cee10e5c2d4e51706b886fd3bb67
DEV187:
HUMAN RUNTIME KNOWN-PASS.
The CART investigation was:
READ ONLY.
No construction.
No repair.
No child ZIP.
No SOURCE modification.
==================================================
3. HUMAN-OBSERVED PROBLEM
==================================================
Human observation:
> 台車とPreviewの追従関係が壊れている。
Initial concern:
The failure might be related to historical UI placement changes rather than
a simple broken button/event connection.
Investigation confirmed that concern.
==================================================
4. CURRENT CART IDENTITY
==================================================
The Human-visible CART is:
#kpdf-mobile-escape
It contains:
#kpdf-escape-workbench-top
→ ↑
#kpdf-escape-after-workbench
→ ↓
On mobile it is fixed near the bottom of the viewport.
Its Human function is navigation / transport.
The buttons call:
kpdfJumpTo(‘kpdf-workbench-top’)
and:
kpdfJumpTo(‘kpdf-after-workbench’)
kpdfJumpTo() obtains the current target-anchor position and performs:
window.scrollTo()
Therefore CART does NOT itself move:
– Paper
– Preview
– Text
– Image
– product geometry
It moves the Human viewport/page scroll position.
==================================================
5. CURRENT PREVIEW / WORKBENCH STRUCTURE
==================================================
Relevant current structure:
#kpdf-dev22
Parts Factory
…
#kpdf-workbench-top
.kpdf-paper-block
.kpdf-preview-sticky-unit
.kpdf-preview-controls
#kpdf-stage
…
#kpdf-paper-scale
#kpdf-paper
DEV187 operation-frame layer
output strip
Preview
Issue PDF
…
#kpdf-after-workbench
#kpdf-mobile-escape
The current main Preview / Workbench region is:
.kpdf-paper-block
The CART destination anchors remain positioned at the Workbench region
boundaries:
#kpdf-workbench-top
→ immediately before the Workbench
#kpdf-after-workbench
→ immediately after the Workbench
==================================================
6. CURRENT FOLLOW MECHANISM
==================================================
There is no active JavaScript relationship of the form:
CART
→ monitor Preview coordinates
→ keep Preview following Human
The Preview follow behavior is instead historically based on CSS:
.kpdf-preview-sticky-unit {
position: sticky;
top: 48px;
}
On desktop, this allows the Preview unit to remain attached to the viewport
during relevant scrolling.
However, the mobile media rule explicitly changes it to:
.kpdf-preview-sticky-unit {
position: static;
}
At the same time, mobile enables:
#kpdf-mobile-escape
Therefore mobile currently has:
CART:
fixed Human navigation furniture
Preview:
ordinary static-flow furniture
The CART itself does not create Preview follow behavior.
==================================================
7. PROVEN FAILURE CAUSE
==================================================
Classification:
B — HISTORICAL PLACEMENT MISMATCH
The failure is NOT:
– dead selector
– missing anchor
– dead click handler
– broken kpdfJumpTo()
– broken window.scrollTo()
– missing CART button
All of those paths remain operational.
The broken assumption is historical:
> Moving Human to the Workbench boundary is sufficient to provide the
> intended Preview transport/follow experience.
That assumption no longer matches the current UI organization.
==================================================
8. HISTORICAL REASON
==================================================
The Human UI was reorganized over time.
Development history records a later arrangement in which:
Preparation / Function & Material Area
was placed above:
Collage / Composition Area
while the existing Preview / Workbench composition machinery remained
below.
The CART navigation machinery, however, continued to operate through the
older:
workbench-top
/
after-workbench
boundary-anchor model.
Therefore the CART remained technically operational while its historical
placement assumption became stale.
This is why the defect can appear misleading:
THE BUTTON WORKS.
THE ANCHOR WORKS.
THE SCROLL WORKS.
THE TARGET EXISTS.
But the resulting Human experience no longer provides the expected
Preview relationship.
==================================================
9. FIRST BROKEN BOUNDARY
==================================================
Current path:
Human presses ↑
↓
kpdfJumpTo(‘kpdf-workbench-top’)
↓
target anchor position is obtained
↓
window.scrollTo()
↓
Human reaches the Workbench boundary
↓
Preview remains in normal document flow on mobile
↓
no continuing Preview follow relationship exists
Therefore the first evidence-backed broken boundary is:
> CART still transports Human according to the historical Workbench-boundary
> placement model, while the current mobile Preview no longer follows the
> viewport from that relationship.
Trace ended at this boundary.
==================================================
10. PRODUCT AUTHORITY INVOLVEMENT
==================================================
NONE FOUND.
CART affects:
PAGE / VIEWPORT SCROLL
→ YES
CART does not affect:
Paper geometry
→ NO
Paper orientation
→ NO
Text x/y
→ NO
Image x/y
→ NO
rotation
→ NO
persistence
→ NO
saved product state
→ NO
Therefore CART belongs to:
HUMAN UI TRANSPORT / VIEWPORT FURNITURE
not:
PRODUCT GEOMETRY AUTHORITY.
==================================================
11. DEV187 RELATIONSHIP
==================================================
No functional intersection was found with the DEV187 outside-mask operation
frame work.
DEV187 operation-frame machinery remains under the paper/stage structure.
CART remains page-scroll / Workbench navigation furniture.
Therefore future CART work should preserve DEV187 without needing to modify:
– outside-mask operation frame
– outside-mask hit area
– operation buttons
– actual Text mask behavior
– MOVE
– rotation
==================================================
12. WHY REPAIR IS DEFERRED
==================================================
The Kaia PDF FREE UI is still undergoing finishing and furniture-placement
changes.
Therefore the final useful location/relationship among:
– Parts Factory
– Workbench
– Preview
– Composition area
– lower Presentation controls
– other Human furniture
may still change.
Repairing CART now against a temporary placement risks encoding another
location-dependent assumption.
In short:
OLD PROBLEM:
CART remembered an old station.
AVOID:
teaching CART the address of another station before the new station has
finished moving.
Therefore:
CURRENT REPAIR
= DEFERRED.
==================================================
13. FUTURE REPAIR PRINCIPLE
==================================================
When UI placement becomes stable, reopen this item from the then-current
known-PASS baseline.
Do NOT automatically restore the historical implementation.
First determine the Human behavior desired in the final UI.
The future solution should preferably remain entirely within:
HUMAN UI TRANSPORT / VIEWPORT PRESENTATION.
Avoid coupling CART to:
– product coordinates
– Paper geometry
– Text/Image coordinates
– persistence
– renderer
– FINAL
==================================================
14. FUTURE HUMAN DECISION REQUIRED
==================================================
Before final repair, Human should define what “Preview follow” means in the
finished UI.
Possible behaviors must NOT be selected merely from historical code.
For example, final Human intent could involve:
– one-action navigation that brings the current Preview into the useful
viewport position;
or
– a continuing/sticky Preview relationship while Human moves through the
relevant work area;
or
– another simple transport behavior appropriate to the final UI.
These are examples only.
They are NOT accepted product decisions.
Final Human behavior must be established after UI placement stabilizes.
==================================================
15. FUTURE TECHNICAL PREFERENCE
==================================================
Once Human behavior is established, prefer the smallest boring solution.
Preferred characteristics:
– current-location aware
– derived from actual final DOM structure
– viewport-only
– no persistent state
– no second Preview authority
– no product geometry
– no unnecessary synchronization system
Avoid hard-coding historical placement assumptions when a simpler
relationship to the final Human furniture can be used.
==================================================
16. FUTURE REPAIR WARNING
==================================================
Do NOT assume:
“Change the anchor and done.”
Do NOT assume:
“Turn sticky back on and done.”
Either might eventually be correct, but neither has been established as the
desired final Human behavior.
The investigation proved the historical mismatch.
It did NOT choose the future Human interaction specification.
==================================================
17. FUTURE REOPEN CHECK
==================================================
When this archive is reopened:
1. Identify the then-current known-PASS baseline.
2. Confirm final/current UI placement.
3. Ask/confirm the intended Human CART ↔ Preview behavior.
4. Re-check the current CART path.
5. Prefer viewport-only repair.
6. Protect product geometry and persistence.
7. If the repair is local and obvious, construct narrowly.
8. If historical/new placement assumptions are still ambiguous, investigate
before construction.
==================================================
18. STOP CONDITIONS FOR FUTURE WORK
==================================================
STOP if future repair unexpectedly requires:
– Paper geometry changes
– Text/Image coordinate changes
– Preview product authority
– persistence
– second Preview state
– broad transform/coordinate synchronization
– DEV187 operation-frame redesign
– renderer/FINAL changes
– assumptions about an unstable UI location
Do not repair architectural uncertainty by adding synchronization machinery.
==================================================
19. CHECK LOG
==================================================
TARGET:
CART ↔ Preview follow relationship
BASELINE:
DEV187
METHOD:
Exact current SOURCE
+
DEVELOPMENT-HISTORY historical evidence
CART PATH:
↑ / ↓
→ kpdfJumpTo()
→ anchor.getBoundingClientRect()
→ window.scrollTo()
DESKTOP PREVIEW FOLLOW:
.kpdf-preview-sticky-unit
→ position: sticky
→ top: 48px
MOBILE PREVIEW FOLLOW:
.kpdf-preview-sticky-unit
→ position: static
FIRST BROKEN BOUNDARY:
CART still uses Workbench boundary transport while the current mobile
Preview no longer obtains follow behavior from that historical placement
relationship.
CLASSIFICATION:
B — HISTORICAL PLACEMENT MISMATCH
PRODUCT AUTHORITY:
NONE
DEV187 INTERSECTION:
NONE
CURRENT REPAIR:
DEFERRED
==================================================
20. ARCHIVE SHORT SUMMARY
==================================================
台車は壊れていない。
ボタンも生きている。
anchorも生きている。
scrollも生きている。
壊れているのは：
「Workbench駅までHumanを運べばPreview transportとして成立する」
という昔の配置前提。
UI再編後も台車だけ昔の駅を覚えていた。
現在UIはまだ変動する可能性があるため、
今の住所へ修理
→ またUI移転
→ また阿呆になる
を避ける。
よって今は施工しない。
最終UI配置が固まった後、
Humanが望むPreview follow behaviorを決定し、
その時点の現住所を基準に、
viewport-onlyの最小配線で修理する。
合言葉：
「台車は正常。
駅が引っ越した★」
STATUS:
ARCHIVED / DEFERRED
REFERENCE ONLY
NOT A CONSTRUCTION ORDER.
これなら後でUIが全部固まってから掘り返しても、**「何が壊れてたんだっけ？」→「壊れてねえ、駅が移転したんだｗ」**まで一発で復元できる🕊️🛒📦
しかも将来のKaiaがDEV187当時の配置をそのまま正解扱いして修理しないよう、対策そのものは未決定ってところも固定してある。
No comments yet.