@phis/contracts 0.2.0

package/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "{}"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 Phisys Ltd
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/NOTICE

@@ -0,0 +1,4 @@
+@phis/addon-contract
+Copyright 2026 Phisys Ltd
+
+This product includes software developed by Phisys Ltd.

package/README.md

@@ -0,0 +1,102 @@
+# @phis/contracts
+
+The agreements phi-server keeps with what surrounds it. Two of them, under two subpaths, because
+they hold between different parties and freeze at different moments.
+
+```
+@phis/contracts/addon     what phi-server and a separately shipped Add-on promise each other
+@phis/contracts/access    the authorization vocabulary phi-server and @phis/ui both evaluate
+@phis/contracts/signals   the signal vocabulary the UI declares against and phi-server validates
+```
+
+There is deliberately no root export. A package you can import from the top invites everything that
+two of our packages happen to share; a subpath makes you say which agreement you mean.
+
+## `/addon`
+
+The types and constants a phi-server Add-on declares or implements. Types and constants only — no
+runtime code, no `server-only`, no React, no Next.
+
+An Add-on is compiled to a single ESM artifact and installed into a running phi-server through the
+`phis` CLI. It is never built into the server. This subpath is the only thing an Add-on compiles
+against; it must not depend on phi-server itself.
+
+```sh
+npm install --save-dev @phis/contracts
+```
+
+For an Add-on author it is a build-time dependency: everything `/addon` exports is erased at compile
+time, apart from a handful of constants.
+
+## `/access`
+
+Claim shapes, policy shapes, and the evaluator that decides them. Unlike `/addon`, this one **is**
+runtime code, and it is a real dependency of both packages that use it.
+
+Two processes decide the same question. phi-server decides it in its guards and API routes; the site
+decides it while rendering — per navigation entry, per tree node, and in the browser, where
+phi-server is not reachable without a round trip. Neither can defer to the other, so both evaluate,
+and one compiled source is the only way both can agree.
+
+They did not agree before this subpath existed. A stored claim with `flags: -1` admitted everything
+on the server and nothing in the UI: one side normalised the value, the other did not. Neither copy
+looked wrong on its own, which is why it went unnoticed.
+
+Each side keeps its own viewer type and passes a projection onto `PhiAccessSubject`, so neither
+package has to adopt the other's shape.
+
+## `/signals`
+
+The closed vocabularies a widget's wiring is written in -- scopes, actions, value types -- and the shape
+of a value schema name.
+
+A widget declares what it emits and listens for, the Builder stores that, and phi-server validates it on
+the way in. Two lists, one meaning; and when they were two lists they drifted. `@phis/ui` had grown
+`date`, `time` and `length`; phi-server had not. A length control's change signal -- from a widget the
+same release shipped -- was refused on save with "valueType is invalid".
+
+Which schemas exist stays with the UI. phi-server checks that a JSON signal names *a* schema, never
+which one, and `isPhiSignalValueSchemaShape` is exactly that much: shape, not membership. The UI asks
+the stricter question, because it holds the module registry; phi-server must not, or it would refuse
+every third party's schema for never having heard of it.
+
+## What `/addon` covers
+
+- **Manifest** — `PhiServerAddonManifestV1`: identity, version, required core capabilities,
+  the routes an Add-on claims, the services it provides.
+- **Runtime** — `PhiServerAddonRuntimeV1`, `PhiServerAddonHandler`,
+  `PhiServerAddonRequestContext`: the shape the artifact's default export must have.
+- **Schema** — `PhiServerAddonSchemaDescriptor` and its column, index, and constraint
+  descriptors. Tables are declared, not migrated by hand; phi-server applies them.
+- **Service kinds** — the interfaces an Add-on may provide or consume, currently the media
+  storage adapter (`PhisMediaStorageAdapter`, upload plans, object I/O).
+- **What Core offers** — `PHI_SERVER_CORE_CAPABILITIES`, the capability ids an Add-on may
+  require; `PHI_SERVER_SERVICE_KINDS`, the service kinds Core owns; and
+  `PHI_SERVER_SERVICE_INTERFACE_DIGESTS`, the digest of each kind's current interface. Declare
+  against these names rather than spelling them out: Core refuses an Add-on whose digest is not
+  the one this release offers, and a literal cannot be checked before you ship it.
+
+This list is a promise, not a plan. A capability appears here when Core delivers it, never
+before.
+
+`PHI_SERVER_ADDON_ABI_VERSION` is the single number a server checks an Add-on against.
+
+## Admission rule
+
+Per subpath, and both halves are narrow on purpose.
+
+Into `/addon`: only what **phi-server and a separately shipped Add-on must agree on**. Declarations,
+never implementations.
+
+Into `/access`: only what **phi-server and `@phis/ui` must both evaluate**, because each decides it
+in its own process. Not what both happen to use — a date formatter used on both sides is shared
+convenience, not a contract, and belongs to neither.
+
+The test for either is the same: name the two parties and the sentence they are promising each
+other. If that sentence cannot be written down, it does not go in here.
+
+## Documentation
+
+The full walkthrough — how an Add-on is laid out, compiled, installed, activated, and
+upgraded — lives in phi-server's `ADDON_HOWTO.md`, with the design rationale in
+`SERVER_ADDONS.md`.

