feat(meetings): read the user's calendar over CalDAV, Google and Microsoft 365

[kaizawa97]

Problem / Motivation

Meetings had to be created by hand. The app never knew what was already scheduled,
so the whole point of a meetings assistant — being ready for the meeting that is
about to start — was left to the user to arrange manually every time.

There was no way to connect a calendar at all: no provider, no credential store,
and no OAuth handshake for the two providers that require one.

Why it matters

Every downstream feature is gated on knowing the schedule. Without it the app
cannot pre-create a meeting, cannot name it, cannot attach the right attendees, and
cannot start on time — the user has to notice the meeting themselves and set it up
by hand, which is exactly the work they wanted delegated.

It also blocks the calendar UI, which is a separate PR: there is nothing for it to
render until a provider exists.

What changed (motivation → approach → change)

Goal. Read the user's calendar from wherever it already lives, without
becoming three separate integrations.

Approach. One CalendarProvider interface with three implementations — CalDAV,
Google Calendar, Microsoft 365 — plus the two pieces they need and did not have: a
credential store and an OAuth handshake. NoCalendarProvider keeps "not
configured" a normal case rather than a branch at every call site.

This PR is backend only. There is no UI change, so no Screenshots section.

The security decisions, because they shaped the code

Credentials sit outside the agent-reachable tree. They live under
<crew-home>/workspace/meetings/, not app_data_dir("meetings"). That data dir is
the region store.contain bounds agent-supplied paths against, and a calendar
refresh token survives until revoked — an agent that could read the file would keep
reading the user's schedule long after the session ended. Keeping it outside removes
the reachability question instead of answering it. security.py gains the path to
its denylist, generated for both crew-home prefixes so a migration fallback to the
legacy data-home is covered too.

The address vet is link_unfurl.vet_unfurl_url, reused rather than
reimplemented. This is the part worth reviewing closely, because it started as a
purpose-built check in calendar.py and that was a mistake. A calendar URL is
operator-supplied and fetched server-side, so this endpoint is an SSRF surface; a
second copy of the vetting logic is a second place to fix a bypass. The local copy
was also already weaker in four concrete ways:

input	the local copy	why
0177.0.0.1	approved, then fetched at 177.0.0.1	ipaddress will not read the octal, so it fell through to DNS and getaddrinfo read 0177 as decimal. The vet and the connection disagreed about the target — the exact class of bug the pinning exists to prevent.
100.64.0.1	approved	is_private does not cover CGNAT; only is_global does. On a machine on a tailnet, that range is the private network.
fec0::1	approved	Deprecated IPv6 site-local reports is_global.
.local, .onion	approved	Resolve through a side channel, or not at all.

link_unfurl also owns test_vet_rejects_every_special_purpose_range, which pins
the refusal set against a table of IANA special-purpose prefixes — so the next gap
is found by the suite instead of by a reviewer. A second implementation here would
not have inherited that.

One refusal went the other way and is kept, layered on top. A resolved address
that ipaddress cannot read is refused, not skipped. _reject_if_internal_ip
returns silently for a non-literal, because to it a non-literal is a hostname still
to be resolved; here the list is already a resolution result, so an unreadable entry
would reach the pin unchecked.

The pin, the redirect hop loop and the same-origin check stay local, and are not
duplication. VettedUrl's own docstring says to pin the resolver on wire_host
— this is the caller side of that contract. resolve is injected for one reason:
to keep every address the vet approved, since VettedUrl reports one and a
multi-homed calendar host should keep its fallbacks. Every address kept is one the
vet checked; it vets the whole answer, not just the address it returns.

Ports narrow to 80/443, which https-only leaves as 443. Stricter than "whatever
port the URL names", deliberately: a calendar on another port is nearly always an
internal service, and the port is the cheapest place to stop this endpoint being
used to probe for one. Nothing is broken by starting strict — this feature has never
shipped — and relaxing it later is one line.

XML parsing uses defusedxml with forbid_dtd=True. The stdlib
ElementTree expands internal entities while refusing external ones, and
XMLParser.doctype is ignored on 3.12, so hand-rolled stdlib hardening is not
a reliable option (and the SAST gate python.lang.security.use-defused-xml
fails the build on stdlib xml.etree anyway). defusedxml is declared in
setup.cfg — not a new runtime requirement in practice: doc_parser has
imported it since before this PR and the install only ever got it
transitively; this entry declares the dependency the tree already had.

