[PR #6024] [MERGED] fix(android): name the JADX deadline and recover apktool decode #7129

Closed
opened 2026-11-01 21:45:36 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6024
Author: @morluto
Created: 10/21/2026
Status: ✅ Merged
Merged: 10/21/2026
Merged by: @morluto

Base: main ← Head: cursor/android-jadx-apktool-deadlines-5ac1


📝 Commits (4)

  • cad8291 fix(android): name the JADX deadline and recover apktool decode
  • 48a5f79 merge(main): update android deadline branch
  • f4493da fix(android): derive capture recovery from the fixed allowance
  • 0ef83e4 test(apktool): observe a real decode deadline and process cleanup

📊 Changes

25 files changed (+636 additions, -47 deletions)

View changed files

📝 .agents/skills/reverse-engineer-anything/references/android-applications.md (+3 -2)
📝 docs/adb-device-analysis.md (+5 -3)
📝 docs/android-analysis.md (+6 -3)
📝 docs/apktool-resource-analysis.md (+9 -3)
📝 scripts/lib/test-projects.mjs (+1 -1)
📝 src/adb/AdbCommand.test.ts (+35 -0)
📝 src/adb/AdbCommand.ts (+16 -10)
📝 src/adb/AdbConfiguration.ts (+8 -7)
➕ src/adb/AdbVersionProbe.test.ts (+62 -0)
📝 src/android/JadxConfiguration.ts (+2 -0)
📝 src/android/JadxFailure.ts (+6 -5)
📝 src/android/JadxJavaProbe.ts (+9 -3)
➕ src/android/JadxOperationTimeout.test.ts (+35 -0)
📝 src/android/JadxRelease.ts (+8 -0)
📝 src/apktool/ApktoolConfiguration.ts (+19 -2)
➕ src/apktool/ApktoolDecodeTimeout.test.ts (+153 -0)
📝 src/apktool/ApktoolProvider.ts (+19 -4)
📝 src/apktool/ApktoolVersionProbe.test.ts (+6 -1)
📝 src/cli/apktoolCommands.ts (+5 -0)
📝 src/contracts/apktool/apktoolToolContracts.ts (+1 -1)

...and 5 more files

📄 Description

Summary

Refs #5910 (parent #5808). JADX operation timeouts now name REA_JADX_OPERATION_TIMEOUT_MS, the effective milliseconds, the range 1 to 2147483647, and that a change applies on the next process start.

Apktool decode accepts decode_timeout_ms (CLI --decode-timeout-ms). Omitted means 600000 ms. The integer range is 1 to 2147483647. A timeout names that key, and a change applies on the next decode. It does not raise the 4194304-byte output capture allowance.

ADB command deadlines, the adb version probe, the apktool version probe, and the JADX Java module-listing probe stay at their current numbers and say this release has no runtime override.

Problem and expected behavior

A JADX operation that reached its deadline reported only the generic provider timeout. The failure did not name REA_JADX_OPERATION_TIMEOUT_MS, the effective milliseconds, the accepted range, or that the value is read from the environment captured at process start.

apktool d used a fixed 600000 ms wall clock. A stopped decode did not name a control the caller could set on the next decode. The 4194304-byte output capture allowance stayed fixed.

ADB deadlines and version probes failed without saying this release has no runtime override.

Change and scope

  • JADX timeout projection (captureJadxFailure, archive inspection, and the Java probe when the operation deadline aborts it) uses jadxOperationTimeoutGuidance. The env var, parser, and 120000 ms default are unchanged. The provider still receives the snapshotted launch environment, so a change applies on the next process start. The 30000 ms bridge startup handshake stays fixed.
  • decode_android_resources gains optional decode_timeout_ms. Omitted stays omitted in Evidence and the provider uses 600000. CLI --decode-timeout-ms maps to that field. At 2147483647 the recovery says not to increase it further.
  • ADB runAdbCapture timeouts and output-cap refusals, the adb version probe, the apktool version probe (including Windows PATH lookup), and the Java module-listing probe name the effective value and say there is no runtime override. decode_timeout_ms and REA_JADX_OPERATION_TIMEOUT_MS do not raise those probes.
  • Capture refusals keep that no-runtime-override sentence in the fixed-allowance name. Recovery is derived from the allowance. decode_timeout_ms does not raise the apktool output cap.
  • A POSIX production-boundary test launches a hanging interpreter and a pipe-holding child through ApktoolProvider, waits until both are alive, and requires the owned-command deadline to elapse before provider_timeout with completed cleanup.

Out of scope: MCP response and startup ceilings, JEB/IDA/command_timeout_ms, JavaScript heap and semantic ceilings, browser, native, swiftc, engines, and ASAR. The measured JADX JAR central-directory budget is unchanged.

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.

Not applicable. This names an existing JADX launch-environment deadline and adds a caller-selected wall clock to the existing apktool decode. It does not add a provider, target execution, injection, mutation, or protection recovery.

Contract and boundary impact

  • Semantic owner and earliest changed stage: JadxRelease owns the JADX deadline sentence. apktoolInputSchemas.decode_android_resources owns decode_timeout_ms. ApktoolProvider applies it to the decode command. ADB and version-probe text stays at the command owners that already fail the call.
  • Contribution scope fit and linked maintainer decision: not applicable. Recovery and one existing-workflow deadline inside the current Android and apktool boundaries.
  • CLI and MCP/tool-catalog contract: decode_android_resources accepts optional decode_timeout_ms (CLI --decode-timeout-ms). Omitted means 600000 and is absent from parameters. Tool description names the default, range, and that the output cap and version probe stay fixed. docs/public/product-catalog.json is generated and was not committed.
  • Provider, bridge, target-format, or platform compatibility: none. JADX still requires the caller-supplied JAR. Apktool is still bring-your-own.
  • Evidence, artifact, provenance, or reconstruction contract: a selected decode_timeout_ms is retained in Evidence parameters. Omitted stays omitted. Result fields are unchanged.
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): the selected deadline bounds the existing owned apktool d process. It does not raise the output capture allowance. On POSIX, the hanging-launcher test observes the launcher and its pipe-holding child gone after the deadline, with cleanupIncomplete false.
  • 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): the Android skill sentence now names the JADX range and next process start. No package or install change.

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: tests/boundary/providers/apktoolDecodeDeadline.test.ts, src/android/JadxOperationTimeout.test.ts, src/apktool/ApktoolDecodeTimeout.test.ts, src/domain/apktool/apktoolResourceAnalysis.test.ts, src/apktool/ApktoolVersionProbe.test.ts, src/adb/AdbCommand.test.ts, src/adb/AdbVersionProbe.test.ts, tests/boundary/android/jadxConfiguration.test.ts, tests/boundary/cli/apktoolBooleanOptions.test.ts.
  • Base reproduction or other evidence: source inspection. JADX AnalysisTimeoutError sites passed only the millisecond count into the generic timeout sentence. DECODE_TIMEOUT_MS was a private 600000 constant with no input field. The module test still projects the omitted 600000 deadline, a selected 5000 ms decode, and the maximum "do not increase it further" sentence. The boundary test runs a real hanging launcher.
  • User-visible CLI/MCP output (if applicable): --decode-timeout-ms 900000 is accepted and omitted means the field is absent. 0 and 2147483648 are rejected before the provider runs. MCP advertisement of decode_android_resources still matches the contract.
  • Remaining proof gaps: the maximum 2147483647 ms sentence is projected, not waited out. No upstream apktool or JADX distribution was launched; the hanging launcher is a Node script selected with REA_APKTOOL_COMMAND. The deadline test skips Windows, so it does not establish Job Object cleanup. The Java module-listing probe test did run a hanging fake JDK and observed the 10000 ms no-override sentence.

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

  • npm run check:fast — typecheck and lint succeeded.
  • npm run test:focused -- the apktool, android, and adb source tests plus tests/boundary/providers/apktoolDecodeDeadline.test.ts, tests/boundary/android/jadxConfiguration.test.ts, tests/boundary/cli/apktoolBooleanOptions.test.ts, tests/boundary/cli/apktoolLocaleOption.test.ts, tests/boundary/cli/apktoolCli.test.ts, and tests/boundary/mcp/apktoolMcp.test.ts — 24 files, 487 tests passed. The hanging-launcher case settled in about 2600 ms for a 2500 ms deadline.

