[Bug] gemini-enterprise: access_start_day / access_end_day are documented as ISO-8601 (1=Mon, 7=Sun) but are substituted into a CEL getDayOfWeek() expression, which is 0-6 (0=Sunday)

[JohnHales]

Bug Description

gemini-stage-0/variables.tf:114-123 documents the day-of-week inputs as ISO-8601:

variable "access_start_day" {
  description = "The day of the week when access starts (1 for Monday, 7 for Sunday)."
  default     = 1
}
variable "access_end_day" {
  description = "The day of the week when access ends (1 for Monday, 7 for Sunday)."
  default     = 5
}

Those values are substituted verbatim into the time access level's CEL expression in gemini-stage-0/access_policy.tf:

request.time.getDayOfWeek("<tz>") >= <start> && request.time.getDayOfWeek("<tz>") <= <end>

CEL's getDayOfWeek() returns 0-6, not 1-7. The documented mapping is therefore wrong at both ends: getDayOfWeek() never returns 7, and the day the docs call Sunday is actually 0.

The defaults (1..5) happen to be correct for Monday-Friday under both readings, which is why the mismatch is invisible in the shipped configuration. It only surfaces when an operator follows the documentation at the boundary:

• Setting access_end_day = 7 to "include Sunday" matches nothing new — the expression tops out
  at 6 (Saturday) and Sunday (0) stays excluded.
• An operator wanting seven-day access will naturally write 1..7 and silently get six days,
  with no error and no plan diff to hint at it.

Environment and Deployment Context

• Stellar Engine Version/Commit: main at commit f64ce6cd (re-verified 2026-08-10)
• Deployment Type:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Medium
  • FedRAMP High
  • FedRAMP Moderate
  • DoD IL4
  • DoD IL5
  • Stand-alone / Custom
• FAST Stage (if applicable): N/A — this is a blueprint, not a FAST stage
  • Stage 0 (Bootstrap)
  • Stage 1 (Resource Management)
  • Stage 2 (Network Creation)
  • Stage 3 (Security and Audit)
• Affected Component:
  • blueprints/fedramp-high/gemini-enterprise/gemini-stage-0/variables.tf:114-123
  • blueprints/fedramp-high/gemini-enterprise/gemini-stage-0/access_policy.tf:44-52 (the time access level)
• Terraform Version: 1.12.2 (pinned by deploy.sh via tfenv; the stage declares required_version >= 1.7.4)
• GCP Provider Version: hashicorp/google >= 6.21.0 (stage-0 declared constraint)

Steps to Reproduce

1. Apply gemini-stage-0 with create_time_access = true and, following the variable descriptions, set access_start_day = 1 and access_end_day = 7 to mean "Monday through Sunday".
2. Read the generated access level: gcloud access-context-manager levels describe time --policy <access_policy_number>.
3. Compare the CEL expression's day bounds against the days access is actually granted on.

Expected Behavior

The documented mapping matches the expression that is generated. 7 means Sunday, and 1..7 grants access every day of the week.

Actual Behavior

The value is substituted verbatim into request.time.getDayOfWeek(...), which returns 0-6 with 0 = Sunday. >= 1 && <= 7 therefore grants Monday-Saturday and silently excludes Sunday, and a start day of 7 matches nothing at all because the function never returns 7.

Relevant Logs and Errors

No error is emitted — the expression is valid CEL and applies cleanly. That is what makes it dangerous: the access level silently covers fewer days than the operator asked for. The generated expression (from source inspection) reads:

request.time.getHours("America/New_York") >= 9 &&
request.time.getHours("America/New_York") <= 17 &&
request.time.getDayOfWeek("America/New_York") >= 1 &&
request.time.getDayOfWeek("America/New_York") <= 7

Suggested Fix

Correct both descriptions to the CEL convention (0 = Sunday … 6 = Saturday) and state that 0 through 6 is the full week. Optionally add a validation block rejecting values outside 0-6 so 7 fails fast instead of silently narrowing access.

Additional Context

Found while widening a FedRAMP-High deployment's access window from weekdays to seven days.