Redaction is applied once, in build_event(), rather than per provider. A new
provider then cannot forget it, and security_posture.py gains one sink instead of
three.

The OAuth redirect URI is derived from the request's own origin. Dashboard auth
is an HMAC-signed cookie scoped to the host, and the port is configurable — a
constant would break on any non-default port, and localhost vs 127.0.0.1 would
not share the cookie.

Tests

Three files, ~1,800 lines of tests for ~1,700 lines of source.

• test_meetings_providers.py — ICS parsing (escapes, TZID, DURATION, recurrence
  windows), the address vet, and the pin. TestDnsRebindingIsRefused stands up a
  real loopback server on two families and asserts the fetch lands on the vetted
  address rather than a rebound one; it lifts exactly two refusals (the
  private-address rule, since 127.0.0.1 is the test server, and the 80/443 port
  rule, since it binds ephemeral) and runs everything else — resolution, the
  all-or-nothing check, the pin, the connector, the hop loop — for real.
• test_meetings_oauth.py — the handshake: state, redirect-URI derivation, token
  exchange and refresh, and that a failure does not strand a half-written credential.
• test_meetings_calendar_routes.py — the HTTP surface, including that a
  provider error is a 4xx with a message rather than a 500.

Non-vacuous on the part that matters: reverting the delegation and restoring the
local vet fails by name on 0177.0.0.1, 100.64.0.0/10 and fec0::/10.

Manual verification

The address vet was checked against the live code rather than only through the
suite — the four rows in the table above were run through _normalize_url before
and after the change, confirming each was approved before and is refused now, and
that a public host still resolves and pins normally (4 addresses, port 443) with
webcal:// rewritten to https://.

OAuth against live Google / Microsoft tenants is not verified here: it needs
registered client credentials for each, which this branch does not carry. The
handshake is covered by unit tests at the protocol level, and the redirect-URI
derivation — the piece most likely to be wrong in a real deployment — is tested
against non-default ports and both loopback spellings.

Related Issues

N/A — part of bringing the meetings app's calendar support up, not from a filed
issue.

Checklist

• Single commit with a Conventional Commits title
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable) — N/A: the user-facing calendar docs
  land with the UI PR, which is what a user will actually configure
• No secrets, credentials, or internal references in the diff

[github-actions]

Design Review (Fable 5, fork) — 🔴 BLOCK (blocking)

Design-level review of ca08283fac21c300d3997fb4d318e96113c246a0 via the fork AI-review pipeline — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

All key checks are done. I have what I need for the verdict: the diff adds workspace/meetings to _CREW_SECRET_LEAVES (tool gate) but never touches sandbox.py, whose hand-maintained disposition lists are what the reconciliation pin test (test_every_crew_sensitive_path_is_masked_sealed_or_a_declared_exception) checks against — so the new credential directory has no OS-level fence, and the repo's own keystone doc names the OS layer as the enforcement point. The meetings spec is also untouched despite documenting exactly what this PR changes.

Design-Verdict: BLOCK

The credential store's OS-sandbox half is missing: the refresh token is fenced only at the tool gate, which spawned shells never route through.

Blockers

The new secret leaf has no sandbox disposition, so a spawned shell reads the live tokens in every mode.
The diff adds "workspace/meetings" to _CREW_SECRET_LEAVES in src/kiro_crew/security/paths.py but never touches sandbox.py, whose hand-maintained _CREW_HIDDEN_LEAVES/_CREW_READONLY_LEAVES/_CREW_SANDBOX_VISIBLE_LEAVES are the OS enforcement point ("The enforcement point is the OS layer in sandbox.py, not a text matcher" — AGENTS.md). Result: cat ~/.kiro/crew/workspace/meetings/calendar-credentials.json works from any sandboxed agent shell in every mode, defeating the PR's own headline claim ("Keeping it outside removes the reachability question"), and test_sandbox_governance_mask.py::TestTheReconciliationIsComplete should fail on POSIX with workspace/meetings unaccounted — contradicting the checklist's "existing tests pass."
Fix: add workspace/meetings to _CREW_HIDDEN_LEAVES (dir and files lists — the gateway is its only reader, the inbound-spool pattern) and to the mask test's MASKED table.
Clears when: sandbox.py carries a HIDDEN disposition for workspace/meetings and test_sandbox_governance_mask.py passes on POSIX with the leaf in its MASKED table.

