tegwick
d573ef5e3d
Some checks failed
Use-case regression gate / usecase-regressions (push) Failing after 3m19s
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a192e9-c28b-7533-bf25-e2341364c22a
129 lines
6.7 KiB
Markdown
129 lines
6.7 KiB
Markdown
# Productive content acceptance session
|
|
|
|
The sharing correction image85378d10/source61c154f is independently verified at
|
|
Helm revision22, completed2026-11-01T20:16:44Z. The editor attachment correction
|
|
remains included. Record your review date and actual verdicts.
|
|
|
|
Use your normal account at https://app.coulomb.social. Create two private spaces,
|
|
`acceptance-a-20261031` and `acceptance-b-20261031`, or choose unused names if those
|
|
already exist. These are disposable review spaces. Keep existing workspaces and
|
|
their grants intact. Keep the review artifacts until the verdicts are recorded.
|
|
|
|
## 1. Authoring and attachments — UC-003 / WP-0013-T06
|
|
|
|
In space A, create a page titled `Acceptance notes`, file name `notes`, and abstract
|
|
`Content and attachment review`. Use this body:
|
|
|
|
```html
|
|
Acceptance notes.
|
|
|
|
<ol start="3">
|
|
<li>Third item</li>
|
|
<li>Fourth item</li>
|
|
</ol>
|
|
|
|
**Keep this text when adding or removing attachments.**
|
|
```
|
|
|
|
Save and reopen. The list should start at3. In Attachments, add
|
|
[attachment-check.txt](fixtures/productive-content-acceptance/attachment-check.txt)
|
|
and [visual-check.png](fixtures/productive-content-acceptance/visual-check.png).
|
|
Download the text file and open the image: the text has two short lines and the
|
|
image has blue and yellow halves. Files should remain available after reopening.
|
|
|
|
To check a page Visual, use Open image and take the `assets/...` part of its
|
|
address as the Visual field in the page editor. Save and check the displayed
|
|
image. Edit the title/abstract/body and reopen to check persistence.
|
|
|
|
Open the page editor in two tabs. Both should show Attachments with working
|
|
downloads. Save a change in the first; then try saving the
|
|
older second tab. The second submission must retain your submitted text and ask
|
|
you to reopen/merge rather than overwrite the newer page; its Attachments section should remain visible. Return to the current
|
|
page and check that its attachments and Visual remain intact.
|
|
|
|
Verdicts: `UC-003 accepted/gap` and `attachments accepted/gap`, with any observed
|
|
difference. The custom-topic rendering and obsolete-scrap dispositions are already
|
|
recorded; they do not need another review.
|
|
|
|
## 2. Independent copy and move — UC-004
|
|
|
|
Duplicate the page into space B with file name `copied`. Change its body and
|
|
remove its text attachment. Reopen the original in A: its body and downloadable
|
|
text file should remain unchanged. The removed copy's earlier revisions retain
|
|
the file, as agreed in the retention policy.
|
|
|
|
Create another duplicate in A with file name `moving`, retaining both files.
|
|
Save its address before moving it to B with file name `moved`. Its content,
|
|
Visual and downloads should remain intact. Its old address should reach the
|
|
destination for an authorized account; the sharing check below verifies denial
|
|
when the destination is private to you.
|
|
|
|
Verdict: `UC-004 accepted/gap`, including the incoming-address permission result
|
|
once the second participant has checked it.
|
|
|
|
## 3. Sharing and revocation — UC-005
|
|
|
|
The user nominated `testuser` as the second participant. The live app had only
|
|
one member at preparation. An existing platform/LLDAP user does not need a second
|
|
registration: in a separate browser profile or private window, open
|
|
https://app.coulomb.social, choose **Sign in**, and authenticate as `testuser`
|
|
with the existing platform account. After successful verified platform sign-in,
|
|
the app links the platform identity and creates its local member profile on first
|
|
use. There is currently no separate “Join this application” confirmation step.
|
|
This does not grant access to the owner's private spaces.
|
|
|
|
Open https://app.coulomb.social/account/data/ as `testuser` and obtain **Your member
|
|
ID**. The user approved owner-managed sharing with any active Coulomb member,
|
|
regardless of platform identity tenant, on 2026-11-01. No directory group or
|
|
platform role change is needed. The correction is deployed and independently verified at revision22;
|
|
reopen Share space and retry Update access.
|
|
|
|
The user confirmed successful `testuser` first sign-in and initial denial on
|
|
2026-11-01. Revision21 refused the grant because `testuser` is in `tenant:coulomb`
|
|
and `tegwick`/the review spaces are in `tenant:platform`. That diagnosis is
|
|
recorded; the corrected release is live and viewer/revoked states need user review.
|
|
|
|
The same participant can cover the ungranted, viewer and revoked states in
|
|
sequence, using their own browser session.
|
|
|
|
Before a grant, they try the A page and its direct image/download URLs: access
|
|
must be denied. In A's Share space screen, grant their member ID Viewer access.
|
|
They should now read and download, but receive denial for direct edit/copy/move
|
|
URLs copied from your session. Space B stays private: they must be denied both
|
|
the moved page and its old incoming address.
|
|
|
|
Revoke their A access. They retry the page, image and saved download URLs: each
|
|
must be denied. Review the remaining grants and creator access in Share space.
|
|
Sharing does not send email.
|
|
|
|
Verdict: `UC-005 accepted/gap`, including the participant's three access states.
|
|
|
|
## 4. Account-local portability — UC-006
|
|
|
|
Open https://app.coulomb.social/account/data/ and Export my account records.
|
|
Inspect the downloaded JSON privately: profile, identity references and space
|
|
memberships should match your local account. Pages/assets remain in their spaces;
|
|
this account export is distinct from the complete operator client-data export.
|
|
|
|
Review Leaving the app and the ownership/succession explanation. Sole-owned
|
|
spaces must gain another active owner before local account removal. Shared
|
|
content remains, while platform identity and mailbox remain under their existing
|
|
owners. Review these screens with your productive account. Any actual account
|
|
removal exercise needs a separately selected disposable member.
|
|
|
|
Verdict: `UC-006 accepted/gap`, stating whether export and the displayed exit/
|
|
succession semantics meet your needs. Keep the account export private.
|
|
|
|
## Result record
|
|
|
|
Record the deployed revision/date and each verdict independently:
|
|
|
|
- UC-003 authoring:
|
|
- Attachments: editor visibility confirmed; owner copy/removal independence accepted in step2. Reader/revoked access remains step3.
|
|
- UC-004 copy/move and old-address permissions: owner workflow accepted2026-11-01 (“The step 2 of the walkthrough seems fine.”). Participant denial through the old address remains step3.
|
|
- UC-005 sharing/revocation: revision22 Viewer flow accepted2026-11-01. User confirms read access to A, visible attachments, no editing, and other spaces hidden. Moved-page old-address denial and revoked page/download denial remain pending.
|
|
- UC-006 account-local export and exit/succession semantics:
|
|
|
|
An unresolved gap or an unperformed participant check stays open. Automated
|
|
regression, native postflight and recovered-store proofs remain supporting
|
|
evidence and do not supply these user verdicts.
|