erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: #345 mechanism caught — ValidateWalkable's below-push Adjusts every attempt but the adjustment never carries forward

Browse source 
The trace shows 275 uniform player stuck ticks: target 0.268m below a
just-too-steep plane (N.z=0.599 vs FloorZ 0.664), below-push Adjusted
on every transition attempt with the IDENTICAL dist each time — the
adjust is recomputed from scratch instead of feeding the next attempt,
attempts exhaust, the tick yields zero. The fix contract's question is
now a single retail cross-read: does transitional_insert feed the
adjusted CheckPos forward, or branch differently on Adjusted-with-
non-walkable. The probe paid for itself in one one-minute run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-07 10:53:24 +02:00
parent e761761aa3
commit 2098fa6690
1 changed files with 21 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

24
docs/ISSUES.md
View file

@ -166,9 +166,27 @@ morning: PRE-EXISTING, not a campaign regression.** The pre-campaign binary
protocol) shows the identical signature — eleven consecutive 2-second windows
of sustained ~30 m requested with 0.0% yield (`uphill-AB-precampaign.jsonl`).
Campaign S is exonerated wholesale; the defect is older and was simply never
noticed before the user's slope attention this week. Suspect space unchanged
(the UP-normal zero-displacement step-down-refusal shape leads); theory work
remains forbidden until the mechanism session instruments it.
noticed before the user's slope attention this week. **MECHANISM CAUGHT 2026-08-08 (`345-mechanism.log`, ACDREAM_DUMP_TRANSIT_FAIL):**
275 uniform player stuck ticks. Per tick: the run step's target puts the
sphere's foot point **0.268 m BELOW a too-steep plane** (`N=(0.799,0.050,0.599)`,
N.z just under FloorZ 0.664); `ValidateWalkable`'s below branch returns
**Adjusted** (push-up) on EVERY transition attempt — and every attempt reports
the IDENTICAL `dist=-0.26801`: **the adjustment does not carry forward between
attempts.** env/building/objects phases all OK each attempt; ~6 attempts per
tick; attempts exhaust; the transition fails and restores the original
position. Zero yield. (`oiContact=True, spStepDown=False, guardPassed=False`
on every line — the morning's `collN=(0,0,1)` comes from the failure path's
result-filling, not from ValidateWalkable's guard, which never passes here.)
**The fix contract's question is now precise:** what does RETAIL's
transitional_insert do with validate_walkable's Adjusted on a non-walkable
plane — does the adjusted CheckPos feed the NEXT attempt (convergence), or
does retail take a different branch entirely (slide/collision) instead of
re-adjusting from scratch? Grep-named-first targets:
`OBJECTINFO::validate_walkable`'s callers, `CTransition::transitional_insert`'s
attempt loop and its use of the adjusted check position, and the
`walk_interp` bookkeeping. The non-carry between attempts is the defect
candidate; do not touch the #331/#32/AD-65 machinery.
**Filed:** 2026-08-08 morning, from the user's report ("I stop instead of
sliding") + a directed 45-degree capture.