Files
SoulStream/handoff/rounds/ins-r47-ground-vector.txt
T
KeelrLeek 9f0601027c android: the handoff — the pending rounds, the pipeline, and what is unverified
Everything written this session that has not been through the device: rounds 43
to 48 (each patch adversarially verified, 43's transient-notice expectation
fixed), a partial round 49, the pipeline scripts, the Android Auto design and
the icon comparison mock. Also the two harness changes that were never A/B'd —
adaptive waits, which may only shorten a declared wait and never lengthen it,
and a ship that runs the mock walk and the deploy at the same time. The A/B and
its 255-step baseline are in handoff/tools; main stays at what the phone has
actually walked.
2026-09-14 07:57:41 -05:00

77 lines
3.6 KiB
Plaintext

<?xml version="1.0" encoding="utf-8"?>
<!-- The adaptive background: concept 04's ground, not a flat colour.
The desktop ships concept 04 "Deep navy glow" (src-tauri/icons/icon.svg,
byte-identical to the kit's soulstream-04-deep-navy-glow.svg) and the
phone shipped #05080B under the same falcon. The falcon covers about a
quarter of a circle-masked tile, so the ground is three quarters of what
anyone sees; the glow survives every mask, lifting the visible top-left
corner from #05080B to #0E3543; and a phone wearing a flatter icon than
the desktop is a divergence for no gain.
LAYER-FIT, not mask-fit: the 1024 artwork is mapped onto the whole 108
layer, not onto the 72 window inside it. Under a circle or a squircle the
two are indistinguishable, and this one never shows a flat edge when a
launcher parallaxes the layers apart.
Every number below is the kit's, multiplied by 108/1024 and nothing else:
surface <linearGradient x1=130 y1=50 x2=880 y2=980>
glow <radialGradient gradientTransform=
"translate(270 220) rotate(43) scale(660)">
108/1024 is 27/256, so each of those terminates inside eight decimals and
is an exact float — nothing here is a rounded coordinate.
The glow's transform has a UNIFORM scale, so the ellipse is a circle and
the rotate is a no-op — which is the whole reason a VectorDrawable can
carry this at all: android:type="radial" is centre plus radius, circular,
with no transform of its own. Had that scale been two numbers, no vector
could have expressed it and this would be five PNGs. stop-opacity folds
into the 8-bit alpha of android:color (0.18 -> 2E, 0.05 -> 0D, 0 -> 00);
the worst error that introduces, measured against the SVG's own float
composite at the layer corners, the visible corners, the circle's rim and
the centre, is one level of 255.
The rx="232" on the kit's two rects is deliberately NOT here. That is the
desktop window's corner; on the phone the launcher's mask does that job,
and an adaptive background must fill its layer.
Two full-bleed paths, surface then glow, because an adaptive background
must be opaque: the first is #FF everywhere and the second only lightens
it. -->
<vector xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:aapt="http://schemas.android.com/aapt"
android:width="108dp"
android:height="108dp"
android:viewportWidth="108"
android:viewportHeight="108">
<path android:pathData="M0,0h108v108h-108z">
<aapt:attr name="android:fillColor">
<gradient
android:type="linear"
android:startX="13.7109375"
android:startY="5.2734375"
android:endX="92.8125"
android:endY="103.359375">
<item android:offset="0" android:color="#FF0A2330" />
<item android:offset="0.52" android:color="#FF07141F" />
<item android:offset="1" android:color="#FF040A10" />
</gradient>
</aapt:attr>
</path>
<path android:pathData="M0,0h108v108h-108z">
<aapt:attr name="android:fillColor">
<gradient
android:type="radial"
android:centerX="28.4765625"
android:centerY="23.203125"
android:gradientRadius="69.609375">
<item android:offset="0" android:color="#2E31C0CB" />
<item android:offset="0.58" android:color="#0D1F8FC9" />
<item android:offset="1" android:color="#0007141F" />
</gradient>
</aapt:attr>
</path>
</vector>