Watch

docs/system-specs/modules/meetings.md still says "Shipped: none and ics", omits the five new routes and the credential file; security.md covers the paths.py change. AGENTS.md requires spec updates in the same commit — the checklist's "docs N/A" covers only the user-facing UI docs.
Clears when: meetings.md (route table, provider seam, data layout) and the security spec are updated in this PR.

This is the product's first Kiro-Crew-custodied OAuth chain, while connections.md states "Kiro Crew never holds a connection's credential — kiro-cli owns the OAuth chain end to end." The app-backend scoping is defensible (the poller syncs without an agent session), but the alternative was never weighed in writing, and the next app needing OAuth will copy or import this one.
Clears when: the custody decision (why calendar OAuth bypasses kiro-cli/connections) is recorded in the meetings or connections spec.

Suggestions

The two-way function-local import cycle between oauth.py and providers/calendar.py says fetch_vetted wants its own module inside the app backend; extracting it dissolves the cycle without new surface.

[DESIGN-REVIEWED] ca08283

[github-actions]

GPT 5.6 Review (fork) — 🔴 changes requested (blocking)

Reviewed ca08283fac21c300d3997fb4d318e96113c246a0 via the fork AI-review pipeline; updated in place on each push.

2 of 2 blocking finding(s) are security-class and were withheld from adjudication, so the blocking verdict stands.

BLOCKING -- src/kiro_crew/security/paths.py:296 -- Calendar credentials remain readable to agent subprocesses
"workspace/meetings",
Stored credentials -> agent shell opens the unfenced path -> calendar passwords and OAuth tokens are exposed.
Anchor: backend-security-controls
Fix: Add this directory to the sandbox hidden and precreated-hidden leaf sets.

BLOCKING -- src/kiro_crew/apps/builtins/meetings/backend/providers/calendar.py:1565 -- Cloud providers discard all-day semantics
uid_prefix=k.CALENDAR_PROVIDER_GOOGLE, / uid_prefix=k.CALENDAR_PROVIDER_MICROSOFT,
Date-only or isAllDay event -> build_event defaults all_day=False -> wrong-date rendering and erroneous persisted meeting pre-creation.
Anchor: residual/crash-data-loss-corruption
Fix: Derive and pass each provider’s all-day flag to build_event.

FINDING -- src/kiro_crew/apps/builtins/meetings/backend/providers/calendar.py:10 -- "Three implementations ship" contradicts the five registered factories -> Fix: Say five and include Google and Microsoft.

FINDING -- src/kiro_crew/apps/builtins/meetings/backend/credentials.py:183 -- "rewritten wholesale on the next write" contradicts _load_sync refusing every write while unreadable -> Fix: State that manual repair or replacement is required.

[BLOCK-MERGE] ca08283
[GPT-REVIEWED] ca08283

Adjudication (Opus 4.8) — is blocking on each finding proportionate?

Both fenced findings verified. F1: the diff adds workspace/meetings to security._CREW_SECRET_LEAVES (paths.py:199+, the agent-tool gate) but does not touch sandbox._CREW_HIDDEN_LEAVES (sandbox.py:192) — the OS-layer mask a spawned shell's open() actually hits. A credential file holding a CalDAV password and Google/M365 refresh+access tokens fenced only at the tool gate is readable by any agent shell (cat ~/.kiro/crew/workspace/meetings/calendar-credentials.json), the exact keystone bypass CLAUDE.md warns of. Credential/token exposure = unbounded; the reaching condition (default command tools + a stored calendar credential) is ordinary, not extreme, so no FLAG rarity record can be completed.

F2: _google_events/_graph_events call build_event(...) without all_day (calendar.py, defaults all_day=False at build_event signature), while _google_when maps a date-only {"date": ...} event to a midnight-UTC datetime — so an all-day event loses its flag and renders/pre-creates at a wrong time. All-day events are a common calendar input, not an extreme or writer-impossible one, so the FLAG rarity record cannot be completed.

