[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-81231":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":8,"htmlUrl":8,"language":9,"languages":8,"totalLinesOfCode":8,"stars":10,"forks":11,"watchers":12,"openIssues":11,"contributorsCount":11,"subscribersCount":11,"size":11,"stars1d":11,"stars7d":13,"stars30d":14,"stars90d":11,"forks30d":11,"starsTrendScore":11,"compositeScore":15,"rankGlobal":8,"rankLanguage":8,"license":16,"archived":17,"fork":17,"defaultBranch":18,"hasWiki":19,"hasPages":17,"topics":20,"createdAt":8,"pushedAt":8,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":11,"starSnapshotCount":11,"syncStatus":24,"lastSyncTime":25,"discoverSource":26},81231,"Discord-Permission-Engine","ItzXynx\u002FDiscord-Permission-Engine","ItzXynx",null,"JavaScript",30,0,23,3,7,39.2,"MIT License",false,"main",true,[],"2026-06-12 04:01:32","# Discord Permission Engine\n\nA faithful, minimal implementation of Discord's permission resolution algorithm — built with pure functions, BigInt bitmasks, and zero dependencies.\n\n---\n\n## Why\n\nDiscord's permission system looks simple on the surface (it's just bitwise math) but its real behaviour depends on a strict resolution order across roles, `@everyone`, role overwrites, and member-specific overwrites. Getting that order wrong is the most common source of permission bugs in bots and self-hosted tools.\n\nThis library implements the algorithm exactly as Discord documents it, in roughly 100 lines of core logic.\n\n---\n\n## How the algorithm works\n\nPermissions are resolved in this exact order:\n\n1. **Base permissions** — `OR` together every role the member has, including `@everyone`.\n2. **Administrator short-circuit** — if the `ADMINISTRATOR` flag is set, return all permissions immediately. No overwrite can revoke it.\n3. **`@everyone` channel overwrite** — apply `(perms & ~deny) | allow`.\n4. **Role overwrites** — accumulate `allow` and `deny` across every role overwrite that matches one of the member's roles, then apply `(perms & ~deny) | allow` once.\n5. **Member overwrite** — apply the member-specific overwrite last. This always wins.\n\nThe core formula at every overwrite step is:\n\n```\npermissions = (permissions & ~deny) | allow\n```\n\n---\n\n## Install\n\n```bash\ngit clone \u003Cthis-repo>\ncd discord-permission-engine\nnpm install\n```\n\nNo dependencies are required.\n\n---\n\n## Library usage\n\n```js\nconst { resolve, PERMISSIONS } = require('.\u002Fsrc\u002Fresolver');\n\nconst result = resolve({\n  member: { id: 'user_1', guildId: 'guild_1', roles: ['mods'] },\n  roles: [\n    { id: 'guild_1', name: '@everyone', permissions: '1024' },\n    { id: 'mods',    name: 'Moderators', permissions: '8192' }\n  ],\n  channel: {\n    overwrites: {\n      everyone: { allow: '0', deny: '2048' },\n      members:  [{ id: 'user_1', allow: '0', deny: '8192' }]\n    }\n  }\n});\n\nresult.has('VIEW_CHANNEL');     \u002F\u002F true\nresult.has('SEND_MESSAGES');    \u002F\u002F false  (denied by @everyone overwrite)\nresult.has('MANAGE_MESSAGES');  \u002F\u002F false  (denied by member overwrite)\nresult.permissions;             \u002F\u002F ['VIEW_CHANNEL']\nresult.bitmaskString;           \u002F\u002F '1024'\n```\n\n---\n\n## CLI usage\n\n```bash\nnode cli.js examples\u002Fbasic.json\n```\n\nOutput:\n\n```\nCREATE_INSTANT_INVITE  ❌\nKICK_MEMBERS           ❌\n...\nVIEW_CHANNEL           ✅\nSEND_MESSAGES          ✅\nMANAGE_MESSAGES        ❌\n...\n```\n\nFilter to just the flags you care about:\n\n```bash\nnode cli.js examples\u002Fconflict.json --filter VIEW_CHANNEL,SEND_MESSAGES,MANAGE_MESSAGES\n```\n\n```\nVIEW_CHANNEL     ✅\nSEND_MESSAGES    ❌\nMANAGE_MESSAGES  ❌\n```\n\nJSON output:\n\n```bash\nnode cli.js examples\u002Fbasic.json --json\n```\n\n---\n\n## Input shape\n\n```jsonc\n{\n  \"member\": {\n    \"id\": \"user_1\",\n    \"guildId\": \"guild_1\",\n    \"roles\": [\"role_a\", \"role_b\"]\n  },\n  \"roles\": [\n    { \"id\": \"guild_1\", \"name\": \"@everyone\", \"permissions\": \"1024\" },\n    { \"id\": \"role_a\",  \"permissions\": \"2048\" }\n  ],\n  \"channel\": {\n    \"overwrites\": {\n      \"everyone\": { \"allow\": \"0\", \"deny\": \"0\" },\n      \"roles\":    [{ \"id\": \"role_a\", \"allow\": \"0\", \"deny\": \"0\" }],\n      \"members\":  [{ \"id\": \"user_1\", \"allow\": \"0\", \"deny\": \"0\" }]\n    }\n  }\n}\n```\n\nPermission values are strings to safely round-trip through JSON without losing precision (Discord uses 53+ bit values). Internally everything is `BigInt`.\n\n---\n\n## Edge case worth knowing\n\nIn `examples\u002Fconflict.json`, the user has the `Moderators` role, which is granted `MANAGE_MESSAGES` both at the guild level and via a role overwrite. Yet the final resolution returns `MANAGE_MESSAGES = false`.\n\nWhy? Because the **member-specific overwrite is always applied last**, after all role overwrites have been merged. A single member overwrite can revoke a permission that every one of the user's roles grants. This is the rule that trips most people up — and it's the exact behaviour Discord's client and API enforce.\n\nThe only thing that bypasses this is `ADMINISTRATOR`, which short-circuits the entire pipeline.\n\n---\n\n## Tests\n\n```bash\nnpm test\n```\n\nCovers base merging, admin override, conflicting role overwrites, member-overwrite priority, and the no-channel path.\n\n---\n\n## Project layout\n\n```\nsrc\u002F\n  flags.js        permission constants (BigInt bit shifts)\n  engine.js       pure resolution logic\n  formatter.js    bitmask → readable output\n  resolver.js     public API\ncli.js            CLI entry\nexamples\u002F         sample inputs\ntests\u002F            node:test suite\n```\n\n---\n\n## License\n\nMIT\n# Discord-Permission-Engine\n","这个项目是一个用于解析Discord权限系统的库，实现了与官方文档一致的权限解析算法。它使用纯函数、BigInt位掩码技术，并且不依赖任何外部库，在大约100行核心代码中完成了整个实现。该库严格按照Discord定义的角色、`@everyone`、角色覆盖和成员特定覆盖的顺序来计算最终权限值，确保了在复杂场景下的准确性。适用于需要精确处理Discord权限逻辑的各种应用开发，如构建自托管工具或机器人时避免常见的权限错误问题。",2,"2026-06-11 04:03:59","CREATED_QUERY"]