Compare commits
5 Commits
fix/850-de
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
| 4e5af23214 | |||
|
|
880c28b191 | ||
|
|
7bc2dfb6c8 | ||
| b0d78d8632 | |||
| 344d86a635 |
@@ -661,13 +661,27 @@ describe('whole mutator-class lease gate', () => {
|
|||||||
test('observer revocation and monotonic TTL expiry deny the next mutator', async () => {
|
test('observer revocation and monotonic TTL expiry deny the next mutator', async () => {
|
||||||
const { socket } = await startBroker();
|
const { socket } = await startBroker();
|
||||||
const sessionId = await register(socket);
|
const sessionId = await register(socket);
|
||||||
const pending = await beginVerification(socket, sessionId, 'claude', 1, 1);
|
|
||||||
await promote(socket, sessionId, pending.receipt_challenge!);
|
|
||||||
|
|
||||||
|
// Establish the lease with a normal (non-racing) TTL first and prove it
|
||||||
|
// authorizes. This "still valid" check is setup, not a TTL-expiry
|
||||||
|
// assertion, so it must not share a lease with a 1-second TTL: on a
|
||||||
|
// contended push-CI host, scheduling delay alone between promote() and
|
||||||
|
// this authorize() call can consume that entire 1-second margin and
|
||||||
|
// spuriously deny it (CI#1945). Using a generous TTL here removes that
|
||||||
|
// real-time race without touching lease-gate security semantics.
|
||||||
|
const pending = await beginVerification(socket, sessionId, 'claude');
|
||||||
|
await promote(socket, sessionId, pending.receipt_challenge!);
|
||||||
expect(await authorize(socket, sessionId, 'claude', 'Bash')).toMatchObject({
|
expect(await authorize(socket, sessionId, 'claude', 'Bash')).toMatchObject({
|
||||||
ok: true,
|
ok: true,
|
||||||
decision: 'allow',
|
decision: 'allow',
|
||||||
});
|
});
|
||||||
|
|
||||||
|
// A dedicated, isolated short-TTL lease drives the deliberate monotonic
|
||||||
|
// expiry demonstration below. It is never used for anything but the
|
||||||
|
// wait-then-expire assertion, so there is no setup work racing its
|
||||||
|
// 1-second window.
|
||||||
|
const shortLived = await beginVerification(socket, sessionId, 'claude', 1, 1, 2);
|
||||||
|
await promote(socket, sessionId, shortLived.receipt_challenge!);
|
||||||
await new Promise((resolve) => setTimeout(resolve, 1_100));
|
await new Promise((resolve) => setTimeout(resolve, 1_100));
|
||||||
expect(await authorize(socket, sessionId, 'claude', 'Bash')).toMatchObject({
|
expect(await authorize(socket, sessionId, 'claude', 'Bash')).toMatchObject({
|
||||||
ok: false,
|
ok: false,
|
||||||
@@ -675,7 +689,7 @@ describe('whole mutator-class lease gate', () => {
|
|||||||
decision: 'deny',
|
decision: 'deny',
|
||||||
});
|
});
|
||||||
|
|
||||||
const refreshed = await beginVerification(socket, sessionId, 'claude', 1, 300, 2);
|
const refreshed = await beginVerification(socket, sessionId, 'claude', 1, 300, 3);
|
||||||
await promote(socket, sessionId, refreshed.receipt_challenge!);
|
await promote(socket, sessionId, refreshed.receipt_challenge!);
|
||||||
expect(
|
expect(
|
||||||
await request(socket, {
|
await request(socket, {
|
||||||
|
|||||||
50
skills/glpi-create/SKILL.md
Normal file
50
skills/glpi-create/SKILL.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
# Skill: glpi-create — Open a New GLPI Ticket
|
||||||
|
|
||||||
|
> Create a new GLPI helpdesk ticket. Mutates GLPI — confirm the details before running.
|
||||||
|
|
||||||
|
## When to use
|
||||||
|
|
||||||
|
- Logging a new incident or request that should live in the helpdesk queue.
|
||||||
|
|
||||||
|
## Required information
|
||||||
|
|
||||||
|
- **title** — short subject line.
|
||||||
|
- **content** — description of the issue / request.
|
||||||
|
|
||||||
|
## Optional
|
||||||
|
|
||||||
|
- **priority** — `1`=VeryLow, `2`=Low, `3`=Medium (default), `4`=High, `5`=VeryHigh, `6`=Major.
|
||||||
|
- **type** — `1`=Incident (default), `2`=Request.
|
||||||
|
|
||||||
|
## Command
|
||||||
|
|
||||||
|
Wraps the existing tooling:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
~/.config/mosaic/tools/glpi/ticket-create.sh \
|
||||||
|
-t "<title>" \
|
||||||
|
-c "<content>" \
|
||||||
|
[-p <priority>] \
|
||||||
|
[-y <type>] \
|
||||||
|
[-f json]
|
||||||
|
```
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
~/.config/mosaic/tools/glpi/ticket-create.sh \
|
||||||
|
-t "Paint-area camera install" \
|
||||||
|
-c "Ordered 2 cameras for Paint and stock; schedule mounting + NVR config." \
|
||||||
|
-p 3 -y 2
|
||||||
|
```
|
||||||
|
|
||||||
|
## After creating
|
||||||
|
|
||||||
|
- Note the returned **ticket ID** — you'll need it for **[[glpi-followup]]** and
|
||||||
|
**[[glpi-solve]]**.
|
||||||
|
- If it should also be tracked as brain work, add a matching task (see the `add-task` skill).
|
||||||
|
|
||||||
|
## Guardrails
|
||||||
|
|
||||||
|
- Confirm title/content/priority with the user before creating — a ticket is outward-facing.
|
||||||
|
- Never echo GLPI tokens.
|
||||||
56
skills/glpi-followup/SKILL.md
Normal file
56
skills/glpi-followup/SKILL.md
Normal file
@@ -0,0 +1,56 @@
|
|||||||
|
# Skill: glpi-followup — Add a Followup to a GLPI Ticket
|
||||||
|
|
||||||
|
> Post a followup (comment / progress note / resolution writeup) to a GLPI ticket.
|
||||||
|
> This documents work but does **not** change the ticket status — to close a ticket
|
||||||
|
> out, follow with **[[glpi-solve]]** to set status to Solved.
|
||||||
|
|
||||||
|
## When to use
|
||||||
|
|
||||||
|
- Recording progress, a decision, or a root-cause/resolution note on a ticket.
|
||||||
|
- The documentation step that usually precedes closing a ticket out (`glpi-solve`).
|
||||||
|
|
||||||
|
## Critical quirk
|
||||||
|
|
||||||
|
Use the **top-level `/ITILFollowup` endpoint**, NOT `/Ticket/<id>/ITILFollowup`. The
|
||||||
|
sub-resource path returns permission errors even with a Super-Admin profile.
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
|
||||||
|
### 1. Session + creds
|
||||||
|
|
||||||
|
```bash
|
||||||
|
SESSION=$(~/.config/mosaic/tools/glpi/session-init.sh -q)
|
||||||
|
source ~/.config/mosaic/tools/_lib/credentials.sh && load_credentials glpi
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Post the followup
|
||||||
|
|
||||||
|
```bash
|
||||||
|
TICKET_ID=<id>
|
||||||
|
CONTENT="<the followup text>"
|
||||||
|
curl -sk -X POST "${GLPI_URL}/ITILFollowup" \
|
||||||
|
-H "App-Token: $GLPI_APP_TOKEN" \
|
||||||
|
-H "Session-Token: $SESSION" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d "$(jq -n --argjson id "$TICKET_ID" --arg c "$CONTENT" \
|
||||||
|
'{input:{itemtype:"Ticket", items_id:$id, content:$c}}')"
|
||||||
|
```
|
||||||
|
|
||||||
|
Expect HTTP 201. Building the payload with `jq` keeps quotes/newlines in the content safe.
|
||||||
|
|
||||||
|
### 3. Long or multi-paragraph content
|
||||||
|
|
||||||
|
Write the note to a file first, then read it into the payload:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl -sk -X POST "${GLPI_URL}/ITILFollowup" \
|
||||||
|
-H "App-Token: $GLPI_APP_TOKEN" -H "Session-Token: $SESSION" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d "$(jq -n --argjson id "$TICKET_ID" --rawfile c /path/to/note.md \
|
||||||
|
'{input:{itemtype:"Ticket", items_id:$id, content:$c}}')"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Guardrails
|
||||||
|
|
||||||
|
- Never echo the GLPI app/user/session tokens.
|
||||||
|
- A followup alone leaves the ticket open. If the work is done, run **[[glpi-solve]]** next.
|
||||||
57
skills/glpi-list/SKILL.md
Normal file
57
skills/glpi-list/SKILL.md
Normal file
@@ -0,0 +1,57 @@
|
|||||||
|
# Skill: glpi-list — Query GLPI Tickets
|
||||||
|
|
||||||
|
> Quick lookups of GLPI helpdesk tickets by status or recency. Read-only.
|
||||||
|
|
||||||
|
## When to use
|
||||||
|
|
||||||
|
- "What tickets are open / pending?" · "Show recent tickets" · finding a ticket ID
|
||||||
|
before running **[[glpi-followup]]** or **[[glpi-solve]]**.
|
||||||
|
|
||||||
|
## Command
|
||||||
|
|
||||||
|
Wraps the existing tooling:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
GLPI=~/.config/mosaic/tools/glpi
|
||||||
|
|
||||||
|
# Most recent tickets (default 50, newest first)
|
||||||
|
"$GLPI/ticket-list.sh"
|
||||||
|
|
||||||
|
# Filter by status: new | processing | pending | solved | closed
|
||||||
|
"$GLPI/ticket-list.sh" -s pending
|
||||||
|
|
||||||
|
# JSON output (for parsing / piping to jq) and a custom limit
|
||||||
|
"$GLPI/ticket-list.sh" -s processing -f json -l 20
|
||||||
|
```
|
||||||
|
|
||||||
|
Status IDs: 1 New · 2/3 Processing · 4 Pending · 5 Solved · 6 Closed.
|
||||||
|
|
||||||
|
## Details lookup for one ticket
|
||||||
|
|
||||||
|
When you have an ID and want the full record:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
SESSION=$(~/.config/mosaic/tools/glpi/session-init.sh -q)
|
||||||
|
source ~/.config/mosaic/tools/_lib/credentials.sh && load_credentials glpi
|
||||||
|
curl -sk "${GLPI_URL}/Ticket/<id>?expand_dropdowns=true" \
|
||||||
|
-H "App-Token: $GLPI_APP_TOKEN" -H "Session-Token: $SESSION" \
|
||||||
|
| jq '{id, name, status, date, date_mod}'
|
||||||
|
|
||||||
|
# Followups on a ticket
|
||||||
|
curl -sk "${GLPI_URL}/Ticket/<id>/ITILFollowup" \
|
||||||
|
-H "App-Token: $GLPI_APP_TOKEN" -H "Session-Token: $SESSION" \
|
||||||
|
| jq '.[] | {date, content}'
|
||||||
|
```
|
||||||
|
|
||||||
|
(Reading followups via the sub-resource is fine — only _creating_ them requires the
|
||||||
|
top-level `/ITILFollowup` endpoint. See **[[glpi-followup]]**.)
|
||||||
|
|
||||||
|
## Present to user
|
||||||
|
|
||||||
|
Group by status, one line per ticket: `#<id> · <title> · <status> · <last-modified>`.
|
||||||
|
Use neutral phrasing — no "OVERDUE"/"URGENT".
|
||||||
|
|
||||||
|
## Guardrails
|
||||||
|
|
||||||
|
- Read-only. Never echo GLPI tokens.
|
||||||
|
- To sync tickets into brain data instead, use `python tools/sync_glpi.py` (not this skill).
|
||||||
96
skills/glpi-solve/SKILL.md
Normal file
96
skills/glpi-solve/SKILL.md
Normal file
@@ -0,0 +1,96 @@
|
|||||||
|
# Skill: glpi-solve — Close Out a GLPI Ticket
|
||||||
|
|
||||||
|
> Properly close out a completed GLPI helpdesk ticket. Completing the work is not
|
||||||
|
> enough — the ticket **status must be set to "Solved"**, which is what triggers
|
||||||
|
> GLPI's config-driven auto-close. Posting a resolution followup documents the work
|
||||||
|
> but does **not** change status, so a ticket left at Solved-less status stays open.
|
||||||
|
|
||||||
|
## When to use
|
||||||
|
|
||||||
|
- Any time work on a GLPI ticket is finished and it should be closed out.
|
||||||
|
- After posting a root-cause / resolution writeup as an `/ITILFollowup`.
|
||||||
|
- During a cleanup sweep of tickets that are done in reality but still open in GLPI.
|
||||||
|
|
||||||
|
## The rule (from an operator, 2026-07-20)
|
||||||
|
|
||||||
|
**"Solved" is the correct terminal state to set — not "Closed."** GLPI is configured
|
||||||
|
to auto-close Solved tickets after its delay. If you only post a followup and never set
|
||||||
|
status, the ticket sits open (this bit us on a real incident where resolution followups
|
||||||
|
were posted but status was never advanced, leaving tickets open, which the operator had
|
||||||
|
to mark Solved by hand).
|
||||||
|
|
||||||
|
Close-out = **followup (optional but preferred) + set status to Solved.**
|
||||||
|
|
||||||
|
## GLPI status IDs
|
||||||
|
|
||||||
|
| ID | Status | |
|
||||||
|
| ----- | --------------------- | -------------------------------------------- |
|
||||||
|
| 1 | New | |
|
||||||
|
| 2 | Processing (assigned) | |
|
||||||
|
| 3 | Processing (planned) | |
|
||||||
|
| 4 | Pending / Waiting | |
|
||||||
|
| **5** | **Solved** | ← set this on close-out |
|
||||||
|
| 6 | Closed | ← happens automatically; do not set manually |
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
|
||||||
|
### 1. Get a session token
|
||||||
|
|
||||||
|
```bash
|
||||||
|
SESSION=$(~/.config/mosaic/tools/glpi/session-init.sh -q)
|
||||||
|
source ~/.config/mosaic/tools/_lib/credentials.sh && load_credentials glpi
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. (Preferred) Post the resolution followup
|
||||||
|
|
||||||
|
Use the **top-level `/ITILFollowup` endpoint** — the `/Ticket/<id>/ITILFollowup`
|
||||||
|
sub-resource returns permission errors even as Super-Admin (known GLPI quirk).
|
||||||
|
|
||||||
|
```bash
|
||||||
|
TICKET_ID=<id>
|
||||||
|
curl -sk -X POST "${GLPI_URL}/ITILFollowup" \
|
||||||
|
-H "App-Token: $GLPI_APP_TOKEN" \
|
||||||
|
-H "Session-Token: $SESSION" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d "{\"input\":{\"itemtype\":\"Ticket\",\"items_id\":${TICKET_ID},\"content\":\"<resolution summary>\"}}"
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Set status to Solved (the step that actually closes it out)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl -sk -X PUT "${GLPI_URL}/Ticket/${TICKET_ID}" \
|
||||||
|
-H "App-Token: $GLPI_APP_TOKEN" \
|
||||||
|
-H "Session-Token: $SESSION" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d "{\"input\":{\"id\":${TICKET_ID},\"status\":5}}"
|
||||||
|
```
|
||||||
|
|
||||||
|
Expect HTTP 200/201. GLPI will auto-close it later per its config — leave status at 5.
|
||||||
|
|
||||||
|
### 4. Verify
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl -sk "${GLPI_URL}/Ticket/${TICKET_ID}?expand_dropdowns=true" \
|
||||||
|
-H "App-Token: $GLPI_APP_TOKEN" -H "Session-Token: $SESSION" \
|
||||||
|
| jq '{id, name, status}'
|
||||||
|
```
|
||||||
|
|
||||||
|
`status` should read `Solved` (or `5`).
|
||||||
|
|
||||||
|
## Optional: sweep for done-but-open tickets
|
||||||
|
|
||||||
|
List tickets still open (New/Processing/Pending) to spot ones whose work is actually
|
||||||
|
finished but were never marked Solved:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
~/.config/mosaic/tools/glpi/ticket-list.sh -s processing -f table
|
||||||
|
~/.config/mosaic/tools/glpi/ticket-list.sh -s pending -f table
|
||||||
|
```
|
||||||
|
|
||||||
|
Review each; for any that are genuinely resolved, run steps 2–3.
|
||||||
|
|
||||||
|
## Guardrails
|
||||||
|
|
||||||
|
- Read-only until you intend to close — confirm the ticket is actually done first.
|
||||||
|
- Never echo the GLPI app/user/session tokens.
|
||||||
|
- Set **Solved (5)**, never Closed (6) — auto-close owns that transition.
|
||||||
62
skills/glpi-sweep/SKILL.md
Normal file
62
skills/glpi-sweep/SKILL.md
Normal file
@@ -0,0 +1,62 @@
|
|||||||
|
# Skill: glpi-sweep — Find Done-But-Open Tickets
|
||||||
|
|
||||||
|
> Read-only sweep for tickets that are finished in reality but still sitting open in
|
||||||
|
> GLPI (never moved to Solved). Surfaces the exact miss an operator caught on 2026-07-20
|
||||||
|
> (a real incident where an affected ticket had resolution followups posted but was left
|
||||||
|
> open). For each one that's genuinely done, close it out with **[[glpi-solve]]**.
|
||||||
|
|
||||||
|
## When to use
|
||||||
|
|
||||||
|
- Periodic hygiene pass (e.g. before a weekly update or month-end).
|
||||||
|
- After a burst of ticket work, to catch any you resolved-in-followup but never Solved.
|
||||||
|
|
||||||
|
## Why this exists
|
||||||
|
|
||||||
|
Posting an `/ITILFollowup` documents work but does **not** change status. Tickets only
|
||||||
|
auto-close once set to **Solved (status 5)**. Anything left at New/Processing/Pending
|
||||||
|
stays open indefinitely. This sweep finds those.
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
|
||||||
|
### 1. List still-open tickets by status
|
||||||
|
|
||||||
|
```bash
|
||||||
|
GLPI=~/.config/mosaic/tools/glpi
|
||||||
|
"$GLPI/ticket-list.sh" -s new -f table
|
||||||
|
"$GLPI/ticket-list.sh" -s processing -f table
|
||||||
|
"$GLPI/ticket-list.sh" -s pending -f table
|
||||||
|
```
|
||||||
|
|
||||||
|
(GLPI status IDs: 1 New · 2/3 Processing · 4 Pending · 5 Solved · 6 Closed.)
|
||||||
|
|
||||||
|
### 2. Triage
|
||||||
|
|
||||||
|
For each open ticket, judge whether the underlying work is actually finished — check
|
||||||
|
its latest followups and cross-reference brain tasks / recent work. Read-only here;
|
||||||
|
change nothing yet.
|
||||||
|
|
||||||
|
Reasonable "probably done" signals:
|
||||||
|
|
||||||
|
- A resolution/root-cause followup already posted, but status never advanced.
|
||||||
|
- The related brain task is `done`, or the fix shipped and was confirmed.
|
||||||
|
- Requester confirmed resolution but the ticket was never Solved.
|
||||||
|
|
||||||
|
### 3. Present the candidates
|
||||||
|
|
||||||
|
List them for review before touching anything — never bulk-solve blindly:
|
||||||
|
|
||||||
|
```
|
||||||
|
Open tickets that look resolved:
|
||||||
|
- #<id> "<title>" — <why it looks done> → glpi-solve?
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. Close out the confirmed ones
|
||||||
|
|
||||||
|
For each ticket the user (or clear evidence) confirms is done, run **[[glpi-solve]]**
|
||||||
|
(optionally **[[glpi-followup]]** first if a closing note is warranted).
|
||||||
|
|
||||||
|
## Guardrails
|
||||||
|
|
||||||
|
- Read-only until a ticket is confirmed done — do not auto-solve on a guess.
|
||||||
|
- Never echo GLPI tokens.
|
||||||
|
- Set **Solved (5)**, never Closed (6) — GLPI auto-close owns that transition.
|
||||||
Reference in New Issue
Block a user