morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #7004] feat(doctor): report the configured workflow beside an audit-wide result #7566

New issue

Open

opened 2026-11-03 13:38:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 13:38:45 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/7004
Author: @akshatgg
Created: 10/24/2026
Status: 🔄 Open

Base: main ← Head: fix/doctor-audit-scope-hint

📝 Commits (8)

d129a05 feat(doctor): report the configured workflow beside an audit-wide result
e7aebf3 fix(doctor): judge the configured skill from the configured clients' copies
492ebcd fix(doctor): keep partial skills, cleanup failures and Windows quoting in configured scope
7baaa6b fix(doctor): keep the package-runner launcher in the suggested command
15282fc fix(doctor): pin the suggested release and select Hopper by discovery
68d371d docs(doctor): describe the pinned package-runner launcher
e785f81 fix(doctor): quote PowerShell splatting and array tokens in the suggested command
c91230b feat(doctor): name the failing checks in configured_scope

📊 Changes

4 files changed (+635 additions, -12 deletions)

View changed files

📝 docs/installation.md (+17 -0)
📝 src/application/Doctor.test.ts (+371 -1)
📝 src/application/Doctor.ts (+129 -11)
📝 src/application/DoctorScope.ts (+118 -0)

📄 Description

Summary

Refs #6914. Without a scope option, rea doctor reports healthy: false whenever any detected client or provider is unhealthy, including ones the user never set up (here: IDA, JADX, Kuna, and the Codex, VS Code and Gemini registrations). A working setup then looks broken, and the report does not say which failures matter or how to check only the set-up workflow.

Problem and expected behavior

Trigger: run rea doctor with no --client, --provider or --skill on a host where only some clients and providers are set up.
Before: healthy: false and environment_healthy: false, with no pointer to the configured workflow's readiness. The scoped mode that answers this already exists, but the user has to know to use it and which IDs to pass.
After: the audit-wide report additionally carries configured_scope, with the set-up clients, providers and skill, their readiness under the existing explicit-scope rules, and the exact rea doctor command that reports that scope. healthy, environment_healthy, scope_checks and the exit status are unchanged.

Change and scope

src/application/DoctorScope.ts: new configuredDoctorScope, which selects:
- clients whose registration state is anything except missing or manual (so stale, unknown and invalid registrations stay in, and their failures still count);
- providers whose inspection reports configured: true, plus Hopper when it is configured or its launcher was discovered (presence, not readiness, so a failing Hopper stays visible);
- the skill when any selected copy is installed, including a partial install whose aggregate state is missing.
selectConfiguredDoctorScope picks the clients and providers; configuredDoctorScope builds the explicit scope and reuses scopeDoctorChecks for healthy, so there is no second definition of readiness. Nothing is reported when no client or provider is set up. It reports argv (the exact unquoted arguments, starting with npx -y rea-agents@<version> or bunx rea-agents@<version>, pinned to the running release, when doctor was launched that way, otherwise rea) and command, the same invocation quoted for PowerShell on Windows and POSIX shells elsewhere, quoting only arguments that need it (on Windows that includes a leading @ and any ,, which PowerShell treats as splatting and array syntax).
src/application/Doctor.ts: when any client is configured, inspectConfiguredScope reads that client set's skill copies (as the suggested --client … --skill scope does) through inspectSkillIdentity, the helper collectDoctorIdentity now shares, and judges configured_scope from those facts. With no configured client the suggested scope reads every copy, so the audit's facts are reused. The audit's own checks are unchanged. If doctor's final cleanup fails, configured_scope.healthy becomes false with the top-level fields, as the suggested scope would report.
DoctorReport.configured_scope? is emitted only when scope.mode === "audit-wide".
docs/installation.md: explains why an audit-wide healthy can be false for a working setup and what configured_scope contains.
Not included: no change to what healthy means or to the exit status; the issue's discussion suggests keeping both summaries, and this keeps the audit result authoritative. No new CLI flag (the existing --client/--provider/--skill scope already covers the "configured only" check; the report now names it).

Follow the contribution scope.
Unresolved scope, authority, side effects, or required verification block
integration. Link the required maintainer scope decision for new providers or
capabilities involving target execution, injection, mutation, or protection
recovery; ordinary fixes within existing boundaries may state "not applicable".
Draft PRs may leave the scope decision pending and the readiness and merge checklists
unchecked. Maintainers can help resolve open questions.

Contract and boundary impact

