PC-CLAIM-4: Foundry actor sync detects player-character-claiming addon, routes to PC sub-type#64
Merged
Merged
Conversation
…ter-claiming addon
- sync-manager.mjs: _fetchAddons() calls GET /addons after _detectSystem() and
before module init; exposes isPcClaimingEnabled() to all modules. Gracefully
degrades when the endpoint is not yet deployed.
- actor-sync.mjs:
• _resolveCharacterTypeId() resolves _pcSubtypeId in the same /entity-types
call when the addon is on, via exported _findPcSubtypeId() pure helper.
• _handleCreateActor() gates owner resolution on isPcClaimingEnabled() (addon
off → no auto-claim); routes player-owned actors to the PC sub-type via
exported _pickEntityTypeId() pure helper.
• _isCharacterEntity() refactored: ID-based check is now authoritative,
accepting both parent character type and PC sub-type; slug/name are fallbacks.
• onInitialSync() queries both character type and PC sub-type.
• hasPlayerOwnedPcs() added for dashboard hint.
- sync-dashboard.mjs + templates/sync-dashboard.hbs: one-line info hint
"Enable Player Character Claiming in Chronicle to sync player claims."
shown in the Characters tab when addon is off and player-owned PCs exist.
- tools/test-pc-claiming.mjs: 29 unit tests, all pass (445 total suite green).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019WVEMu2d2t2ZyqGsGDJnLv
keyxmakerx
added a commit
that referenced
this pull request
Jun 19, 2026
5 tasks
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
2 participants
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.
Why
Stages 2 & 3 (Chronicle-side, now merged) plumbed the
player-character-claimingaddon, theclaimableflag, and the GM/player UI for it — but the Foundry module still pushed every character actor to the generic character type with no owner, ignoring both the addon state and the "Player Characters" sub-type that Stage 2 created. This is Stage 4 of 4 of the staged Player Character Claiming feature.What's in here
1. Addon detection —
sync-manager.mjs_fetchAddons()runs after_detectSystem()and before any moduleinit(), callingGET /addonsand caching whetherplayer-character-claimingis enabled.isPcClaimingEnabled()exposes the result. Gracefully degrades when the endpoint isn't deployed (flag staysfalse).2. PC sub-type routing —
actor-sync.mjs_resolveCharacterTypeId()now also resolves_pcSubtypeIdin the same/entity-typescall when the addon is on — finds the direct child of_characterTypeIdwhose slug/name matches "player-characters" via the exported_findPcSubtypeId()pure helper._handleCreateActor()gates_resolveOwnerUserId()onisPcClaimingEnabled():ownerUserId = null(no auto-claim, parent character type used)_pickEntityTypeId(), includesowner_user_idin the POST_isCharacterEntity()refactored: ID-based check is now authoritative when IDs are resolved, accepting both parent type and PC sub-type; slug/name remain as fallbacks for minimal/pre-init payloads.onInitialSync()queries both_characterTypeIdand_pcSubtypeIdso existing actor links under either type are refreshed.hasPlayerOwnedPcs()added for the dashboard hint.3. Dashboard hint —
sync-dashboard.mjs+templates/sync-dashboard.hbs_buildCharacterData()returnspcClaimingHint: truewhen the addon is off AND at least one player-owned character actor exists. The Characters tab shows a single non-spammy info bar: "Enable Player Character Claiming in Chronicle to sync player claims." Visible only when the condition is true; never fires as a repeated notification.Verification
node -cclean on all 3 changed scriptsnode --test tools/test-pc-claiming.mjs: 29/29 (new, covers_findPcSubtypeId,_pickEntityTypeId,_isCharacterEntity,hasPlayerOwnedPcs,isPcClaimingEnabled,_fetchAddons)node --test tools/test-*.mjs: 445/445No conflicts with Chronicle PC-CLAIM-3 (#482)
PR #482 (now merged) was entirely server-side UI — owner display on the entity page, GM roster, per-type checkbox. It made no API shape changes to the endpoints this module calls (
GET /addons,POST /entities,GET /entity-types). Our branch is branched directly from the post-merge main.🤖 Generated with Claude Code
https://claude.ai/code/session_019WVEMu2d2t2ZyqGsGDJnLv
Generated by Claude Code