package/dist/access.d.ts

@@ -0,0 +1,115 @@
+/**
+ * The authorization vocabulary phi-server and the site UI share.
+ *
+ * Two processes decide the same question. phi-server decides it in its guards, its Add-on capabilities
+ * and its API routes; the site decides it while rendering -- per navigation entry, per tree node, per
+ * menu item, and in the browser, where phi-server is not reachable without a round trip. Neither can
+ * defer to the other, so both evaluate, and the only way both can agree is that both compile the same
+ * source.
+ *
+ * They did not agree before this file existed. `flags: -1` on a stored claim admitted everything on the
+ * server and nothing in the UI, because one side normalised the value and the other did not. Nothing was
+ * wrong with either copy on its own, which is exactly why it went unnoticed.
+ *
+ * What belongs here is what two ends of one agreement must both know. Not what both happen to use.
+ */
+export declare const PHI_CORE_ROLE_PROVIDER_ID: "@phis/server/core";
+/**
+ * The Site roles Core itself grants, as bit flags.
+ *
+ * Flags rather than names, because these are Core's own and finite, they are stored on a membership row,
+ * and a viewer is checked against several at once. An Add-on's roles are the opposite case and are
+ * carried by name.
+ */
+export declare const PhiBaseRole: {
+    readonly Admin: number;
+    readonly Builder: number;
+    readonly Publisher: number;
+    readonly Author: number;
+    readonly Developer: number;
+    readonly Supporter: number;
+    readonly Accountant: number;
+};
+export type PhiRoleProviderId = `@${string}/${string}`;
+export type PhiGroupProviderId = `@${string}/${string}`;
+export type PhiViewerRoleClaim = {
+    providerId: PhiRoleProviderId;
+    flags: number;
+};
+export type PhiViewerGroupClaim = {
+    providerId: PhiGroupProviderId;
+    key: string;
+    flags: number;
+};
+/**
+ * The roles a Server Add-on declared, held by this viewer, by name.
+ *
+ * An Add-on's roles are frozen from the first assignment and declared in its own manifest, so a bit
+ * position would have to be handed out and kept forever -- reordering the manifest would silently change
+ * what a policy means, and thirty-two would be the ceiling. Core never interprets these names.
+ */
+export type PhiViewerAddonRoleClaim = {
+    providerId: PhiRoleProviderId;
+    roles: readonly string[];
+};
+export type PhiViewerAccessPolicy = {
+    access: "anyone";
+} | {
+    access: "anonymous";
+} | {
+    access: "authenticated";
+} | {
+    access: "roles";
+    providerId: PhiRoleProviderId;
+    allowedRoleFlags: number;
+} | {
+    access: "groups";
+    providerId: PhiGroupProviderId;
+    allowedGroupKeys: readonly string[];
+} | {
+    access: "addon-roles";
+    providerId: PhiRoleProviderId;
+    allowedRoles: readonly string[];
+};
+/**
+ * The least a viewer has to be for a policy to be decided about them.
+ *
+ * Deliberately smaller than either side's own viewer. phi-server carries `authenticated: boolean` and
+ * the UI carries an `access` that also drives rendering; making one of those shapes the shared one would
+ * have pushed a foreign concern into the other package. Each side keeps its own and passes a projection.
+ */
+export type PhiAccessSubject = {
+    authenticated: boolean;
+    roleClaims?: readonly PhiViewerRoleClaim[];
+    groupClaims?: readonly PhiViewerGroupClaim[];
+    /** Absent means none are known here, not that none are held: an `addon-roles` policy then denies. */
+    addonRoleClaims?: readonly PhiViewerAddonRoleClaim[];
+};
+export declare function getPhiViewerRoleFlags(subject: Pick<PhiAccessSubject, "roleClaims">, providerId: PhiRoleProviderId): number;
+export declare function hasProviderRole(subject: Pick<PhiAccessSubject, "roleClaims">, providerId: PhiRoleProviderId, roleFlag: number): boolean;
+export declare function hasPhiBaseRole(subject: Pick<PhiAccessSubject, "roleClaims">, roleFlag: number): boolean;
+export declare function hasProviderGroup(subject: Pick<PhiAccessSubject, "groupClaims">, providerId: PhiGroupProviderId, groupKey: string): boolean;
+export declare function hasProviderAddonRole(subject: Pick<PhiAccessSubject, "addonRoleClaims">, providerId: PhiRoleProviderId, role: string): boolean;
+/**
+ * Whether this subject may reach something guarded by this policy.
+ *
+ * A missing policy is `anyone`: a surface that states no requirement has none. Site Admin passes
+ * everything, which is the one shortcut in here and the reason a locked-out Site can always be reopened.
+ */
+export declare function canPhiAccessSubjectReach(subject: PhiAccessSubject, policy: PhiViewerAccessPolicy | null | undefined): boolean;
+/**
+ * Whether a policy names a provider its owner is allowed to name.
+ *
+ * A Module may gate on its own Add-on's roles and on Core's, and not on a stranger's -- otherwise one
+ * package could make its surface depend on another's vocabulary, which nobody would be responsible for
+ * keeping stable.
+ */
+export declare function isPhiAccessPolicyProviderOwned(policy: PhiViewerAccessPolicy, ownerProviderId?: PhiRoleProviderId | null): boolean;
+/**
+ * Reads a stored descriptor back into a policy, or null.
+ *
+ * Whatever does not read as a policy is refused rather than repaired: a half-understood requirement
+ * would decide what somebody is shown, and guessing at it is how a stricter rule quietly becomes a
+ * looser one.
+ */
+export declare function readPhiViewerAccessPolicy(value: unknown): PhiViewerAccessPolicy | null;

