current-cli 0.1.42__tar.gz → 0.1.43__tar.gz

{current_cli-0.1.42 → current_cli-0.1.43}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: current-cli
-Version: 0.1.42
+Version: 0.1.43
 Summary: Command line interface for the Current API, generated from its OpenAPI schema at runtime
 Author-email: Orin <your-email@example.com>
 License-Expression: MIT

{current_cli-0.1.42 → current_cli-0.1.43}/current_cli/schema.yml

@@ -2093,12 +2093,29 @@ paths:
         Thumbs up/down (+ optional reason and comment) on a piece of platform
         output.
 
-        Reads are author-only: a member sees the reactions they gave, and never
-        anyone else's. Feedback on the platform's own output is candid only when
-        the member knows their colleagues are not reading it, and no surface
-        shows another member's reaction. Aggregate sentiment is a reporting
-        question, answered off the table directly rather than through this
-        endpoint.
+        Reads have two scopes, chosen by the ``scope`` query parameter:
+
+        - ``mine`` (the default) — the reactions the caller gave, and nobody
+          else's. This is what a plain member gets, whatever they ask for.
+        - ``workspace`` — every member's reactions, restricted to the workspaces
+          the caller is an admin of. A caller who administers no workspace reads
+          nothing under this scope; an admin of one workspace does not thereby
+          read a workspace where they are only a member.
+
+        Author-only is the default rather than the rule because the alternative
+        breaks the caller that exists. The portal reads this endpoint to draw a
+        member's own thumb (``getMyReaction``/``getMyReactions`` in
+        ``reactionsLogic.ts``) and takes the first row for a subject as "my
+        current reaction". Widening reads for admins by default would silently
+        make an admin's own widget show whichever teammate reacted last. An
+        explicit ``scope=workspace`` keeps that call path byte-for-byte
+        unchanged and makes reading a colleague's feedback a deliberate act.
+
+        A member is told this: feedback is private from their colleagues, but an
+        admin of their workspace can read it. That is a weaker promise than the
+        one this endpoint shipped with, and it is the honest one — an admin has
+        to be able to see whether the platform's output is any good, and the
+        alternative in practice was reading the production database.
 
         Create for any member of the workspace — every submission is a new row
         (see ``Reaction``). No update or delete: a changed mind is a new
@@ -2121,6 +2138,16 @@ paths:
         schema:
           type: string
         description: Filter by project UUID
+      - in: query
+        name: scope
+        schema:
+          type: string
+          enum:
+          - mine
+          - workspace
+        description: Whose reactions to read. 'mine' (the default) reads your own.
+          'workspace' reads every member's, and returns rows only from the workspaces
+          you are an admin of.
       - in: query
         name: subject_id
         schema:
@@ -2159,12 +2186,29 @@ paths:
         Thumbs up/down (+ optional reason and comment) on a piece of platform
         output.
 
-        Reads are author-only: a member sees the reactions they gave, and never
-        anyone else's. Feedback on the platform's own output is candid only when
-        the member knows their colleagues are not reading it, and no surface
-        shows another member's reaction. Aggregate sentiment is a reporting
-        question, answered off the table directly rather than through this
-        endpoint.
+        Reads have two scopes, chosen by the ``scope`` query parameter:
+
+        - ``mine`` (the default) — the reactions the caller gave, and nobody
+          else's. This is what a plain member gets, whatever they ask for.
+        - ``workspace`` — every member's reactions, restricted to the workspaces
+          the caller is an admin of. A caller who administers no workspace reads
+          nothing under this scope; an admin of one workspace does not thereby
+          read a workspace where they are only a member.
+
+        Author-only is the default rather than the rule because the alternative
+        breaks the caller that exists. The portal reads this endpoint to draw a
+        member's own thumb (``getMyReaction``/``getMyReactions`` in
+        ``reactionsLogic.ts``) and takes the first row for a subject as "my
+        current reaction". Widening reads for admins by default would silently
+        make an admin's own widget show whichever teammate reacted last. An
+        explicit ``scope=workspace`` keeps that call path byte-for-byte
+        unchanged and makes reading a colleague's feedback a deliberate act.
+
+        A member is told this: feedback is private from their colleagues, but an
+        admin of their workspace can read it. That is a weaker promise than the
+        one this endpoint shipped with, and it is the honest one — an admin has
+        to be able to see whether the platform's output is any good, and the
+        alternative in practice was reading the production database.
 
         Create for any member of the workspace — every submission is a new row
         (see ``Reaction``). No update or delete: a changed mind is a new
