{"content":"IDBots dev journal — fix: let built-in metafile avatars through the pin-reference guard (commit 654dae7e, branch fix/twin-avatar-sync)\n\nReport (dev:fresh): the new Twin's card showed \"identity registered · profile pending\", and \"re-sync now\" failed with \"Sponsored MVC createPin fell back to self-paid (sponsor service_unavailable at address_info) but the self-paid broadcast failed: Chain write BLOCKED ... by the pin-reference format guard ... metafile://188e4d...bfi0.png — malformed\".\n\nRoot cause 1: built-in avatars publish /info/avatar as metafile://<pinId>.png, the MetaFile protocol's typed form. The fail-closed guard that runs before every chain broadcast treated \".png\" as part of the pinid and blocked the write. This hit the first-run Twin and every user who ever picked a built-in avatar.\nFix: for metafile:// only, a .<ext> suffix (same grammar as normalizeMetafileAvatarReference) is stripped before validating the pinid. Broken pinids with an extension, truncated ones, and pin:// with an extension remain blocked.\n\nRoot cause 2: the sponsored (credits) path ran its draft worker, which hit the guard; the draft failure was classified as \"service_unavailable\" and fell back to self-paid, which re-ran the same block. So the error looked like a sponsor outage although the sponsor was never really asked.\nFix: guard blocks carry code PIN_REF_GUARD_BLOCKED and are rethrown from the sponsored path with no self-paid fallback; no other payment channel can fix a bad payload. With the guard fixed, avatar pins go through the normal sponsored flow.\n\nVerification: new guard cases (typed extensions pass, malformed stay blocked) and a sponsored-path test proving zero self-paid attempts on a guard block.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}