Repository navigation
Conversation
… — the ask was pointing at the wrong three words THE ASK WAS POINTING AT THE WRONG THREE WORDS. This artifact planned to obtain the runtime values of [sp,#152], [sp,#208] and [sp,#232]. Disassembling ekf@0.10.0#estimate shows all three are the MULTIPLICAND of a `x 9.81`, in three copies of one shape: vldr s8,[sp,#<accum>] ; vldr s9,[sp,#<slot>] ; movw/movt ip=0x411CF5C3 vmov s10,ip ; vmul.f32 s11,s9,s10 ; vadd.f32 s9,s8,s11 ; str -> linmem so each is the gravity DIRECTION and the OTHER operand is an accumulator. Pairs, with the hand-read block at 0x24a4 as the extractor's positive control: ([sp,#200],[sp,#152])->+940 ([sp,#216],[sp,#232])->+936 ([sp,#192],[sp,#208])->+944. AND THE REPORTER'S PUBLISHED TICK-1 WORDS FIT ONE MECHANISM EXACTLY. If the three ACCUMULATORS read zero, only gravity survives: down becomes 0 + 1.0*9.81, integrated as 9.81*0.001, whose f32 bits are 0x3C20BA20 — BIT-IDENTICAL to the vel-d measured on Renode, QEMU and i.MX RT1176 alike. North/east become exact zeros, which is what was measured, while wasmtime's non-zero north/east come from that same accumulator. pos-d fits (g*dt)*dt/2 to 5 significant figures. Four of four published words, one cause. HYPOTHESIS THREE, RECORDED AS A FALSIFIABLE PREDICTION RATHER THAN A CAUSE. The first two were refuted, both claims about STATE; this is about the translational computation, which is where that refutation pointed, and it does not contradict the quaternion agreeing. Measured: the expression shape and the arithmetic fit. NOT measured: any runtime value. AN EMPTY POSITIVE CONTROL WAS THE FINDING, TWICE. (a) Searching the object for the constant as a 4-byte LE pattern returned zero — and so did the controls, 1.0 and 0.001. synth materializes f32 constants as movw/movt pairs and Thumb-2 scatters a 16-bit immediate across i:imm3:imm8, so the pattern never appears contiguously. Reconstructing pairs finds +9.81 at 5 sites, -9.81 at 2, controls at 34 and 18. (b) The pairing extractor first returned ZERO triples because its window began one instruction too late and saw one of the two vldrs; caught only because the block had been read by eye first as a control. DISCLOSED, not glossed: lowered with synth 0.82.0 while the reporter ran 0.77.0, and 0.82.0 is NOT byte-compared against 0.77.0 for this module. Partial stability evidence: all three inherited slot offsets reproduce here ([sp,#152] 82 sites, [sp,#208] 32, [sp,#232] 20). The correspondence therefore gives a version-robust instruction-pattern locator and marks addresses as orientation. Inputs verified against the committed SHA256SUMS before use. A first compile without the reporter's own flags was REFUSED with a diagnostic naming #1041, which is the refusal working. Rule 4 binds: no oracle was hardened in #1436's name. The reply is DRAFTED AND SURFACED for approval, not posted from this lane. Refs #1436 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
avrabe
force-pushed
the
lane/v0.83-jessdiverge5
branch
from
October 8, 2026 23:15
78a7e7f to
f95733e
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
avrabe
added a commit
that referenced
this pull request
Oct 9, 2026
…ll four lanes R4-lane and R15 both red on the unstamped branch, four failures from one cause: FIRSTTOKEN2 and SWEEP carried `landed: PENDING-PR-STAMP`, which names neither a PR nor an issue. R15 states the remedy itself — "Name BOTH the issue and the delivering PR" — and that is the arm taken here rather than flipping status, because a CLAIMING status would authorise closing #1476 and #1373. Read R4-lane's message as the disjunction it is. WIDEFILE6 and JESSDIVERGE5 are restamped too. Their `PR #1501` / `PR #1502` become FALSE the moment they land via a different PR, so this is a correction for accuracy and not a concession to consolidating them. Each `landed:` value was read in FULL before editing: the prose describes the FINDING, not the PR mechanics, so the leading number was the only stale token. Verified after the edit, not before it: status_evidence_check.py rc=0, 0 failures, printed count == printed list issue-scope: 0 issue(s) authorised for closure, 1 held by `outlives` all four still `status: proposed` with no `issue-scope:` — non-claiming closer-keyword scan over the new prose: zero adjacencies, control firing The print-order fix that makes the first line trustworthy arrived with #1500: this same tree printed 2 failures while counting 4 on the previous base. Refs #1476, Refs #1373, Refs #1439, Refs #1436 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
Contributor
Author
|
Superseded by #1503, which carries this commit unchanged — the artifact file is byte-identical to the one on this branch, verified after the rebase. Consolidated because each artifact-only lane as its own PR costs a full CI run plus a rebase and re-run after every preceding merge, and the The |
avrabe
added a commit
that referenced
this pull request
Oct 9, 2026
…nly lanes, four refutations, none claiming (#1503) * v0.83 FIRSTTOKEN2 (#1476): the widening is refused again, and this time because the hole it would close is EMPTY v0.82 refused three widenings by weighing a cost against a benefit. This re-measures the trade the refuting command asks about and finds the BENEFIT SIDE IS ZERO — a stronger refusal than v0.82's, not a repeat of it. THE HOLE HAS NO INSTANCES AT THIS TREE. `unclassified_lead` — the function that makes #1476's hole nameable — returns a token for ZERO artifacts. Its own docstring records the measured escapes as NOT LANDED, DONE, NOT-DELIVERED and CLOSED; none of the four is present any more. A DERIVED ZERO IS A REFUSAL AND NOT A PASS, so the detector was PAIRED-CONTROLLED before the zero was believed. POSITIVE 4/4: fed the four openings its docstring names, it returns each one. NEGATIVE 4/4: fed `PARTIAL,`, `DELIVERED,`, `THE MEASUREMENT` and `MEASURED`, it returns None for all four. SO THE TRADE IS 33 DROPPED TO CLOSE 0. Variant 3, stated precisely because the count depends on the statement: drop any artifact whose FIRST SENTENCE of verified-by contains a negator (NOT|NO|NEVER|WITHOUT|CANNOT|NEITHER|NOR). Over the checker's own population plus this release's five delivered artifacts, 33 of 85. No widening is justified by an empty hole. AND THE DROP COUNT MOVED, confirming the non-adoptability argument from a second direction. v0.82 measured 27 of 78 at afa59b5 and observed the count moving with the SENTENCE SCOPE; it also moves with the TREE. A population that changes with a parsing choice and with the commit is not a population. A FIRST ATTEMPT WAS WRONG IN THIS REPO'S RECORDED WAY. It reimplemented the lookup as "LEAD matched but the phrase is in no set" and reported THIRTEEN escapes. Every one was a false positive: LEAD prefers a TWO-WORD run and `unclassified_lead` falls back to the FIRST word, so `IMPLEMENTED PER` is correctly out of scope. The hand-rolled version measured the regex; the script's function measures the rule. Thirteen became zero with the right instrument. THIS RELEASE'S OWN FIVE DELIVERED ARTIFACTS WERE PUT THROUGH THE GATE — the check this lane could most easily have skipped. All five in population, zero red verdicts, zero escapes. One scare recorded: run from a branch cut off origin/main the same scan showed four of them `lead=None` and apparently OUT of population; the cause was the branch, not the artifacts — on main those files are still the PLAN versions with no verified-by at all. AND THE POPULATION FIGURE IS QUOTED FROM THE GATE'S OWN PRINTED LINE, not computed. A first write gave three hand-derived numbers and all three were unstable for reasons unrelated to the tree: 80 became 81 the moment this artifact gained its own verified-by, and 577 became 575 under a one-line change to my helper's type filter. The fix was to stop producing them and read the instrument's output. #1476 STAYS OPEN as the record of why no wider rule is adoptable. Refs #1476 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L * v0.83 SWEEP (#1373): the board CAN answer "is this still broken?" — and for the pinned set the answer is YES, which refutes verify-and-close as a strategy MAINTAINER-REQUESTED mid-release: reduce the open-issue count as far as evidence allows. The plan was a verify-and-close sweep over the 54 open issues. THAT PLAN IS REFUTED AS A STRATEGY, with numbers, and the refutation is the deliverable. THE PINS ANSWER THE QUESTION #1373 SAYS THE BOARD CANNOT. #1428 established that all six non-empty KNOWN*/PINNED* tables are exact in BOTH directions — they go RED when a pinned defect is FIXED. So a PASSING differential is positive evidence the defect is STILL LIVE. Re-measured against this release's binary: false_reject_1229_differential PASS — 130 false-rejections of valid WASM invalid_accept_1207_differential PASS — 38 wrongly-accepted invalid modules aarch64_operand_class_1231_diff PASS — 4 operand-class confusions ra003_join_1230_differential PASS — 3 remaining declines Closing any of those as "verified fixed" would be a FALSE closure of a CI-proven live defect — strictly worse than leaving the count where it is. #1447 RE-RUN AND REPRODUCING EXACTLY: (if (result T)) with no params and two constant arms gives i32 COMPILES, i64 COMPILES, f32 DECLINED, f64 DECLINED, with the diagnostic unchanged — including "function too complex" about a zero-parameter two-constant module. Stays open. The misleading clause is a cheap separate fix and is deliberately NOT done here: a diagnostic correction is not progress on the capability gap. #1085 VERIFIED CLOSEABLE, recorded rather than closed. R7 is labelled `# ---- R7 git archaeology (#1085)`, landed in b2abf95 whose first tag is v0.61.0, carries class R7EvidenceRelease whose docstring records that disabling R7 kills at least one test, and runs live at 84 archaeology checks / 0 skipped / 0 failures. Closure cites a TAGGED release, so it waits for v0.83.0. #1448 IS AN HONEST NON-RESULT. A hand-written approximation of its bisection DECLINED IN BOTH ARMS where the issue reports 1 compiling and 2 declining. That does not refute the issue and is not evidence about it — the module is mine, not the reporter's, and a disagreement between my approximation and a measured bisection means MY module is wrong. #1448 has no committed repro, which is exactly why it cannot be cheaply re-verified. THE UNPINNED REMAINDER carries each figure WITH ITS GLOB, because one moved while this was being written: 16 of 54 have a name-matched repro under scripts/repro/*; "named anywhere" is 30 over scripts/repro/* + crates/*/tests/*.rs + crates/*/src/*.rs, and a first pass over a wider recursive set gave 29. The population is a property of the glob, not of the board. The directional claim is unaffected. AND AN INSTRUMENT USED FOR THIS TRIAGE WAS TOO CRUDE TO TRUST, recorded so it is not re-used: a census mapping each issue to "the first tag containing the newest commit mentioning it" dated #1085 to v0.64.0, where the IMPLEMENTING commit gives v0.61.0. The newest mention is not the fix. Refs #1373 Refs #1428 Refs #1085 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L * v0.83 WIDEFILE6 (#1439): the newly-accepted function disassembled — no VABS is emitted, and sign cannot come from reassociation THE RETRY WAS APPLIED LOCALLY AND THE RUNG LANDS. v0.78's pool-grow retry for stage 3, mirroring stage 2, re-applied on a scratch tree (NEVER committed; restored byte-identically, diff -q IDENTICAL, tripwire green again at 10/10). The 60-local right-leaning shape compiles — 1956 bytes — and wide60_declines_and_the_ladder_dies_on_the_wide_file_rung_1426 FIRED exactly as built: "IF THIS FIRED, THE RUNG LANDED". AND THE DIFFERENTIAL NAMED AS THIS DEFECT'S ORACLE NEVER RUNS THE SHAPE. With the retry applied it reports "PASS: 70 emulations bit-identical to wasmtime". That PASS is TRUE ABOUT THE WRONG SUBJECT: F32_EXPORTS is ["live13","live14","live16","live24"], tops out at 24 locals, folds LEFT, and every entry compiles on an EARLIER rung — live24 on vfp-frame-locals+pool-grow, bit-exact since v0.78. The newly-accepted function is in no export list. The tripwire's own message predicted this: "a compile-only green here says nothing about the bytes". THE ABS HYPOTHESIS IS REFUTED BY THE EMITTED CODE, not only by encoding reachability. Over the function's 1956 bytes, sliding by a HALFWORD rather than assuming alignment: ZERO VABS.F32, ZERO VMOV.F32 reg-reg, ZERO VNEG.F32. POSITIVE CONTROL, which is why the zero means anything: the same scanner finds VABS.F32 twice in a 74-byte abs/copysign module. AND SIGN CANNOT COME FROM REASSOCIATION — proven, not assumed. sign(a*b) is the XOR of the signs and XOR is commutative, so a product's sign is invariant under any reordering; overflow destroys magnitude associativity and leaves sign alone. Measured in f32 with infinity saturation over the exact 60-factor chain, forward vs fully reversed, params +/-0.5/1/2/3: got ^ want == 0 every time. It also explains the signature — the chain OVERFLOWS after ~25 factors, and two infinities of opposite sign differ in exactly the sign bit with bit-identical magnitudes, which is v0.78's observation verbatim. THE MULTIPLY MULTISET IS INTACT: VMUL.F32 appears 119 times against 119 f32.mul in the source, so none is dropped or duplicated. (Spill-traffic counts were taken and are NOT quoted: those masks returned nothing on the control, so they are UNPROVEN.) SURVIVING CLASS, now the only one in this family: a WRONG OPERAND — a spill/reload reading the wrong frame slot — which substitutes a value without changing the instruction count or the sign algebra. Last on v0.81's candidate list, never tested, now the sole survivor. BOTH REFUTING COMMANDS REFUTED THEIR OWN EXPECTATIONS, and one was malformed in this release's exact shape. `git log -S"pool grow retry" | wc -l` expected 0 and returns 5 — and -S is a PICKAXE, matching every commit where the count CHANGED, so it cannot speak about HEAD. Worse, all five commits are the artifact commits themselves: the phrase lives ONLY in release-v0.81/-v0.82/-v0.83 YAML prose and zero times in code, so the instrument was counting the commits that wrote the artifacts carrying it. Replaced with `git grep` at HEAD, which says 0 — the claim was true, the command could not establish it. And the emitter count is 4 not 3 under `-- crates/`, because a test asserts the constant; the pathspec is part of the command, and `crates/*/src/*` gives 3 while `:(glob)crates/*/src/**` gives 0 — a wrong pathspec looks exactly like a passing refutation. Encoder line numbers RE-DERIVED at this commit: 2012 (F32Abs A32), 6366 (F32Abs Thumb-2), 7354 — which is NOT an F32Abs emitter but sits inside encode_thumb_f32_copysign. The v0.81 figures 1992/6322/7310 had all moved. Fixture denominator re-measured because two records disagreed: 130 f32.mul (plus 15 f64.mul), zero abs/copysign/neg in both widths. A durable note carried 71 since v0.81; never true — the fixture has ONE commit (0ec9dc7, v0.60) and `git show <rev>:<path>` gives 130 at every revision. The cause is NOT named, so the retry STAYS OUT and the tripwire STAYS ARMED. Refs #1439 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L * v0.83 JESSDIVERGE5 (#1436): the gravity triple read out of the object — the ask was pointing at the wrong three words THE ASK WAS POINTING AT THE WRONG THREE WORDS. This artifact planned to obtain the runtime values of [sp,#152], [sp,#208] and [sp,#232]. Disassembling ekf@0.10.0#estimate shows all three are the MULTIPLICAND of a `x 9.81`, in three copies of one shape: vldr s8,[sp,#<accum>] ; vldr s9,[sp,#<slot>] ; movw/movt ip=0x411CF5C3 vmov s10,ip ; vmul.f32 s11,s9,s10 ; vadd.f32 s9,s8,s11 ; str -> linmem so each is the gravity DIRECTION and the OTHER operand is an accumulator. Pairs, with the hand-read block at 0x24a4 as the extractor's positive control: ([sp,#200],[sp,#152])->+940 ([sp,#216],[sp,#232])->+936 ([sp,#192],[sp,#208])->+944. AND THE REPORTER'S PUBLISHED TICK-1 WORDS FIT ONE MECHANISM EXACTLY. If the three ACCUMULATORS read zero, only gravity survives: down becomes 0 + 1.0*9.81, integrated as 9.81*0.001, whose f32 bits are 0x3C20BA20 — BIT-IDENTICAL to the vel-d measured on Renode, QEMU and i.MX RT1176 alike. North/east become exact zeros, which is what was measured, while wasmtime's non-zero north/east come from that same accumulator. pos-d fits (g*dt)*dt/2 to 5 significant figures. Four of four published words, one cause. HYPOTHESIS THREE, RECORDED AS A FALSIFIABLE PREDICTION RATHER THAN A CAUSE. The first two were refuted, both claims about STATE; this is about the translational computation, which is where that refutation pointed, and it does not contradict the quaternion agreeing. Measured: the expression shape and the arithmetic fit. NOT measured: any runtime value. AN EMPTY POSITIVE CONTROL WAS THE FINDING, TWICE. (a) Searching the object for the constant as a 4-byte LE pattern returned zero — and so did the controls, 1.0 and 0.001. synth materializes f32 constants as movw/movt pairs and Thumb-2 scatters a 16-bit immediate across i:imm3:imm8, so the pattern never appears contiguously. Reconstructing pairs finds +9.81 at 5 sites, -9.81 at 2, controls at 34 and 18. (b) The pairing extractor first returned ZERO triples because its window began one instruction too late and saw one of the two vldrs; caught only because the block had been read by eye first as a control. DISCLOSED, not glossed: lowered with synth 0.82.0 while the reporter ran 0.77.0, and 0.82.0 is NOT byte-compared against 0.77.0 for this module. Partial stability evidence: all three inherited slot offsets reproduce here ([sp,#152] 82 sites, [sp,#208] 32, [sp,#232] 20). The correspondence therefore gives a version-robust instruction-pattern locator and marks addresses as orientation. Inputs verified against the committed SHA256SUMS before use. A first compile without the reporter's own flags was REFUSED with a diagnostic naming #1041, which is the refusal working. Rule 4 binds: no oracle was hardened in #1436's name. The reply is DRAFTED AND SURFACED for approval, not posted from this lane. Refs #1436 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L * v0.83 artifacts2: stamp `landed:` with the delivering PR (#1503) on all four lanes R4-lane and R15 both red on the unstamped branch, four failures from one cause: FIRSTTOKEN2 and SWEEP carried `landed: PENDING-PR-STAMP`, which names neither a PR nor an issue. R15 states the remedy itself — "Name BOTH the issue and the delivering PR" — and that is the arm taken here rather than flipping status, because a CLAIMING status would authorise closing #1476 and #1373. Read R4-lane's message as the disjunction it is. WIDEFILE6 and JESSDIVERGE5 are restamped too. Their `PR #1501` / `PR #1502` become FALSE the moment they land via a different PR, so this is a correction for accuracy and not a concession to consolidating them. Each `landed:` value was read in FULL before editing: the prose describes the FINDING, not the PR mechanics, so the leading number was the only stale token. Verified after the edit, not before it: status_evidence_check.py rc=0, 0 failures, printed count == printed list issue-scope: 0 issue(s) authorised for closure, 1 held by `outlives` all four still `status: proposed` with no `issue-scope:` — non-claiming closer-keyword scan over the new prose: zero adjacencies, control firing The print-order fix that makes the first line trustworthy arrived with #1500: this same tree printed 2 failures while counting 4 on the previous base. Refs #1476, Refs #1373, Refs #1439, Refs #1436 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ask was pointing at the wrong three words
This artifact planned to obtain the runtime values of
[sp,#152],[sp,#208]and[sp,#232]. Disassemblingekf@0.10.0#estimateshows all three are the multiplicand of a× 9.81, in three copies of one shape:So each named slot is the gravity direction, and the other operand is an accumulator. The derived pairs, with the hand-read block at
0x24a4serving as the extractor's positive control:0x24a4[sp,#200][sp,#152]0x24d0[sp,#216][sp,#232]0x24fc[sp,#192][sp,#208]The discriminating operands are therefore the accumulators, and the ask becomes six words with a predicted value each, not three.
One mechanism fits four of four published words
If the three accumulators read zero, only the gravity term survives:
vel-df32(9.81 × 0.001)=0x3C20BA200x3C20BA20— bit-identicalvel-n0 + 0.0×9.81=00vel-e0 + 0.0×9.81=00pos-d(g·dt)·dt/2=4.9050007e-064.9050004e-06wasmtime's non-zero north/east come from that same accumulator, and its
vel-dis0because the accumulator's−9.81cancels the gravity term.Recorded as a falsifiable prediction, not a cause
The mechanism on this thread has been wrong twice — "an identity rotation" (refuted by the reporter's tick-16 numbers) and "a lagged attitude read" (refuted by the reporter's own TCG tracer showing the quaternion bit-identical at every tick). Both were claims about state; this one is about the translational computation, which is where that refutation pointed, and it does not contradict the quaternion agreeing.
Measured: the expression shape, and the arithmetic fit. Not measured: any runtime value. So the correspondence states a predicted value per slot and the conditions that refute it.
An empty positive control was the finding, twice
1.0(62 occurrences in the wasm) and0.001(22). The search was structurally incapable: synth materialises f32 constants asmovw/movtpairs, and Thumb-2 scatters a 16-bit immediate acrossi:imm3:imm8, so the pattern never appears contiguously. Reconstructing the pairs finds+9.81at 5 sites and−9.81at 2, with controls at 34 and 18 — non-zero, so potent.vldrs. Caught only because the block had been read by eye first, which served as the control.Disclosed, not glossed
Lowered with synth 0.82.0 while the reporter ran 0.77.0, and 0.82.0 has not been byte-compared against 0.77.0 for this module — the durable record establishes 0.79.0 ≡ 0.77.0 and says nothing about 0.82.0. Partial stability evidence: all three inherited slot offsets reproduce here (
[sp,#152]82 sites,[sp,#208]32,[sp,#232]20). The correspondence therefore supplies a version-robust instruction-pattern locator and marks addresses as orientation only.Both inputs were verified against the committed
SHA256SUMS.txtbefore use. A first compile without the reporter's own recorded flags was refused by synth with a diagnostic naming #1041 (13 active data segments, no__synth_wasm_datareference) — the refusal working.Conduct
#1436 is externally reported and still open, so rule 4 binds and no oracle was hardened in its name. The reply leads with what changed for them, states the prediction and what refutes it, and offers detail rather than pasting it. It was drafted and surfaced to the maintainer for approval, not posted from this lane.
Refs #1436
🤖 Generated with Claude Code
https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L