@@ -2200,12 +2244,29 @@ paths:
         Thumbs up/down (+ optional reason and comment) on a piece of platform
         output.
 
-        Reads are author-only: a member sees the reactions they gave, and never
-        anyone else's. Feedback on the platform's own output is candid only when
-        the member knows their colleagues are not reading it, and no surface
-        shows another member's reaction. Aggregate sentiment is a reporting
-        question, answered off the table directly rather than through this
-        endpoint.
+        Reads have two scopes, chosen by the ``scope`` query parameter:
+
+        - ``mine`` (the default) — the reactions the caller gave, and nobody
+          else's. This is what a plain member gets, whatever they ask for.
+        - ``workspace`` — every member's reactions, restricted to the workspaces
+          the caller is an admin of. A caller who administers no workspace reads
+          nothing under this scope; an admin of one workspace does not thereby
+          read a workspace where they are only a member.
+
+        Author-only is the default rather than the rule because the alternative
+        breaks the caller that exists. The portal reads this endpoint to draw a
+        member's own thumb (``getMyReaction``/``getMyReactions`` in
+        ``reactionsLogic.ts``) and takes the first row for a subject as "my
+        current reaction". Widening reads for admins by default would silently
+        make an admin's own widget show whichever teammate reacted last. An
+        explicit ``scope=workspace`` keeps that call path byte-for-byte
+        unchanged and makes reading a colleague's feedback a deliberate act.
+
+        A member is told this: feedback is private from their colleagues, but an
+        admin of their workspace can read it. That is a weaker promise than the
+        one this endpoint shipped with, and it is the honest one — an admin has
+        to be able to see whether the platform's output is any good, and the
+        alternative in practice was reading the production database.
 
         Create for any member of the workspace — every submission is a new row
         (see ``Reaction``). No update or delete: a changed mind is a new
@@ -2218,6 +2279,16 @@ paths:
           format: uuid
         description: A UUID string identifying this reaction.
         required: true
+      - in: query
+        name: scope
+        schema:
+          type: string
+          enum:
+          - mine
+          - workspace
+        description: Whose reactions to read. 'mine' (the default) reads your own.
+          'workspace' reads every member's, and returns rows only from the workspaces
+          you are an admin of.
       tags:
       - reactions
       security:

{current_cli-0.1.42 → current_cli-0.1.43}/llms.txt

@@ -758,12 +758,29 @@ Options:
 Thumbs up/down (+ optional reason and comment) on a piece of platform
 output.
 
-Reads are author-only: a member sees the reactions they gave, and never
-anyone else's. Feedback on the platform's own output is candid only when
-the member knows their colleagues are not reading it, and no surface
-shows another member's reaction. Aggregate sentiment is a reporting
-question, answered off the table directly rather than through this
-endpoint.
+Reads have two scopes, chosen by the ``scope`` query parameter:
+
+- ``mine`` (the default) — the reactions the caller gave, and nobody
+  else's. This is what a plain member gets, whatever they ask for.
+- ``workspace`` — every member's reactions, restricted to the workspaces
+  the caller is an admin of. A caller who administers no workspace reads
+  nothing under this scope; an admin of one workspace does not thereby
+  read a workspace where they are only a member.
+
+Author-only is the default rather than the rule because the alternative
+breaks the caller that exists. The portal reads this endpoint to draw a
+member's own thumb (``getMyReaction``/``getMyReactions`` in
+``reactionsLogic.ts``) and takes the first row for a subject as "my
+current reaction". Widening reads for admins by default would silently
+make an admin's own widget show whichever teammate reacted last. An
+explicit ``scope=workspace`` keeps that call path byte-for-byte
+unchanged and makes reading a colleague's feedback a deliberate act.
+
+A member is told this: feedback is private from their colleagues, but an
+admin of their workspace can read it. That is a weaker promise than the
+one this endpoint shipped with, and it is the honest one — an admin has
+to be able to see whether the platform's output is any good, and the
+alternative in practice was reading the production database.
 
 Create for any member of the workspace — every submission is a new row
 (see ``Reaction``). No update or delete: a changed mind is a new
@@ -779,12 +796,29 @@ Options:
 Thumbs up/down (+ optional reason and comment) on a piece of platform
 output.
 
