docs: §12.3.1 SHIPPED + §12.3.2 → Issue #174 (per-token spent-state rescan)#175
Open
vrogojin wants to merge 1 commit into
Open
docs: §12.3.1 SHIPPED + §12.3.2 → Issue #174 (per-token spent-state rescan)#175vrogojin wants to merge 1 commit into
vrogojin wants to merge 1 commit into
Conversation
…escan) The transfer protocol doc had `§12.3 Periodic rescans` framed as "two rescans deferred as a unit" at T.1–T.8 plan-time. That framing is stale: the aggregator-pointer wave + Item #15 shipped §12.3.1 (profile-pointer rescan) outside T.1–T.8's bucket. Only §12.3.2 (per-token spent-state rescan) remains genuinely open. Updates to `UXF-TRANSFER-PROTOCOL.md §12.3`: - Banner status block flipping §12.3.1 to SHIPPED and §12.3.2 to Issue #174. - §12.3.1 body rewritten to describe the AS-IMPLEMENTED mechanism (randomized [30s, 90s) interval, `pointer.recoverLatest()`, `applySnapshotIfWired` dispatch via Item #15's host method, pubsub hint-channel via `triggerPointerPollNow()`, 5× permanent-failure back-off, cold-start path via `recoverFromAggregatorPointerBestEffort`). Operator override: omitting `getPointerLayer` IS the off-switch — no separate `disableProfilePointerRescan` flag (the spec text was aspirational on that point). - §12.3.2 body flagged with the Issue #174 status banner; reactive vs proactive surface contrast explained (Item #14 Phase 1 is the reactive piece; §12.3.2 is the proactive piece). Event name aligned to the project's `transfer:*` convention (`token:off-record-spent` → `transfer:off-record-spent`). Updates to `UXF-TRANSFER-IMPL-PLAN.md` "Out-of-scope for T.1–T.8": - Same status banner: §12.3.1 SHIPPED outside the T.1–T.8 bucket (landed via the separate aggregator-pointer wave); §12.3.2 STILL OPEN per Issue #174. Original "deferred as a unit" wording preserved as historical record of T.1–T.8 scope. Updates to `OUTBOX-SEND-FOLLOWUPS.md`: - New Item #16 row covering the §12.3.2 acceptance criteria, relationship to Items #14 / #15, file inventory, complexity, blast radius. Links back to Issue #174 as the canonical tracker. No code changes — pure documentation refresh after the architectural shift Item #15 delivered.
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.
Summary
Documentation refresh after the architectural shift Item #15 delivered.
The transfer protocol doc had `§12.3 Periodic rescans` framed as "two rescans deferred as a unit" at T.1–T.8 plan-time. That framing is stale:
PROFILE-AGGREGATOR-POINTER-IMPL-PLAN.mdPhases A–E, 75 tasks) and consolidated by Item [Sphere SDK] Add groupchat support #15 (PR Item #15 full-profile-snapshot sync + B.4 + Item #2/#6/#14 Phase 1 (#166) #173). Implementation:profile/profile-token-storage/lifecycle-manager.ts:schedulePointerPoll/runPointerPollOnce, randomized [30s, 90s) interval.Changes
Caught by
A user question after PR #173 landed: "we do not have periodic polling for the profile pointer update from the unicity aggregator???" — I had carelessly described `§12.3 periodic rescans (DEFERRED as a unit)` in a status summary, conflating §12.3.1 (shipped) with §12.3.2 (open). This PR fixes the doc drift that misled me.
Test plan
Documentation only — no code changes. Verified the §12.3.1 description matches the actual code in `lifecycle-manager.ts` (interval bounds, mechanism, hint-channel wiring, back-off semantics, cold-start path).
Refs