F1 conditions: paths.py:199 (_CREW_SECRET_LEAVES gains workspace/meetings), sandbox.py:192 (_CREW_HIDDEN_LEAVES lacks it); recovery: none — a refresh token survives until revoked.
F2 conditions: calendar.py build_event all_day defaults False, _google_when returns a datetime for date-only events with no all-day propagation; recovery: next sync repeats the same wrong reading.

[ADJUDICATION] ca08283fac21c300d3997fb4d318e96113c246a0 total=0 uphold=0 downgrade=0
[GPT-ADJUDICATED] ca08283fac21c300d3997fb4d318e96113c246a0

[ADJUDICATION-FENCED] ca08283fac21c300d3997fb4d318e96113c246a0 fenced=2 flagged=0
UPHOLD-FENCED F1 src/kiro_crew/security/paths.py:296 -- Credential file fenced only at the tool gate, not the OS sandbox mask, so any agent shell can read live calendar tokens; reaching conditions are ordinary, not extreme.
UPHOLD-FENCED F2 src/kiro_crew/apps/builtins/meetings/backend/providers/calendar.py:1565 -- All-day cloud events lose their flag and render/pre-create at a wrong time; all-day events are a common input, so no rarity argument clears it.
[GPT-ADJUDICATED-FENCED] ca08283fac21c300d3997fb4d318e96113c246a0

[github-actions]

Opus 4.8 Review (fork) — ✅ no blocking findings

Reviewed ca08283fac21c300d3997fb4d318e96113c246a0 via the fork AI-review pipeline; updated in place on each push.

Review details

No findings that block; one advisory.

FINDING — src/kiro_crew/apps/builtins/meetings/backend/oauth.py:743 — _post_token calls fetch_vetted(client.token_url, …) with the default ok_statuses=frozenset({200}), so a token-endpoint error (RFC 6749 §5.2 mandates HTTP 400; Google/Microsoft both use it for invalid_grant on a revoked/expired refresh token) is raised as the generic "calendar URL returned HTTP {resp.status}" inside fetch_vetted before _post_token ever reaches parsed.get("error"), so the intended "the calendar provider refused the authorization: {detail}" message is unreachable for real providers and a revoked connection surfaces as an undiagnosable "HTTP 400" → Fix: pass ok_statuses=frozenset({200, 400}) to the fetch_vetted call in _post_token so the JSON error body is parsed and error_description surfaced.

[OPUS-REVIEWED] ca08283

[bolichen97]

🤖 Kiro Crew [operator: bolichen97]: This PR has been inactive for 7+ days with failing CI. I've assessed the blockers and they appear resolvable — I'll push fixes directly to this branch as a co-author.

Assessment: GPT 5.6 flagged 3 concrete bugs (credential temp-file path gate bypass, concurrent-write race in credentials store, read-failure causing credential loss). The only CI test failure (test_subagent_scale.py::TestWaveDigest) is a pre-existing main flake unrelated to this PR. Fix plan: address the 3 GPT BLOCKING findings, rebase onto latest main, re-run CI.

If you'd prefer I don't touch this PR, add the pr-no-autofix label.

[bolichen97]

🤖 Kiro Crew [operator: bolichen97]

Drive-to-green pass on this PR (original work by @kaizawa97, authorship preserved; head is now 269e4a107):