-Reads are author-only: a member sees the reactions they gave, and never
-anyone else's. Feedback on the platform's own output is candid only when
-the member knows their colleagues are not reading it, and no surface
-shows another member's reaction. Aggregate sentiment is a reporting
-question, answered off the table directly rather than through this
-endpoint.
+Reads have two scopes, chosen by the ``scope`` query parameter:
+
+- ``mine`` (the default) — the reactions the caller gave, and nobody
+  else's. This is what a plain member gets, whatever they ask for.
+- ``workspace`` — every member's reactions, restricted to the workspaces
+  the caller is an admin of. A caller who administers no workspace reads
+  nothing under this scope; an admin of one workspace does not thereby
+  read a workspace where they are only a member.
+
+Author-only is the default rather than the rule because the alternative
+breaks the caller that exists. The portal reads this endpoint to draw a
+member's own thumb (``getMyReaction``/``getMyReactions`` in
+``reactionsLogic.ts``) and takes the first row for a subject as "my
+current reaction". Widening reads for admins by default would silently
+make an admin's own widget show whichever teammate reacted last. An
+explicit ``scope=workspace`` keeps that call path byte-for-byte
+unchanged and makes reading a colleague's feedback a deliberate act.
+
+A member is told this: feedback is private from their colleagues, but an
+admin of their workspace can read it. That is a weaker promise than the
+one this endpoint shipped with, and it is the honest one — an admin has
+to be able to see whether the platform's output is any good, and the
+alternative in practice was reading the production database.
 
 Create for any member of the workspace — every submission is a new row
 (see ``Reaction``). No update or delete: a changed mind is a new
@@ -796,6 +830,7 @@ Options:
 - `--limit` - Number of results to return per page.
 - `--offset` - The initial index from which to return the results.
 - `--project` - Filter by project UUID
+- `--scope` - Whose reactions to read. 'mine' (the default) reads your own. 'workspace' reads every member's, and returns rows only from the workspaces you are an admin of.
 - `--subject-id` - Filter by subject id
 - `--subject-type` - Filter by subject type
 - `--subject-version` - Filter by subject version
@@ -806,12 +841,29 @@ Options:
 Thumbs up/down (+ optional reason and comment) on a piece of platform
 output.
 
-Reads are author-only: a member sees the reactions they gave, and never
-anyone else's. Feedback on the platform's own output is candid only when
-the member knows their colleagues are not reading it, and no surface
-shows another member's reaction. Aggregate sentiment is a reporting
-question, answered off the table directly rather than through this
-endpoint.
+Reads have two scopes, chosen by the ``scope`` query parameter:
+
+- ``mine`` (the default) — the reactions the caller gave, and nobody
+  else's. This is what a plain member gets, whatever they ask for.
+- ``workspace`` — every member's reactions, restricted to the workspaces
+  the caller is an admin of. A caller who administers no workspace reads
+  nothing under this scope; an admin of one workspace does not thereby
+  read a workspace where they are only a member.
+
+Author-only is the default rather than the rule because the alternative
+breaks the caller that exists. The portal reads this endpoint to draw a
+member's own thumb (``getMyReaction``/``getMyReactions`` in
+``reactionsLogic.ts``) and takes the first row for a subject as "my
+current reaction". Widening reads for admins by default would silently
+make an admin's own widget show whichever teammate reacted last. An
+explicit ``scope=workspace`` keeps that call path byte-for-byte
+unchanged and makes reading a colleague's feedback a deliberate act.
+
+A member is told this: feedback is private from their colleagues, but an
+admin of their workspace can read it. That is a weaker promise than the
+one this endpoint shipped with, and it is the honest one — an admin has
+to be able to see whether the platform's output is any good, and the
+alternative in practice was reading the production database.
 
 Create for any member of the workspace — every submission is a new row
 (see ``Reaction``). No update or delete: a changed mind is a new
@@ -819,6 +871,9 @@ reaction, not an edit to the old one.
 
 GET /api/reactions/reactions/{id}/
 
+Options:
+- `--scope` - Whose reactions to read. 'mine' (the default) reads your own. 'workspace' reads every member's, and returns rows only from the workspaces you are an admin of.
+
 ### current tasks create
 
 The caller's personal todos. Incomplete tasks sort before completed ones.

{current_cli-0.1.42 → current_cli-0.1.43}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "current-cli"
-version = "0.1.42"
+version = "0.1.43"
 description = "Command line interface for the Current API, generated from its OpenAPI schema at runtime"
 readme = "README.md"
 requires-python = ">=3.10"