Files
2026-07-13 22:21:12 +08:00

2.6 KiB

ADDED Requirements

Requirement: User task-submission policy is durable and authoritative

The system SHALL persist an optional versioned submission policy for each human user, containing submission enablement and explicit Host/Device target allow-lists, and SHALL enforce that policy after scope authentication on every public task-submission request.

Scenario: Restricted user submits to an allowed Device

  • WHEN a principal with tasks:submit has a policy allowing a Host/Device target and submits a task for that exact target
  • THEN the system accepts the task subject to normal validation and records the authenticated principal as its submitter

Scenario: Restricted user omits or exceeds a target allow-list

  • WHEN a principal with a restrictive policy submits without a target or names a Host/Device outside its allow-list
  • THEN the system rejects the request before creating a task

Scenario: Submission is disabled

  • WHEN a principal with tasks:submit has a policy with submission disabled
  • THEN the system rejects task submission without changing the queue

Requirement: Host governance policy is versioned and enforceable

The system SHALL persist a monotonic revisioned policy for each Host with an optional active-task limit and optional UTC-day AI token budget, and SHALL enforce active-task limits during Cloud scheduling.

Scenario: Host active-task limit is reached

  • WHEN a Host already has its configured maximum number of assigned or dispatched attempts and another queued task targets that Host
  • THEN the scheduler leaves the later task queued until capacity becomes available

Scenario: Host policy is updated

  • WHEN an authorized governance administrator updates a Host policy
  • THEN the system stores a strictly newer revision and later Cloud authorization, scheduling, and proxy operations use the new policy

Requirement: Governance mutations and reads use dedicated scopes

The system SHALL protect governance policy and AI-usage operations with governance:read or governance:admin as appropriate, and SHALL record safe audits for policy mutations.

Scenario: Administrator changes a policy

  • WHEN a principal with governance:admin changes a user or Host policy
  • THEN the system records actor, target, old/new revision, timestamp, and non-secret policy metadata without recording credentials or request secrets

Scenario: Non-governance principal attempts a policy mutation

  • WHEN a principal lacking governance:admin updates a governance policy
  • THEN the system rejects the request before changing durable policy state