spencerm/PacketStation
1
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: issue 6 keeps every tightening row, Shipping filing included

Browse Source 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
spencerm
2026-10-27 15:03:12 -06:00
co-authored by Claude Opus 5.5
parent 8e69b38e0b
commit 20ee7a8130
3 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/PLAN.md
+1 -1
View File
@@ -222,7 +222,7 @@ Need an answer before the named phase. Defaults apply if none arrives in time.
4. **PIN defaults** (confirm): 6 to 12 digits, five attempts, 10-hour shop session, device cookie. Was open (Seth and Q.C., before phase 6): whether Q.C. accept and filing require the domain password even with a PIN set. Default: PIN is enough. Confirmed by SethD on 2026-10-26, Gitea issue 2: the PIN is enough for every sign-off, Q.C. accept and filing included. IT: device certificate later. The device cookie stays and no device certificate is planned: confirmed by Spencer (IT) on 2026-10-18, Gitea issue 3.
5. **Several open orders on a project** (before phase 3): which order a packet shows. Proposed rule: the open order whose line's top job is the packet's work order base, else the newest open order, else the newest closed one; the packet shows "via base" or "via project" and Clerical can override. Needs Seth's view. Phase 3 (2026-10-16) built the default in one function (`feed/orders.py`): a Clerical pin, else the base's own linked order, else the project order whose top job is the unit, else the project's first open order, else its newest; the source (`via`) is stored on the project and unit and shown on the project page, which lists every open order. Seth may change the rule later in that one place.
6. **VISUAL_ENCRYPT** (IT, before production): yes once vsql has a trusted certificate; `no` until then.
7. **Policy tightenings** listed under "Challenges" 1 to 3 (Seth, before phase 2). SethD on 2026-10-26, Gitea issue 6: "good as shown". The issue's checklist left two rows unticked: the warehouse release gate, which SethD confirmed on issue 16, and filing for packets routed to Shipping, which is asked on issue 6. Issue 6 stays open for that row; every other row is kept.
7. **Policy tightenings** listed under "Challenges" 1 to 3 (Seth, before phase 2). Confirmed by SethD on 2026-10-26, Gitea issue 6: "good as shown". Every row is kept, filing for packets routed to Shipping included (Spencer read the answer that way on 2026-10-27).
8. **Repo location**: PacketStation2 as proposed, or another name.
9. **Retention period** (D6) and customer-facing data book copy (D7): deferred, but a decision from Seth and Q.C. lets a later phase close them.
docs/POLICY.md
+1 -1
View File
@@ -995,7 +995,7 @@ On a draft made by the feed that is flagged (or already has a hand upload), Cler
The old policy was looser than the old screens in places. The rebuild follows the screens where they were stricter, and the README where it states the intent. Each row is a change Seth can veto.
SethD answered on 2026-10-26: the rows are kept as shown (Gitea issue 6), the data book date (issue 14), the withdrawn verification and ITP initials rows (issue 15), both release rows (issue 16) and the block signature row (issue 26). One row is still asked on issue 6: filing for packets routed to Shipping.
SethD answered on 2026-10-26: every row is kept as shown (Gitea issue 6), and he confirmed the data book date (issue 14), the withdrawn verification and ITP initials rows (issue 15), both release rows (issue 16) and the block signature row (issue 26).
| What the old build allowed | What the rebuild does | Why | Can be vetoed |
|---|---|---|---|