1. Rebased onto current main (was based on a commit from 08-13). This also absorbs the fix for the test_subagent_scale.py wave-digest flake (#3281) that failed Backend Tests shards 3.10/4 and 3.12/4 on the previous head — those failures were a pre-existing main flake, not this PR.

2. Re: the GPT 5.6 blocking review of 7035762d — that review predates the author's own amend (5d221090, pushed 09:17 UTC the same morning), which already addressed the findings: the sensitive-path gate covers the whole workspace/meetings directory (UUID temp siblings included), the credential read-modify-write is serialized under _STORE_LOCK, and unreadable-store reads raise _StoreUnreadable on the write path instead of silently rebuilding from {}. Stage-1 CI failing on the flake meant no review bot ever re-ran on that head.

3. One new fix (local GPT 5.6 review of the rebased head): the invalid/expired/forged-state rejection in handle_oauth_callback returned early without a SEL audit record — the one exit path of that handler that didn't audit, and it is precisely the anti-forgery check firing. Added audit("meetings.calendar_oauth_callback", "unknown", outcome="error", error="invalid_or_expired_state") before the return, and extended test_a_forged_callback_with_no_flow_is_refused to lock the record in. Only constant strings are logged — no query-string input is echoed into the audit trail.

4. PR description updated to remove the stale claim that defusedxml was avoided — the code (correctly) uses defusedxml with forbid_dtd=True and declares it in setup.cfg; the description now matches.

Local gates on the pushed head: isort / flake8 / mypy clean, full pytest 56380 passed. Opus 4.8 local review: NO-BLOCKING (SSRF vetting, redirect auth-drop, gate coverage, and Graph timezone handling all verified sound).

[bolichen97]

🤖 Kiro Crew [operator: bolichen97] — dispositions for the GPT 5.6 blocking review of 7035762d (superseded by the author's amend 5d221090 and the rebase 269e4a107):

• Credential temp files bypass the sensitive-path gate (security.py) — fixed

The denylist entry is now the directory workspace/meetings (not the exact leaf), and _path_in_home_dirs prefix-matches children, so calendar-credentials.json.<uuid>.tmp siblings are denied. Locked in by the gate's directory-matching semantics shared with trust/profiles.

• Concurrent credential PUT vs OAuth refresh lost-update (credentials.py) — fixed

Both write_for and clear_for run their whole read-modify-write under the module-level _STORE_LOCK (threading.Lock, correct for asyncio.to_thread workers).

• except (OSError, ValueError): return {} erases credentials on corruption (credentials.py) — fixed

The write path calls _load_sync, which raises _StoreUnreadable on any read/parse failure other than FileNotFoundError; only the display path (_read_sync) degrades to empty, so a merge never rebuilds the file from a partial view.

• New in 269e4a107 — the invalid-state OAuth callback rejection now writes a SEL audit record (fixed a local-review finding of the same class; see the drive-to-green comment above).

[bolichen97]

🤖 Kiro Crew [operator: bolichen97]

Push 9 (4d8c8a4b0): zero-diff re-trigger. Identical tree to 587940df9 (verified git diff --stat = 0 lines); pushed solely so the review pipeline runs a fresh round against the adjudication ledger, which now carries the Graph-timezone disposition (rebuttal + scope fold into #4328). No code change to review beyond the prior head.

[iamwhatever]

🤖 Kiro Crew [operator: iamwhatever]: adopting this PR for drive-to-green (prior operator claim is 12 days stale). Plan: rebase onto current main to clear the merge conflict (the sole change since the zero-diff retrigger 4d8c8a4b0), re-run local gates, and force-push to get a fresh CI + review round. No design or scope changes — the author's diff and the existing disposition ledger (incl. the round-6 rebuttal → #4328) are preserved.

[iamwhatever]

🤖 Kiro Crew [operator: iamwhatever]

Push 10 (11cd535fe): rebase onto current main (1600+ commits) with conflict reconciliation. The branch had gone CONFLICTING because three meetings fixes landed on main after the last rebase, all touching this PR's files. Changes beyond the mechanical rebase, each the minimal integration of a main-side fix:

1. All-day events (fix(meetings): render all-day calendar events date-only (#4328) #4380 on main): main's _finalize_event gained all_day support while this PR routes all providers through its build_event funnel. Resolution: the flag is threaded through build_event (new all_day: bool = False parameter), so .ics all-day events keep main's date-only semantics through this PR's funnel. No provider behavior change otherwise.
2. Windows TZID mapping (fix(meetings): map Windows/CLDR TZID names to IANA in the .ics parser (#5556) #5557 on main): main landed a _WINDOWS_TO_IANA table in this same file — which is exactly what the outstanding GPT round-6 BLOCK-MERGE finding (Tokyo Standard Time read as UTC → 9-hour shift in _graph_when) called for. The rebuttal had deferred it as new capability; it is now a one-table reuse, so it's fixed in-PR: _graph_when consults the table before the UTC fallback. Tests updated — the old test_a_windows_zone_name_falls_back_to_utc (which pinned the wrong-hour behavior) is replaced by test_a_windows_zone_name_maps_to_iana plus test_an_unknown_zone_name_falls_back_to_utc.
3. Variable-leaf gate interaction (new on main via feat: run local speech-to-text on a resident whisper.cpp recogniser #6232-era test_security.py): this PR's workspace/meetings credential entry put .kiro/crew/workspace into _SENSITIVE_LEAF_PARENT_DIRS, fencing every variable leaf under the crew workspace and breaking main's pinned cat ~/.kiro/crew/workspace/$PROJ/notes.md. Fixed per the documented .config/.config/gcloud precedent: the workspace parent is added to _GENERAL_PURPOSE_PARENT_DIRS; workspace/meetings itself (and children, and the .tmp sibling) remain fully fenced by is_sensitive_path — verified by direct probe and the security suite.

Local gates all green: 1622 meetings+security tests, isort, flake8, mypy (1209 files), baselined black gate. Single commit, author @kaizawa97 preserved, Co-authored-by: Kiro Crew trailer. The GPT round-6 disposition ledger stands; finding is now fixed rather than deferred.

[iamwhatever]

🤖 Kiro Crew [operator: iamwhatever] — disposition for the GPT 5.6 review of 11cd535fe (new head 0b463a10c):

• security.py:7501 — workspace exclusion bypasses credential protection (span=3c5b15a2d41e) — rebutted (pre-existing adjudicated posture; the demanded fix breaks main's own pinned test)

Three grounds, each verified empirically on this head:

1. The flagged shape is the gate's pre-existing, deliberate posture — not a regression this PR introduces. _GENERAL_PURPOSE_PARENT_DIRS exists on main precisely to exempt general-purpose directories whose only sensitive content is a specific child, and its own docstring names the identical trade for .config/.config/gcloud. Probed both side by side on this head: cd ~/.config; cat */credentials.db → allowed (main's shipped posture for gcloud credentials), cd ~/.kiro/crew/workspace; cat */calendar-credentials.json → allowed (same posture, same mechanism). The direct spellings stay blocked: cat ~/.kiro/crew/workspace/meetings/calendar-credentials.json → BLOCKED, cd ~/.kiro/crew/workspace/meetings; cat calendar-credentials.json → BLOCKED.
2. The prescribed fix ("remove the workspace exclusion") reds main's own suite. test_security.py::TestKeystoneVariableLeafNativeSpellings::test_benign_variable_leaves_are_still_allowed pins cat ~/.kiro/crew/workspace/$PROJ/notes.md as allowed — the crew workspace holds the user's notes, memory and project files, and main added that pin specifically so leaf-parent fencing does not taint the whole workspace. Without the exclusion that test fails (verified: that exact failure is what the exclusion was added to fix after rebase).
3. Directory-move taint was never the credential store's protection. The entry's documented threat model is agent file tools and direct path naming, both of which is_sensitive_path still refuses for workspace/meetings and every child, including the atomic_write .tmp sibling. Widening glob/cd-taint semantics for ALL general-purpose parents is a gate-wide design question that belongs to main's _GENERAL_PURPOSE_PARENT_DIRS design, not to this PR.

[iamwhatever]

🤖 Kiro Crew [operator: iamwhatever] — disposition for the First Principles BLOCK on 11cd535fe:

• setup.cfg re-declares defusedxml (duplicate of base line 67, conflicting ceiling) — fixed in 0b463a10c

The finding is correct: main gained its own defusedxml>=0.7,<1 declaration in install_requires after this branch was written, so the rebase carried a duplicate with a narrower <0.8 ceiling. The entire setup.cfg hunk is dropped — the file now matches origin/main byte-for-byte. test_pip_deps_consistency.py (all 9, including the unguarded-imports check) passes: the PR's defusedxml imports are covered by main's existing declaration.

[iamwhatever]

🤖 Kiro Crew [operator: iamwhatever] — status on head 0b463a10c

All remaining CI reds are main-side breakage inherited via the CI merge-ref, not this PR's code:

• test_agent_spec_hardened_reads.py::TestResolveMcpServer::test_valid_agent_spec_still_resolves_under_the_same_cap (Backend 3.10/3.12 shard 1, Windows shard 1) — fails byte-identically on pristine origin/main tip (reproduced locally) and on main's own latest CI run (734d8fd36). Broken by main's fix(agents): route six kirocrew.json reads through the hardened spec reader #7048/533414c8d hardened-reader change (resolver now returns (argv, env)); fixes already open as test(cron): pin the env half of the post-#2602 resolver contract #7176 / fix(test): assert the post-#2602 _resolve_mcp_server shape #7179.
• test_resource_limits_schema.py::TestCgroupConsumerUnchanged::test_the_scope_argv_never_carries_a_zero_ceiling (Windows shard 3) — same failure on main's own run.
• Coverage Gate — downstream of the failed shards.

This PR's own surface is green: all 1622 meetings+security tests, isort/flake8/mypy/baselined-black pass locally on this head. Review lanes gate on workflow_run.conclusion == 'success', so GPT/Opus/Design/UX/First-Principles stay pinned to the prior round until main heals. Watching #7176/#7179; will re-run the failed jobs once a fix merges (the merge-ref picks up main's tip at run time — no rebase needed).

[bolichen97]

Open PR relationship audit

This is a consolidated, point-in-time code-level audit note. It compares complete merge-base diffs and current/merged code; it does not treat a shared topic as duplication or partial coverage as completion.

Relationship findings

• This PR is OVERLAPPING with PR #8080. The goals differ or the implementations can complement each other; this is not a duplicate claim. Recommended action for PR #2190: REBASE. A merged PR refactored the one function 2190 also touches, which is what the 'merge conflict' label reflects. The conflict is mechanical and confined to one import list; nothing in 8080 implements any of 2190's behaviour. Files: src/kiro_crew/apps/builtins/meetings/backend/routes/calendar.py.
• This PR is OVERLAPPING with PR #8081. The goals differ or the implementations can complement each other; this is not a duplicate claim. Recommended action for PR #2190: REBASE. 8081 contains this PR verbatim, but as the dependent half of an author-declared stack: 2190 is the base. Closing 2190 in favour of 8081 would only be right if the two are collapsed into one PR — and 8081 carries the same routes/calendar.py conflict with merged PR #8080, so collapsing removes no rebase work. Keep 2190 as the landing unit and let 8081 rebase onto main afterwards. Files: src/kiro_crew/apps/builtins/meetings/backend/credentials.py, src/kiro_crew/apps/builtins/meetings/backend/routes/calendar.py. The two independent directions used different labels; the matrix conservatively retains OVERLAPPING for coordination.

No PR, Issue, label, branch, or review state was changed by the relationship-note portion of this audit.

[bolichen97]

Rebased onto main 6c24f116e by a maintainer as part of the 2026-09-08 open-PR audit (was 1089 commits behind, mergeable_state: dirty). Now one commit on current main.

Conflicts and how they were resolved:

• src/kiro_crew/security.py (modify/delete): refactor(security): split security.py into a package and drop path regex #9183 split it into a package, so the workspace/meetings denylist entry and its comment moved verbatim into src/kiro_crew/security/paths.py, placed after main's new aws-control-staging entry. The _GENERAL_PURPOSE_PARENT_DIRS hunk was dropped: main deleted that symbol and the whole taint mechanism it exempted, so there is nothing left to exempt from.
• routes/calendar.py: took main's feat(meetings): poll the calendar and pre-create the meeting about to start #8080 calendar_sync.sync_calendar delegation in handle_calendar_sync, kept all of this PR's credentials and OAuth code on top.
• routes/__init__.py: kept main's poller, audio-import and editable-minutes wiring, added only this PR's 6 calendar credential/OAuth route registrations. Reformatted that block for main's line-length = 100.

Gates run locally on the changed files: black, isort, flake8 all clean (the 3 remaining black complaints are pre-existing .github/black-baseline.txt entries that also fail on main). pytest green: 508 in the 4 meetings test files, 1337 in test/test_security*.py.

Please review the resolution, especially the denylist relocation. A maintainer push makes the maintainer the last pusher, so under this repo's last-push rule a second approver is needed. Reply here if anything looks wrong.