| name | ticket-access-and-secrets |
| description | Use when CTOX needs credentials, access rights, or approval boundaries for ticket work and must handle them through encrypted local storage plus explicit access requests. |
| metadata | {"short-description":"Request rights and store secrets safely for ticket work"} |
| cluster | ticket_integration |
Ticket Access And Secrets
CTOX Runtime Contract
- Task spawning is allowed only for real bounded work steps that add mission progress, external waiting, recovery, or explicit decomposition. Do not spawn work merely because review feedback exists.
- The Review Gate is a quality checkpoint, not a control loop. After review feedback, continue the same main work item whenever possible and incorporate the feedback there.
- Do not create review-driven internal work cascades. If more work is needed, reuse or requeue the existing parent work item; create a new task only when it is a distinct bounded work step with a stable parent pointer.
- Every durable follow-up, queue item, plan emission, or internal work item must have a clear parent/anchor: message key, work id, thread key, ticket/case id, or plan step. Missing ancestry is a harness bug, not acceptable ambiguity.
- Rewording-only feedback means revise wording on the same artifact. Substantive feedback means add new evidence or implementation progress. Stale feedback means refresh or consolidate current runtime state before drafting again.
- Before adding follow-up work, check for existing matching internal work, queue, plan, or ticket state and consolidate rather than duplicating.
Use this skill when ticket handling is blocked on missing credentials, missing permissions, or unclear approval boundaries.
Core Rules
CTOX may hold encrypted secret values through the dedicated secret store.
Ticket work and ticket knowledge may only hold references, scopes, channels, and rationale. They must never hold raw secret values.
The secret store and related runtime records are the durable source of truth. Workspace notes or copied credential instructions do not count as durable access knowledge by themselves.
Use the encrypted CTOX secret store and runtime store as the only durable authority for access state.
Commands
Inspect available secret metadata:
ctox secret list [--scope "<scope>"]
ctox secret show --scope "<scope>" --name "<name>"
Store a secret locally:
ctox secret put --scope "<scope>" --name "<name>" --value "<secret>" --description "<text>" --metadata-json '<json>'
Store a secret locally and immediately rewrite leaked memory references in one step:
ctox secret intake --scope "<scope>" --name "<name>" --value "<secret>" --description "<text>" --metadata-json '<json>' --db "<path-to-ctox.sqlite3>" --conversation-id "<id>" --match-text "<secret>" [--label "<human label>"]
Retrieve a secret only for explicit local execution:
ctox secret get --scope "<scope>" --name "<name>"
If a secret already leaked into the CTOX conversation memory, rewrite the LCM/continuity history to a stable keychain handle after storing the secret:
ctox secret memory-rewrite --db "<path-to-ctox.sqlite3>" --conversation-id "<id>" --scope "<scope>" --name "<name>" --match-text "<secret>" [--label "<human label>"]
Create an operator-visible access request in the ticket surface:
ctox ticket access-request-put --system "<system>" --title "<title>" --body "<text>" --required-scopes "<csv>" --secret-refs "<csv>" --channels "mail,jami" --publish
Operating Pattern
- Check whether the required secret or access grant already exists locally.
- If not, create an explicit access request with scopes, secret references, and the preferred contact channels.
- Once the operator supplies the secret, store it only through
ctox secret intake or ctox secret put.
- If the secret already entered CTOX memory, prefer
ctox secret intake so storage and memory rewrite happen as one visible operation.
- Refer back to the secret by scope and name in follow-up ticket work; do not paste the value into tickets or knowledge entries.
If the blocking access question belongs to an existing ticket case, anchor it with a ticket clarification request as well as any access-request/internal-work record:
ctox ticket clarification-request --case-id "<case_id>" --question "<exact safe request>" --target-type owner --target-channel tui --missing-inputs "<scope-or-secret-ref>"
Do not put raw secret values in the clarification request. Ask for a local secret-store intake path or approval, then resolve the clarification only after the secret reference exists in CTOX runtime state.
Important Boundaries
- Do not store raw secrets in ticket metadata.
- Do not request broad access when a narrower scope is sufficient.
- Do not treat operator silence as implied approval.
