[pareilly]

What changes

When an authoring run needs a marker, dtwo-gateway-policy now asks the admin two questions before registering it, how long the restriction should last and whether the person can disable it early, and refuses to pick either on its own. It names each marker for what it restricts and why, writes the description as the first sentence of the deny reason, and registers one marker per restricted tool so a person can disable one safeguard while another stays in force.

dtwo-policy-rego's reader example now returns the three-part deny reason: what triggered the restriction, the time remaining, and whether the person can ask to have the safeguard disabled. A policy cannot read a marker's expiry, so the writer stamps marked_at and the reader derives the minutes left from it and the registered TTL. The disable offer is gated on the registry's clearable flag and on clearing being armed on the gateway. The running example is renamed from pii_detected to no_slack_after_pii to match the naming rule, and a "one trigger, several restrictions" writer snippet shows a trigger emitting one key per restriction.

The cleanup note is corrected: deleting a marker is now refused while a policy still references it.

Plugin version bumped to 1.3.2 (main moved to 1.3.1 while this was open; merged in twice).

How it was tested

• Every Rego block in the reader example parses under opa check --strict and was evaluated under both OPA 1.18 and the gateway's Regorus binding across the fresh / no-timestamp / two-writer / non-clearable / clearing-not-armed / empty-registry cases.
• Live, twice, against a local gateway with Echo and clearing armed. Run 1 (this branch's skills loaded directly): both questions asked, two markers, three policies, deny messages with a decreasing time remaining, and disabling one safeguard left the other in force. Run 2 (a fresh session with only the skill text): the deny message, naming and vocabulary were right, but the agent neither asked the TTL and clearability questions nor split the two tools into two markers. The wording for both rules was then moved to the point where the agent decides to use a marker and made blunter. Run 3 (a fresh session against the revised text): it asked the two questions before registering anything, proposed a TTL and waited for approval, registered two markers with restriction-first names and descriptions, wrote one trigger and two enforcement policies, and the deny messages carried the three parts. Disabling one safeguard restored only its tool; disabling the second restored the other.
• skill-harness: pnpm test (181 passing) and pnpm biome:check clean.

Review notes

• Public-surface check done: no internal hosts, issue refs or design-record names in the diff.

🤖 Generated with Claude Code

[nicobatalla]

Approving, codex found some issues, feel free to discard if not relevant:

[nicobatalla]

[P2] Preserve the write-time TTL when computing time remaining

If an admin changes both TTL settings from 3600 to 600 after a marker has existed for 15 minutes, this calculation reports "Time remaining: 0 minutes" even though the restriction lasts another 45 minutes. The gateway stores expiry when each write lands; deploying a new registry TTL does not update existing records. Keeping the registry and writer schema synchronized therefore does not prevent this mismatch. Could the countdown use per-write TTL or expiry metadata instead of the current registry setting? Enforcement still works; the displayed time is incorrect.

[pareilly]

The diagnosis is right: the countdown uses the registry TTL in force at evaluation time, and a marker written before a TTL change keeps its original expiry, so its displayed figure is off by the difference until it re-stamps or expires. Enforcement is unaffected. There is no policy-side fix, because the session view a policy sees carries values only, not per-key expiry, which is why the time is derived at all; stamping an expires_at in the writer would add a third number to keep in sync for a case that only arises when an admin changes a TTL mid-session. We're leaving it as is for now and will revisit if it shows up in practice.

[nicobatalla]

[P2] Validate marker values before extracting timestamps

For a marker whose writer declares a boolean schema and emits true, which the validators permit, object.get throws in Regorus instead of using the no-timestamp fallback. Evaluating the new reader's reason reproduces this error, whereas the previous presence-only reader supported that value. Could this guard extraction with is_object(v) and validate that the timestamp is numeric before doing arithmetic, so existing marker shapes retain the promised fallback?

[pareilly]

Agreed, and fixed in 0992de0: the comprehension now checks is_object(v) and is_number(t) before the arithmetic, so a bare flag or a non-numeric marked_at gets the no-timestamp fallback sentence. Checked under OPA 1.18 strict and Regorus with true, a bare string, a string marked_at, a null marked_at and a valid timestamp: the first four fall back, the last gives the minutes.