ulfr/recipe
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor(01): address plan-checker revisions (1 blocker, 5 warnings)

Browse Source 
- 01-02: wave 1→2, depends_on [01]; drop unused androidLibrary classpath
  entry; guard Kotlin compilerOptions with plugins.withId listeners
- 01-05: remove misleading 'gradle exit' echo from verify block
- 01-06: harden credential check on docker-compose.yml alone
- 01-07: drop hardcoded /Users/rwilk/dev/repo/recipe cd prefix
- 01-RESEARCH: rename Open Questions → (RESOLVED); replace
  'Recommendation:' with 'RESOLVED:' per gsd Dimension 11 convention
This commit is contained in:
Rafał
2026-04-24 16:40:32 +02:00
parent d6cec3fe07
commit d104d3da87
5 changed files with 29 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.planning/phases/01-project-infrastructure-module-wiring/01-RESEARCH.md
View File

@@ -1141,32 +1141,32 @@ kotlin.native.binary.objcDisposeOnMain=false
**If this table is non-empty:** Planner and `/gsd-discuss-phase` already ran; these assumptions are residual and should be verified during implementation, not re-surfaced. Items A4 and A6 are the ones most likely to surprise — include in Wave 0 smoke checks.
## Open Questions
## Open Questions (RESOLVED)
1. **Should `shared/` keep `com.android.library` directly applied, or rely on `androidTarget` in the `recipe.kotlin.multiplatform` plugin alone?**
- What we know: Current template applies `com.android.library` directly. KMP's `androidTarget { }` declares the Android target but doesn't strictly require the android-library plugin for every module — sometimes it does.
- What's unclear: Whether dropping `com.android.library` from `shared/` breaks the composeApp Android consumer.
- Recommendation: **Keep `com.android.library` applied in `shared/build.gradle.kts` directly in Phase 1.** Build a `recipe.android.library` convention plugin in a future phase if the direct application becomes a pattern. Don't block Phase 1 on this refactor.
- RESOLVED: **Keep `com.android.library` applied in `shared/build.gradle.kts` directly in Phase 1.** Build a `recipe.android.library` convention plugin in a future phase if the direct application becomes a pattern. Don't block Phase 1 on this refactor.
2. **Does `./gradlew build` invoke `flywayMigrate`? Should it?**
- What we know: Flyway plugin exposes `flywayMigrate`, `flywayInfo`, etc. as tasks; it does NOT hook them into `build` by default.
- What's unclear: Nothing — this is a choice.
- Recommendation: **Do NOT wire Flyway tasks into `build` in Phase 1.** Migration is a server-boot concern; the plugin is for CLI ops (developer runs `./gradlew flywayInfo` manually to inspect state). CI integration lands in Phase 11.
- RESOLVED: **Do NOT wire Flyway tasks into `build` in Phase 1.** Migration is a server-boot concern; the plugin is for CLI ops (developer runs `./gradlew flywayInfo` manually to inspect state). CI integration lands in Phase 11.
3. **Should we add `ktor-server-config-yaml` for a `application.yaml` alternative to HOCON?**
- What we know: Ktor 3.x supports YAML config via the `ktor-server-config-yaml` artifact; HOCON remains the default.
- What's unclear: Team preference.
- Recommendation: **Stick with HOCON.** Our server dev is Kotlin/Ktor background (user profile) and HOCON is the historically canonical Ktor config. YAML is a nice-to-have, not worth the added dep.
- RESOLVED: **Stick with HOCON.** Our server dev is Kotlin/Ktor background (user profile) and HOCON is the historically canonical Ktor config. YAML is a nice-to-have, not worth the added dep.
4. **How to verify iOS binary flags take effect without shipping a build to hardware?**
- What we know: Simulator launch eliminates most of the visible symptoms of PITFALL #1; Instruments on a real device would be the gold standard.
- What's unclear: Whether simulator-level verification is sufficient for Phase 1 sign-off.
- Recommendation: **Verify at two levels:** (a) grep `gradle.properties` for the two flags (trivial but catches omission); (b) build the iOS framework and capture the Kotlin/Native link log for a line showing the GC + objcDisposeOnMain options. Real-device verification under Instruments is deferred to Phase 10 (UI chrome) when there's meaningful UI work to stress-test.
- RESOLVED: **Verify at two levels:** (a) grep `gradle.properties` for the two flags (trivial but catches omission); (b) build the iOS framework and capture the Kotlin/Native link log for a line showing the GC + objcDisposeOnMain options. Real-device verification under Instruments is deferred to Phase 10 (UI chrome) when there's meaningful UI work to stress-test.
5. **Does `recipe.quality` need a `targetExclude` for generated Compose Resources code?**
- What we know: Compose Multiplatform generates `Res.kt` under `build/generated/compose/resourceGenerator/...`.
- What's unclear: Whether Spotless/ktlint visit `build/` by default (they shouldn't, but worth confirming).
- Recommendation: **Add `targetExclude("**/build/**", "**/generated/**")` explicitly in the Spotless config** (already in Pattern 5 example) to future-proof against any `.kt` file landing in those paths.
- RESOLVED: **Add `targetExclude("**/build/**", "**/generated/**")` explicitly in the Spotless config** (already in Pattern 5 example) to future-proof against any `.kt` file landing in those paths.
## Environment Availability