Semantic owner and earliest changed stage: doctor scope selection (DoctorScope.ts), consumed by inspectDoctor.
Contribution scope fit and linked maintainer decision: usability change within the existing doctor command; not applicable. The issue is labeled as a feature and its exact presentation is open for maintainer preference.
CLI and MCP/tool-catalog contract: additive optional configured_scope field on audit-wide doctor reports; no change for explicit-scope reports or to existing fields and exit status. No MCP tool schema change.
Provider, bridge, target-format, or platform compatibility: none.
Evidence, artifact, provenance, or reconstruction contract: none.
Target selection, authority, upstream behavior, and cleanup details (if applicable): read-only; reuses the facts doctor already collects (registrations, provider inspections, skill state). No new probes.
Generated metadata (docs/public/product-catalog.json), package, or installation impact (CI generates and validates ignored catalogs and skills/; edit authored instructions in .agents/skills/reverse-engineer-anything/ and never commit build outputs): none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Tests added or updated: src/application/Doctor.test.ts → "doctor configured scope":
- a workstation with an aligned cursor registration, missing codex/vscode, configured Ghidra, discovered Hopper and unconfigured IDA/JADX/Kuna: the audit stays healthy: false, configured_scope is {clients: ["cursor"], providers: ["ghidra", "hopper"], skill: true, healthy: true} with the matching command, and running that exact scope also reports healthy: true (and has no configured_scope);
- a configured but unavailable Ghidra makes configured_scope.healthy false and lists ghidra-java with its remediation in failing_checks; a healthy scope has failing_checks: [];
- a stale registration stays in the configured clients and fails it;
- a target path with a space and a quote is shell-quoted in the command; on win32 it is quoted for PowerShell and kept unquoted in argv;
- a partial skill install (aligned cursor, missing codex copy) keeps --skill and makes the workflow unhealthy;
- a final cleanup failure (through runDoctorOwned) makes both configured_scope and the suggested scope unhealthy and appears in failing_checks;
- a package-runner launch keeps the pinned npx -y rea-agents@<version> in argv/command, and systemDoctorHost detects bunx from the environment;
- on win32, @sample.exe and a,b.exe are quoted while dir/a@b.exe stays bare; on Linux @sample.exe stays bare;
- a discovered Hopper whose later check fails (Linux hopper-demo-runtime) stays in providers and makes the workflow unhealthy;
- the skill is judged from the configured clients' copies: with an aligned cursor copy and a stale copy elsewhere, the audit keeps its failing skill:identity check while configured_scope.healthy is true and matches the suggested scope; a stale cursor copy makes it false (review finding);
- no configured_scope when nothing is set up.
Base reproduction or other evidence: on the base revision the four positive tests fail (configured_scope is undefined); the "nothing set up" control passes on both.
User-visible CLI/MCP output (if applicable): rea doctor --format json on a real macOS host (one agent client registered, Hopper installed, IDA/JADX/Kuna and other clients not set up), run from this branch's build:
```
{"healthy": false, "environment_healthy": false,
 "configured_scope": {"clients": ["<client>"], "providers": ["hopper"], "skill": true,
   "healthy": false, "command": "rea doctor --client <client> --provider hopper --skill",
   "failing_checks": [{"name": "registration:<client>", "ok": false, "classification": "config_drift", …},
                      {"name": "skill:identity", "ok": false, "classification": "config_drift", …}]}}
```
(The registered client's ID is replaced with <client> here; everything else is verbatim.)

Here configured_scope.healthy is false for real reasons rather than the unconfigured components: the development build expects skill version 46 while the installed copy is 42, and the client registration points at the installed 6.7.0 rather than this checkout. Running the printed command reports exactly those two failures (registration:<client>, skill:identity). The installed 6.7.0 on the same host reports the same healthy/environment_healthy without configured_scope.
Remaining proof gaps: not run on Linux or Windows hosts; Windows quoting is covered by a unit test only, and command targets PowerShell (cmd.exe callers should use argv). Whether maintainers prefer a different field name or an additional human-readable summary line is open.

For evidence-bearing changes:

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

Node 24.22.1, macOS arm64, after npm ci. At head c91230b3:

npx vitest run src/application/Doctor.test.ts — 91 passed.
npx vitest run src/application tests/boundary/cli/doctorHopperDiscovery.test.ts tests/boundary/cli/cliSetup.test.ts (after npm run build) — 161 files passed; 2521 tests passed, 3 skipped.
npm run typecheck — passed.
npm run lint — 0 errors; 2657 warnings, identical to main without these changes.
npm run format:check and npm run docs:check — passed.
npm run build — passed.

At 78faaaa4 (first commit), additionally: npx vitest run src/application tests/boundary/cli — 329 of 330 files passed; 3648 tests passed, 8 skipped, 1 failed: tests/boundary/cli/idaRetainedCleanupCli.test.ts, which passes when run alone on this branch and on main without these changes. npm run verify:test-discovery and npm run verify:architecture-guards passed. These were not repeated at c91230b3.

GitHub CI on e7aebf37 failed only in tests/boundary/process/packedBridgeVerification.test.ts, which also failed on main at the base commit; that is now fixed on main. CI on 7baaa6ba failed only in tests/process-global/commandFinalizationCancellation.test.ts, which fails identically on current main 397aa62f without these changes (run locally on a clean checkout; see the PR comments).

Compatibility, safety, and release

Breaking changes or migration steps: none; one optional field added to audit-wide reports.
Real Hopper/Ghidra, browser, or OS coverage: real rea doctor on macOS arm64 (above). Not run on Linux or Windows.
Package or release metadata impact: none.
Security, privacy, process, or containment review: no new reads beyond what doctor already collects; the report repeats client and provider IDs that the audit already lists.

Author readiness

Human owner: @akshatgg

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/7004 **Author:** [@akshatgg](https://github.com/akshatgg) **Created:** 10/24/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/doctor-audit-scope-hint` --- ### 📝 Commits (8) - [`d129a05`](https://github.com/morluto/rea/commit/d129a05abe2c1993172f0dba7bdbb273d7b2da53) feat(doctor): report the configured workflow beside an audit-wide result - [`e7aebf3`](https://github.com/morluto/rea/commit/e7aebf37b21e92aad02ca73dacc67d1612ec3d1d) fix(doctor): judge the configured skill from the configured clients' copies - [`492ebcd`](https://github.com/morluto/rea/commit/492ebcd01f60d56a95e0d216945901095dd4694c) fix(doctor): keep partial skills, cleanup failures and Windows quoting in configured scope - [`7baaa6b`](https://github.com/morluto/rea/commit/7baaa6ba1b9655cfb9b2731bdf43693b2843fd8e) fix(doctor): keep the package-runner launcher in the suggested command - [`15282fc`](https://github.com/morluto/rea/commit/15282fc8028bd9d6baa0dcb6c75ba02e51170c74) fix(doctor): pin the suggested release and select Hopper by discovery - [`68d371d`](https://github.com/morluto/rea/commit/68d371d534707231514f0810bc2dc9f6dc23a68c) docs(doctor): describe the pinned package-runner launcher - [`e785f81`](https://github.com/morluto/rea/commit/e785f819d1349a46708c79dd33a47738587a4a1d) fix(doctor): quote PowerShell splatting and array tokens in the suggested command - [`c91230b`](https://github.com/morluto/rea/commit/c91230b33a6a0d9f01317efaf85b081a910feb88) feat(doctor): name the failing checks in configured_scope ### 📊 Changes **4 files changed** (+635 additions, -12 deletions) <details> <summary>View changed files</summary> 📝 `docs/installation.md` (+17 -0) 📝 `src/application/Doctor.test.ts` (+371 -1) 📝 `src/application/Doctor.ts` (+129 -11) 📝 `src/application/DoctorScope.ts` (+118 -0) </details> ### 📄 Description ## Summary Refs #6914. Without a scope option, `rea doctor` reports `healthy: false` whenever any detected client or provider is unhealthy, including ones the user never set up (here: IDA, JADX, Kuna, and the Codex, VS Code and Gemini registrations). A working setup then looks broken, and the report does not say which failures matter or how to check only the set-up workflow. ## Problem and expected behavior - Trigger: run `rea doctor` with no `--client`, `--provider` or `--skill` on a host where only some clients and providers are set up. - Before: `healthy: false` and `environment_healthy: false`, with no pointer to the configured workflow's readiness. The scoped mode that answers this already exists, but the user has to know to use it and which IDs to pass. - After: the audit-wide report additionally carries `configured_scope`, with the set-up clients, providers and skill, their readiness under the existing explicit-scope rules, and the exact `rea doctor` command that reports that scope. `healthy`, `environment_healthy`, `scope_checks` and the exit status are unchanged. ## Change and scope - `src/application/DoctorScope.ts`: new `configuredDoctorScope`, which selects: - clients whose registration state is anything except `missing` or `manual` (so `stale`, `unknown` and `invalid` registrations stay in, and their failures still count); - providers whose inspection reports `configured: true`, plus Hopper when it is configured or its launcher was discovered (presence, not readiness, so a failing Hopper stays visible); - the skill when any selected copy is installed, including a partial install whose aggregate state is `missing`. `selectConfiguredDoctorScope` picks the clients and providers; `configuredDoctorScope` builds the explicit scope and reuses `scopeDoctorChecks` for `healthy`, so there is no second definition of readiness. Nothing is reported when no client or provider is set up. It reports `argv` (the exact unquoted arguments, starting with `npx -y rea-agents@<version>` or `bunx rea-agents@<version>`, pinned to the running release, when doctor was launched that way, otherwise `rea`) and `command`, the same invocation quoted for PowerShell on Windows and POSIX shells elsewhere, quoting only arguments that need it (on Windows that includes a leading `@` and any `,`, which PowerShell treats as splatting and array syntax). - `src/application/Doctor.ts`: when any client is configured, `inspectConfiguredScope` reads that client set's skill copies (as the suggested `--client … --skill` scope does) through `inspectSkillIdentity`, the helper `collectDoctorIdentity` now shares, and judges `configured_scope` from those facts. With no configured client the suggested scope reads every copy, so the audit's facts are reused. The audit's own checks are unchanged. If doctor's final cleanup fails, `configured_scope.healthy` becomes false with the top-level fields, as the suggested scope would report. - `DoctorReport.configured_scope?` is emitted only when `scope.mode === "audit-wide"`. - `docs/installation.md`: explains why an audit-wide `healthy` can be false for a working setup and what `configured_scope` contains. - Not included: no change to what `healthy` means or to the exit status; the issue's discussion suggests keeping both summaries, and this keeps the audit result authoritative. No new CLI flag (the existing `--client`/`--provider`/`--skill` scope already covers the "configured only" check; the report now names it). Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). Unresolved scope, authority, side effects, or required verification block integration. Link the required maintainer scope decision for new providers or capabilities involving target execution, injection, mutation, or protection recovery; ordinary fixes within existing boundaries may state "not applicable". Draft PRs may leave the scope decision pending and the readiness and merge checklists unchecked. Maintainers can help resolve open questions. ## Contract and boundary impact - Semantic owner and earliest changed stage: doctor scope selection (`DoctorScope.ts`), consumed by `inspectDoctor`. - Contribution scope fit and linked maintainer decision: usability change within the existing doctor command; not applicable. The issue is labeled as a feature and its exact presentation is open for maintainer preference. - CLI and MCP/tool-catalog contract: additive optional `configured_scope` field on audit-wide doctor reports; no change for explicit-scope reports or to existing fields and exit status. No MCP tool schema change. - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details (if applicable): read-only; reuses the facts doctor already collects (registrations, provider inspections, skill state). No new probes. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact (CI generates and validates ignored catalogs and `skills/`; edit authored instructions in `.agents/skills/reverse-engineer-anything/` and never commit build outputs): none. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [x] Read existing files or captured data. - [x] Launch or attach to a process. - [x] Inject instrumentation or run scripts/code. - [x] Change process memory, registers, files, or configuration. - [x] Contact network services. - [x] Recover protected code or work around protections. - [x] Documentation or usability only; no target interaction. - [x] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `src/application/Doctor.test.ts` → "doctor configured scope": - a workstation with an aligned `cursor` registration, missing `codex`/`vscode`, configured Ghidra, discovered Hopper and unconfigured IDA/JADX/Kuna: the audit stays `healthy: false`, `configured_scope` is `{clients: ["cursor"], providers: ["ghidra", "hopper"], skill: true, healthy: true}` with the matching command, and running that exact scope also reports `healthy: true` (and has no `configured_scope`); - a configured but unavailable Ghidra makes `configured_scope.healthy` false and lists `ghidra-java` with its remediation in `failing_checks`; a healthy scope has `failing_checks: []`; - a `stale` registration stays in the configured clients and fails it; - a target path with a space and a quote is shell-quoted in the command; on `win32` it is quoted for PowerShell and kept unquoted in `argv`; - a partial skill install (aligned `cursor`, missing `codex` copy) keeps `--skill` and makes the workflow unhealthy; - a final cleanup failure (through `runDoctorOwned`) makes both `configured_scope` and the suggested scope unhealthy and appears in `failing_checks`; - a package-runner launch keeps the pinned `npx -y rea-agents@<version>` in `argv`/`command`, and `systemDoctorHost` detects `bunx` from the environment; - on `win32`, `@sample.exe` and `a,b.exe` are quoted while `dir/a@b.exe` stays bare; on Linux `@sample.exe` stays bare; - a discovered Hopper whose later check fails (Linux `hopper-demo-runtime`) stays in `providers` and makes the workflow unhealthy; - the skill is judged from the configured clients' copies: with an aligned `cursor` copy and a stale copy elsewhere, the audit keeps its failing `skill:identity` check while `configured_scope.healthy` is true and matches the suggested scope; a stale `cursor` copy makes it false (review finding); - no `configured_scope` when nothing is set up. - Base reproduction or other evidence: on the base revision the four positive tests fail (`configured_scope` is `undefined`); the "nothing set up" control passes on both. - User-visible CLI/MCP output (if applicable): `rea doctor --format json` on a real macOS host (one agent client registered, Hopper installed, IDA/JADX/Kuna and other clients not set up), run from this branch's build: ```json {"healthy": false, "environment_healthy": false, "configured_scope": {"clients": ["<client>"], "providers": ["hopper"], "skill": true, "healthy": false, "command": "rea doctor --client <client> --provider hopper --skill", "failing_checks": [{"name": "registration:<client>", "ok": false, "classification": "config_drift", …}, {"name": "skill:identity", "ok": false, "classification": "config_drift", …}]}} ``` (The registered client's ID is replaced with `<client>` here; everything else is verbatim.) Here `configured_scope.healthy` is false for real reasons rather than the unconfigured components: the development build expects skill version 46 while the installed copy is 42, and the client registration points at the installed 6.7.0 rather than this checkout. Running the printed command reports exactly those two failures (`registration:<client>`, `skill:identity`). The installed 6.7.0 on the same host reports the same `healthy`/`environment_healthy` without `configured_scope`. - Remaining proof gaps: not run on Linux or Windows hosts; Windows quoting is covered by a unit test only, and `command` targets PowerShell (cmd.exe callers should use `argv`). Whether maintainers prefer a different field name or an additional human-readable summary line is open. For evidence-bearing changes: - [ ] Observed, derived, and inferred claims remain distinguishable. - [ ] Artifact identity, source provenance, and failed attempts remain preserved. - [ ] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed Node 24.22.1, macOS arm64, after `npm ci`. At head c91230b3: - `npx vitest run src/application/Doctor.test.ts` — 91 passed. - `npx vitest run src/application tests/boundary/cli/doctorHopperDiscovery.test.ts tests/boundary/cli/cliSetup.test.ts` (after `npm run build`) — 161 files passed; 2521 tests passed, 3 skipped. - `npm run typecheck` — passed. - `npm run lint` — 0 errors; 2657 warnings, identical to main without these changes. - `npm run format:check` and `npm run docs:check` — passed. - `npm run build` — passed. At 78faaaa4 (first commit), additionally: `npx vitest run src/application tests/boundary/cli` — 329 of 330 files passed; 3648 tests passed, 8 skipped, 1 failed: `tests/boundary/cli/idaRetainedCleanupCli.test.ts`, which passes when run alone on this branch and on main without these changes. `npm run verify:test-discovery` and `npm run verify:architecture-guards` passed. These were not repeated at c91230b3. GitHub CI on e7aebf37 failed only in `tests/boundary/process/packedBridgeVerification.test.ts`, which also failed on main at the base commit; that is now fixed on main. CI on 7baaa6ba failed only in `tests/process-global/commandFinalizationCancellation.test.ts`, which fails identically on current main 397aa62f without these changes (run locally on a clean checkout; see the PR comments). ## Compatibility, safety, and release - Breaking changes or migration steps: none; one optional field added to audit-wide reports. - Real Hopper/Ghidra, browser, or OS coverage: real `rea doctor` on macOS arm64 (above). Not run on Linux or Windows. - Package or release metadata impact: none. - Security, privacy, process, or containment review: no new reads beyond what doctor already collects; the report repeats client and provider IDs that the audit already lists. ## Author readiness Human owner: @akshatgg - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-11-03 13:38:45 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#7566

No description provided.

Rows
Columns