package/dist/access.js

@@ -0,0 +1,157 @@
+/**
+ * The authorization vocabulary phi-server and the site UI share.
+ *
+ * Two processes decide the same question. phi-server decides it in its guards, its Add-on capabilities
+ * and its API routes; the site decides it while rendering -- per navigation entry, per tree node, per
+ * menu item, and in the browser, where phi-server is not reachable without a round trip. Neither can
+ * defer to the other, so both evaluate, and the only way both can agree is that both compile the same
+ * source.
+ *
+ * They did not agree before this file existed. `flags: -1` on a stored claim admitted everything on the
+ * server and nothing in the UI, because one side normalised the value and the other did not. Nothing was
+ * wrong with either copy on its own, which is exactly why it went unnoticed.
+ *
+ * What belongs here is what two ends of one agreement must both know. Not what both happen to use.
+ */
+export const PHI_CORE_ROLE_PROVIDER_ID = "@phis/server/core";
+/**
+ * The Site roles Core itself grants, as bit flags.
+ *
+ * Flags rather than names, because these are Core's own and finite, they are stored on a membership row,
+ * and a viewer is checked against several at once. An Add-on's roles are the opposite case and are
+ * carried by name.
+ */
+export const PhiBaseRole = {
+    Admin: 1 << 0,
+    Builder: 1 << 1,
+    Publisher: 1 << 2,
+    Author: 1 << 3,
+    Developer: 1 << 4,
+    Supporter: 1 << 5,
+    Accountant: 1 << 6,
+};
+/**
+ * Flags as they may be trusted.
+ *
+ * A stored claim is data, and data can be wrong. A negative value passes a bitwise test against every
+ * mask there is, so reading it as written turns one bad row into every permission. Anything that is not
+ * a non-negative integer is read as no flags at all.
+ */
+function readRoleFlags(value) {
+    return typeof value === "number" && Number.isInteger(value) && value >= 0 ? value : 0;
+}
+export function getPhiViewerRoleFlags(subject, providerId) {
+    return readRoleFlags(subject.roleClaims?.find((claim) => claim.providerId === providerId)?.flags);
+}
+export function hasProviderRole(subject, providerId, roleFlag) {
+    const wanted = readRoleFlags(roleFlag);
+    return wanted !== 0 && (getPhiViewerRoleFlags(subject, providerId) & wanted) !== 0;
+}
+export function hasPhiBaseRole(subject, roleFlag) {
+    return hasProviderRole(subject, PHI_CORE_ROLE_PROVIDER_ID, roleFlag);
+}
+export function hasProviderGroup(subject, providerId, groupKey) {
+    return subject.groupClaims?.some((claim) => claim.providerId === providerId && claim.key === groupKey) === true;
+}
+export function hasProviderAddonRole(subject, providerId, role) {
+    return subject.addonRoleClaims?.some((claim) => claim.providerId === providerId && claim.roles.includes(role)) === true;
+}
+/**
+ * Whether this subject may reach something guarded by this policy.
+ *
+ * A missing policy is `anyone`: a surface that states no requirement has none. Site Admin passes
+ * everything, which is the one shortcut in here and the reason a locked-out Site can always be reopened.
+ */
+export function canPhiAccessSubjectReach(subject, policy) {
+    const resolved = policy ?? { access: "anyone" };
+    if (resolved.access === "anyone") {
+        return true;
+    }
+    if (resolved.access === "anonymous") {
+        return !subject.authenticated;
+    }
+    if (!subject.authenticated) {
+        return false;
+    }
+    if (resolved.access === "authenticated") {
+        return true;
+    }
+    if (hasPhiBaseRole(subject, PhiBaseRole.Admin)) {
+        return true;
+    }
+    if (resolved.access === "groups") {
+        return resolved.allowedGroupKeys.some((key) => hasProviderGroup(subject, resolved.providerId, key));
+    }
+    if (resolved.access === "addon-roles") {
+        return resolved.allowedRoles.some((role) => hasProviderAddonRole(subject, resolved.providerId, role));
+    }
+    return resolved.allowedRoleFlags > 0 &&
+        (getPhiViewerRoleFlags(subject, resolved.providerId) & resolved.allowedRoleFlags) !== 0;
+}
+/**
+ * Whether a policy names a provider its owner is allowed to name.
+ *
+ * A Module may gate on its own Add-on's roles and on Core's, and not on a stranger's -- otherwise one
+ * package could make its surface depend on another's vocabulary, which nobody would be responsible for
+ * keeping stable.
+ */
+export function isPhiAccessPolicyProviderOwned(policy, ownerProviderId) {
+    return (policy.access !== "roles" &&
+        policy.access !== "groups" &&
+        policy.access !== "addon-roles") ||
+        policy.providerId === PHI_CORE_ROLE_PROVIDER_ID ||
+        (ownerProviderId != null && policy.providerId === ownerProviderId);
+}
+const PROVIDER_ID_PATTERN = /^@[^/]+\/[^/]+(?:\/[^/]+)*$/;
+const GROUP_KEY_PATTERN = /^[a-z0-9][a-z0-9._-]{0,159}$/u;
+/** The same shape an Add-on manifest may declare a role under. */
+const ADDON_ROLE_NAME_PATTERN = /^[a-z][a-z0-9-]{0,63}$/;
+/**
+ * Reads a stored descriptor back into a policy, or null.
+ *
+ * Whatever does not read as a policy is refused rather than repaired: a half-understood requirement
+ * would decide what somebody is shown, and guessing at it is how a stricter rule quietly becomes a
+ * looser one.
+ */
+export function readPhiViewerAccessPolicy(value) {
+    if (!value || typeof value !== "object" || Array.isArray(value)) {
+        return null;
+    }
+    const record = value;
+    if (record.access === "anyone" ||
+        record.access === "anonymous" ||
+        record.access === "authenticated") {
+        return { access: record.access };
+    }
+    if (typeof record.providerId !== "string" || !PROVIDER_ID_PATTERN.test(record.providerId)) {
+        return null;
+    }
+    const providerId = record.providerId;
+    if (record.access === "roles" &&
+        typeof record.allowedRoleFlags === "number" &&
+        Number.isInteger(record.allowedRoleFlags) &&
+        record.allowedRoleFlags > 0) {
+        return { access: "roles", providerId, allowedRoleFlags: record.allowedRoleFlags };
+    }
+    if (record.access === "groups" &&
+        Array.isArray(record.allowedGroupKeys) &&
+        record.allowedGroupKeys.length > 0 &&
+        record.allowedGroupKeys.every((key) => typeof key === "string" && GROUP_KEY_PATTERN.test(key))) {
+        return {
+            access: "groups",
+            providerId,
+            allowedGroupKeys: [...new Set(record.allowedGroupKeys)],
+        };
+    }
+    if (record.access === "addon-roles" &&
+        Array.isArray(record.allowedRoles) &&
+        record.allowedRoles.length > 0 &&
+        record.allowedRoles.every((role) => typeof role === "string" && ADDON_ROLE_NAME_PATTERN.test(role))) {
+        return {
+            access: "addon-roles",
+            providerId,
+            allowedRoles: [...new Set(record.allowedRoles)],
+        };
+    }
+    return null;
+}

package/dist/addon-index.d.ts

@@ -0,0 +1,6 @@
+export * from "./addon.js";
+export * from "./capabilities.js";
+export * from "./core.js";
+export * from "./media-storage.js";
+export * from "./queries.js";
+export * from "./schema.js";

package/dist/addon-index.js

@@ -0,0 +1,6 @@
+export * from "./addon.js";
+export * from "./capabilities.js";
+export * from "./core.js";
+export * from "./media-storage.js";
+export * from "./queries.js";
+export * from "./schema.js";