Merged origin/main through d8a9673fc before these runs. The branch was behind and CI on the previous head was green.

Compatibility, safety, and release

  • Breaking changes or migration steps: none. Omitted decode_timeout_ms keeps today's 600000 ms decode. Existing JADX environment values parse as before. Callers that matched the generic timeout sentence will see the named control.
  • Real Hopper/Ghidra, browser, or OS coverage: POSIX process-group cleanup of the hanging apktool launcher was observed. Windows Job Object cleanup of that launcher was not run. No Hopper, Ghidra, or browser behavior changed.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: the new field only lengthens or shortens the existing owned apktool decode, within 1..2147483647 ms. It does not add authority. Fixed capture allowances are unchanged.

Author readiness

Human owner: @morluto

  • 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.
Open in Web Open in Cursor 

🔄 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/6024 **Author:** [@morluto](https://github.com/morluto) **Created:** 10/21/2026 **Status:** ✅ Merged **Merged:** 10/21/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `cursor/android-jadx-apktool-deadlines-5ac1` --- ### 📝 Commits (4) - [`cad8291`](https://github.com/morluto/rea/commit/cad82918d4c236e9315047f2a37ccf939515c989) fix(android): name the JADX deadline and recover apktool decode - [`48a5f79`](https://github.com/morluto/rea/commit/48a5f79a260d5c1c62938f1cdb6a414b522e2d77) merge(main): update android deadline branch - [`f4493da`](https://github.com/morluto/rea/commit/f4493dace00942df9fced30c9d599e43c571598c) fix(android): derive capture recovery from the fixed allowance - [`0ef83e4`](https://github.com/morluto/rea/commit/0ef83e43ac78ca5d27597af40033a5492f4da239) test(apktool): observe a real decode deadline and process cleanup ### 📊 Changes **25 files changed** (+636 additions, -47 deletions) <details> <summary>View changed files</summary> 📝 `.agents/skills/reverse-engineer-anything/references/android-applications.md` (+3 -2) 📝 `docs/adb-device-analysis.md` (+5 -3) 📝 `docs/android-analysis.md` (+6 -3) 📝 `docs/apktool-resource-analysis.md` (+9 -3) 📝 `scripts/lib/test-projects.mjs` (+1 -1) 📝 `src/adb/AdbCommand.test.ts` (+35 -0) 📝 `src/adb/AdbCommand.ts` (+16 -10) 📝 `src/adb/AdbConfiguration.ts` (+8 -7) ➕ `src/adb/AdbVersionProbe.test.ts` (+62 -0) 📝 `src/android/JadxConfiguration.ts` (+2 -0) 📝 `src/android/JadxFailure.ts` (+6 -5) 📝 `src/android/JadxJavaProbe.ts` (+9 -3) ➕ `src/android/JadxOperationTimeout.test.ts` (+35 -0) 📝 `src/android/JadxRelease.ts` (+8 -0) 📝 `src/apktool/ApktoolConfiguration.ts` (+19 -2) ➕ `src/apktool/ApktoolDecodeTimeout.test.ts` (+153 -0) 📝 `src/apktool/ApktoolProvider.ts` (+19 -4) 📝 `src/apktool/ApktoolVersionProbe.test.ts` (+6 -1) 📝 `src/cli/apktoolCommands.ts` (+5 -0) 📝 `src/contracts/apktool/apktoolToolContracts.ts` (+1 -1) _...and 5 more files_ </details> ### 📄 Description <!-- CURSOR_AGENT_PR_BODY_BEGIN --> ## Summary Refs #5910 (parent #5808). JADX operation timeouts now name `REA_JADX_OPERATION_TIMEOUT_MS`, the effective milliseconds, the range 1 to 2147483647, and that a change applies on the next process start. Apktool decode accepts `decode_timeout_ms` (CLI `--decode-timeout-ms`). Omitted means 600000 ms. The integer range is 1 to 2147483647. A timeout names that key, and a change applies on the next decode. It does not raise the 4194304-byte output capture allowance. ADB command deadlines, the adb version probe, the apktool version probe, and the JADX Java module-listing probe stay at their current numbers and say this release has no runtime override. ## Problem and expected behavior A JADX operation that reached its deadline reported only the generic provider timeout. The failure did not name `REA_JADX_OPERATION_TIMEOUT_MS`, the effective milliseconds, the accepted range, or that the value is read from the environment captured at process start. `apktool d` used a fixed 600000 ms wall clock. A stopped decode did not name a control the caller could set on the next decode. The 4194304-byte output capture allowance stayed fixed. ADB deadlines and version probes failed without saying this release has no runtime override. ## Change and scope - JADX timeout projection (`captureJadxFailure`, archive inspection, and the Java probe when the operation deadline aborts it) uses `jadxOperationTimeoutGuidance`. The env var, parser, and 120000 ms default are unchanged. The provider still receives the snapshotted launch environment, so a change applies on the next process start. The 30000 ms bridge startup handshake stays fixed. - `decode_android_resources` gains optional `decode_timeout_ms`. Omitted stays omitted in Evidence and the provider uses 600000. CLI `--decode-timeout-ms` maps to that field. At 2147483647 the recovery says not to increase it further. - ADB `runAdbCapture` timeouts and output-cap refusals, the adb version probe, the apktool version probe (including Windows PATH lookup), and the Java module-listing probe name the effective value and say there is no runtime override. `decode_timeout_ms` and `REA_JADX_OPERATION_TIMEOUT_MS` do not raise those probes. - Capture refusals keep that no-runtime-override sentence in the fixed-allowance name. Recovery is derived from the allowance. `decode_timeout_ms` does not raise the apktool output cap. - A POSIX production-boundary test launches a hanging interpreter and a pipe-holding child through `ApktoolProvider`, waits until both are alive, and requires the owned-command deadline to elapse before `provider_timeout` with completed cleanup. Out of scope: MCP response and startup ceilings, JEB/IDA/`command_timeout_ms`, JavaScript heap and semantic ceilings, browser, native, swiftc, engines, and ASAR. The measured JADX JAR central-directory budget is unchanged. 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. Not applicable. This names an existing JADX launch-environment deadline and adds a caller-selected wall clock to the existing apktool decode. It does not add a provider, target execution, injection, mutation, or protection recovery. ## Contract and boundary impact - Semantic owner and earliest changed stage: `JadxRelease` owns the JADX deadline sentence. `apktoolInputSchemas.decode_android_resources` owns `decode_timeout_ms`. `ApktoolProvider` applies it to the decode command. ADB and version-probe text stays at the command owners that already fail the call. - Contribution scope fit and linked maintainer decision: not applicable. Recovery and one existing-workflow deadline inside the current Android and apktool boundaries. - CLI and MCP/tool-catalog contract: `decode_android_resources` accepts optional `decode_timeout_ms` (CLI `--decode-timeout-ms`). Omitted means 600000 and is absent from parameters. Tool description names the default, range, and that the output cap and version probe stay fixed. `docs/public/product-catalog.json` is generated and was not committed. - Provider, bridge, target-format, or platform compatibility: none. JADX still requires the caller-supplied JAR. Apktool is still bring-your-own. - Evidence, artifact, provenance, or reconstruction contract: a selected `decode_timeout_ms` is retained in Evidence parameters. Omitted stays omitted. Result fields are unchanged. - Target selection, authority, upstream behavior, and cleanup details (if applicable): the selected deadline bounds the existing owned `apktool d` process. It does not raise the output capture allowance. On POSIX, the hanging-launcher test observes the launcher and its pipe-holding child gone after the deadline, with `cleanupIncomplete` false. - 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): the Android skill sentence now names the JADX range and next process start. No package or install change. 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. - [ ] 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: `tests/boundary/providers/apktoolDecodeDeadline.test.ts`, `src/android/JadxOperationTimeout.test.ts`, `src/apktool/ApktoolDecodeTimeout.test.ts`, `src/domain/apktool/apktoolResourceAnalysis.test.ts`, `src/apktool/ApktoolVersionProbe.test.ts`, `src/adb/AdbCommand.test.ts`, `src/adb/AdbVersionProbe.test.ts`, `tests/boundary/android/jadxConfiguration.test.ts`, `tests/boundary/cli/apktoolBooleanOptions.test.ts`. - Base reproduction or other evidence: source inspection. JADX `AnalysisTimeoutError` sites passed only the millisecond count into the generic timeout sentence. `DECODE_TIMEOUT_MS` was a private 600000 constant with no input field. The module test still projects the omitted 600000 deadline, a selected 5000 ms decode, and the maximum "do not increase it further" sentence. The boundary test runs a real hanging launcher. - User-visible CLI/MCP output (if applicable): `--decode-timeout-ms 900000` is accepted and omitted means the field is absent. `0` and `2147483648` are rejected before the provider runs. MCP advertisement of `decode_android_resources` still matches the contract. - Remaining proof gaps: the maximum 2147483647 ms sentence is projected, not waited out. No upstream apktool or JADX distribution was launched; the hanging launcher is a Node script selected with `REA_APKTOOL_COMMAND`. The deadline test skips Windows, so it does not establish Job Object cleanup. The Java module-listing probe test did run a hanging fake JDK and observed the 10000 ms no-override sentence. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npm run check:fast` — typecheck and lint succeeded. - `npm run test:focused --` the apktool, android, and adb source tests plus `tests/boundary/providers/apktoolDecodeDeadline.test.ts`, `tests/boundary/android/jadxConfiguration.test.ts`, `tests/boundary/cli/apktoolBooleanOptions.test.ts`, `tests/boundary/cli/apktoolLocaleOption.test.ts`, `tests/boundary/cli/apktoolCli.test.ts`, and `tests/boundary/mcp/apktoolMcp.test.ts` — 24 files, 487 tests passed. The hanging-launcher case settled in about 2600 ms for a 2500 ms deadline. Merged `origin/main` through `d8a9673fc` before these runs. The branch was behind and CI on the previous head was green. ## Compatibility, safety, and release - Breaking changes or migration steps: none. Omitted `decode_timeout_ms` keeps today's 600000 ms decode. Existing JADX environment values parse as before. Callers that matched the generic timeout sentence will see the named control. - Real Hopper/Ghidra, browser, or OS coverage: POSIX process-group cleanup of the hanging apktool launcher was observed. Windows Job Object cleanup of that launcher was not run. No Hopper, Ghidra, or browser behavior changed. - Package or release metadata impact: none. - Security, privacy, process, or containment review: the new field only lengthens or shortens the existing owned apktool decode, within 1..2147483647 ms. It does not add authority. Fixed capture allowances are unchanged. ## Author readiness Human owner: @morluto - [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. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-b56f96a4-508b-5d89-b7e0-deb576955ac1?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a href="https://cursor.com/background-agent?bcId=bc-b56f96a4-508b-5d89-b7e0-deb576955ac1&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</div> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-11-01 21:45:36 +00:00
Sign in to join this conversation.
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#7129
No description provided.