docs(roadmap): v0.4.x plan — auto-publish, analytics, optimal time, repurposing#68
Merged
Conversation
…epurposing Research-informed plan for the next four minor versions, sequenced by user impact and technical dependency. v0.4.0 closes the gap on the table-stake feature missing today (auto-publish at scheduled time); v0.4.1 adds the feedback loop (post-publish analytics); v0.4.2 turns the data into actionable optimal-time suggestions; v0.4.3 ships content repurposing one-click. Compiled from: - Competitive analysis of Buffer / Hypefury / Later 2026 reviews - Tauri scheduling patterns (tokio-cron-scheduler, custom poll) - Viral content research already in memory (golden hour LinkedIn, DM shares > saves > comments > likes Instagram 2026) - Codebase audit of public-fn-without-tests modules Includes: - Top 5 features priorized by ROI with impact + faisability + estimation découpée - Test coverage gaps mapped to feature work (no big-bang test PR) - 14 PRs sequenced across 4 minor versions - Success criteria per version - Explicit hors-scope list (V0.5+ backlog: multi-account same network, Stories/Reels, multi-user, cloud sync) No code change — pure docs, ratifiable by @Thierry. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Guide du réviseurAjoute un nouveau document de feuille de route pour la v0.4.x qui définit l’ordonnancement des fonctionnalités (planification de publication automatique, récupération des analyses, IA pour l’heure optimale de publication, réutilisation de contenu), les améliorations UX associées issues de l’issue #62, la stratégie de couverture de tests et les critères de réussite, sans modifier aucun code exécutable. Diagramme de flux pour l’ordonnancement des fonctionnalités de la feuille de route v0.4.xflowchart LR
subgraph v0_4_0["v0.4.0\nAuto_publish_scheduling"]
F1["F1 scheduler_foundation"]
F2["F2 scheduler_integration"]
F3["F3 scheduler_UI"]
F4["F4 test_sweep"]
F5["F5 UX_polish_1_2_3"]
F1 --> F2 --> F3
F3 --> F4 --> F5
end
subgraph v0_4_1["v0.4.1\nAnalytics_fetch"]
F6["F6 analytics_foundation"]
F7["F7 analytics_IG_fetch"]
F8["F8 analytics_LinkedIn_fetch"]
F9["F9 analytics_UI"]
F10["F10 instagram_adapter_tests"]
F11["F11 UX_polish_4_5_6_7"]
F6 --> F7 --> F8 --> F9
F9 --> F10 --> F11
end
subgraph v0_4_2["v0.4.2\nOptimal_posting_time_AI"]
F12["F12 optimal_posting_time"]
end
subgraph v0_4_3["v0.4.3\nContent_repurposing"]
F13["F13 content_repurposing"]
F14["F14 UX_polish_8_9_10"]
F13 --> F14
end
v0_4_0 --> v0_4_1 --> v0_4_2 --> v0_4_3
F6 -->|requires analytics_data| F12
Modifications au niveau des fichiers
Conseils et commandesInteragir avec Sourcery
Personnaliser votre expérienceAccédez à votre tableau de bord pour :
Obtenir de l’aide
Original review guide in EnglishReviewer's GuideAdds a new roadmap document for v0.4.x that defines feature sequencing (auto-publish scheduling, analytics fetch, optimal posting time AI, content repurposing), associated UX polish from issue #62, test coverage strategy, and success criteria, without changing any executable code. Flow diagram for v0.4.x roadmap feature sequencingflowchart LR
subgraph v0_4_0["v0.4.0\nAuto_publish_scheduling"]
F1["F1 scheduler_foundation"]
F2["F2 scheduler_integration"]
F3["F3 scheduler_UI"]
F4["F4 test_sweep"]
F5["F5 UX_polish_1_2_3"]
F1 --> F2 --> F3
F3 --> F4 --> F5
end
subgraph v0_4_1["v0.4.1\nAnalytics_fetch"]
F6["F6 analytics_foundation"]
F7["F7 analytics_IG_fetch"]
F8["F8 analytics_LinkedIn_fetch"]
F9["F9 analytics_UI"]
F10["F10 instagram_adapter_tests"]
F11["F11 UX_polish_4_5_6_7"]
F6 --> F7 --> F8 --> F9
F9 --> F10 --> F11
end
subgraph v0_4_2["v0.4.2\nOptimal_posting_time_AI"]
F12["F12 optimal_posting_time"]
end
subgraph v0_4_3["v0.4.3\nContent_repurposing"]
F13["F13 content_repurposing"]
F14["F14 UX_polish_8_9_10"]
F13 --> F14
end
v0_4_0 --> v0_4_1 --> v0_4_2 --> v0_4_3
F6 -->|requires analytics_data| F12
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
@Thierry flagged responsive design 2026 as a non-negotiable quality bar for v0.4.x UI work. Added a dedicated section #5 ahead of the UX polish list with concrete standards to apply to every new UI (scheduler badges, analytics views, repurpose modal, etc.): - Container queries (component-level adaptation) replace media queries for components — the brief/preview ratio shift in the Composer is exactly the case container queries were invented for. - Fluid typography with clamp() — caption previews + analytics numbers stay legible from 600px to 1920+px without breakpoint cliffs. - Intrinsic layouts (`repeat(auto-fit, minmax(...))`) for calendar grid, GroupResultPanel tiles, analytics top-post cards — no manual breakpoint calculations. - Dark mode contrast WCAG AA on every new component (Getpostcraft is dark-default). - Image formats AVIF noted for backlog v0.5. Pre-merge checklist for each v0.4.x UI PR: test at 600×800 (narrow Tauri window @thierry-style) AND 1920×1080 (full HD). Container queries + clamp() preferred over media queries for new code. Three new sources added (container queries 2026, UXPin 2026 responsive, Beyond Media Queries). The section is doc-only — implementation discipline lands as each v0.4.x PR ships its UI work. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Salut – j’ai trouvé 2 problèmes et laissé quelques retours plus globaux :
- Pour le planificateur de publication automatique, pensez à spécifier le comportement en cas de mise en veille du système / changement de fuseau horaire (par ex. ordinateur portable en veille au moment de la publication, changements d’heure d’été) afin que l’implémentation puisse gérer ces cas de manière déterministe plutôt que de les traiter comme des scénarios génériques « app fermée ».
- Vous définissez une limite fixe de 24 h pour les publications programmées manquées comme étant « perdues » ; cela vaudrait la peine de préciser si cette valeur devrait être configurable par l’utilisateur (ou au moins paramétrable) compte tenu des différents workflows et fuseaux horaires, afin que le comportement ne surprenne pas les utilisateurs ayant des horizons de planification longs.
- Comme l’auto-publication et l’analytics utilisent tous deux des tâches en arrière-plan avec du polling, il pourrait être utile d’esquisser brièvement comment ces planificateurs vont coexister (par ex. exécuteur partagé vs tâches séparées, stratégie de concurrence maximale / de limitation de débit) pour éviter de futurs conflits ou une duplication de la logique de planification.
Prompt pour agents IA
Please address the comments from this code review:
## Overall Comments
- For the auto-publish scheduler, consider specifying behavior for system sleep/timezone changes (e.g., laptop asleep at publish time, DST shifts) so implementation can handle these cases deterministically rather than treating them as generic 'app fermée' scenarios.
- You define a hard-coded 24h cut-off for missed scheduled posts as 'perdu'; it may be worth calling out whether this should be user-configurable (or at least parameterized) given different workflows and timezones, so the behavior doesn’t surprise users with long planning horizons.
- Since both auto-publish and analytics use background tasks with polling, it could help to briefly outline how these schedulers will coexist (e.g., shared runner vs separate tasks, max concurrency/rate-limit strategy) to avoid future contention or duplicated scheduling logic.
## Individual Comments
### Comment 1
<location path="docs/roadmap-v0.4.md" line_range="3" />
<code_context>
+# v0.4.x Roadmap — Plan de bataille
+
+> Statut : **proposed**, rédigé 2026-05-11 après research compétitive + audit codebase.
+> Auteur : @cc-gpc. À ratifier par @thierry.
+
</code_context>
<issue_to_address>
**nitpick (typo):** Clarify phrasing of "research compétitive" to avoid looking like a typo.
Since the rest of the phrase is in French, consider using "recherche compétitive" to keep the language consistent and avoid this looking like an accidental English insertion.
```suggestion
> Statut : **proposed**, rédigé 2026-05-11 après recherche compétitive + audit codebase.
```
</issue_to_address>
### Comment 2
<location path="docs/roadmap-v0.4.md" line_range="306-307" />
<code_context>
+
+## Sources internes (memory + repo)
+
+- `claude-config/memory/reference_viral_posts_research.md` — règles algo
+ Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden
+ hour LinkedIn ; longueur caption optimal par réseau)
+- `claude-config/memory/feedback_technical_ownership.md` — délégation
</code_context>
<issue_to_address>
**suggestion (typo):** Correct agreement in "longueur caption optimal par réseau".
Consider changing this to “longueur de caption optimale par réseau” so that “optimale” matches “longueur” and the missing “de” is added.
```suggestion
Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden
hour LinkedIn ; longueur de caption optimale par réseau)
```
</issue_to_address>Sourcery est gratuit pour l’open source – si nos revues vous plaisent, pensez à les partager ✨
Original comment in English
Hey - I've found 2 issues, and left some high level feedback:
- For the auto-publish scheduler, consider specifying behavior for system sleep/timezone changes (e.g., laptop asleep at publish time, DST shifts) so implementation can handle these cases deterministically rather than treating them as generic 'app fermée' scenarios.
- You define a hard-coded 24h cut-off for missed scheduled posts as 'perdu'; it may be worth calling out whether this should be user-configurable (or at least parameterized) given different workflows and timezones, so the behavior doesn’t surprise users with long planning horizons.
- Since both auto-publish and analytics use background tasks with polling, it could help to briefly outline how these schedulers will coexist (e.g., shared runner vs separate tasks, max concurrency/rate-limit strategy) to avoid future contention or duplicated scheduling logic.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- For the auto-publish scheduler, consider specifying behavior for system sleep/timezone changes (e.g., laptop asleep at publish time, DST shifts) so implementation can handle these cases deterministically rather than treating them as generic 'app fermée' scenarios.
- You define a hard-coded 24h cut-off for missed scheduled posts as 'perdu'; it may be worth calling out whether this should be user-configurable (or at least parameterized) given different workflows and timezones, so the behavior doesn’t surprise users with long planning horizons.
- Since both auto-publish and analytics use background tasks with polling, it could help to briefly outline how these schedulers will coexist (e.g., shared runner vs separate tasks, max concurrency/rate-limit strategy) to avoid future contention or duplicated scheduling logic.
## Individual Comments
### Comment 1
<location path="docs/roadmap-v0.4.md" line_range="3" />
<code_context>
+# v0.4.x Roadmap — Plan de bataille
+
+> Statut : **proposed**, rédigé 2026-05-11 après research compétitive + audit codebase.
+> Auteur : @cc-gpc. À ratifier par @thierry.
+
</code_context>
<issue_to_address>
**nitpick (typo):** Clarify phrasing of "research compétitive" to avoid looking like a typo.
Since the rest of the phrase is in French, consider using "recherche compétitive" to keep the language consistent and avoid this looking like an accidental English insertion.
```suggestion
> Statut : **proposed**, rédigé 2026-05-11 après recherche compétitive + audit codebase.
```
</issue_to_address>
### Comment 2
<location path="docs/roadmap-v0.4.md" line_range="306-307" />
<code_context>
+
+## Sources internes (memory + repo)
+
+- `claude-config/memory/reference_viral_posts_research.md` — règles algo
+ Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden
+ hour LinkedIn ; longueur caption optimal par réseau)
+- `claude-config/memory/feedback_technical_ownership.md` — délégation
</code_context>
<issue_to_address>
**suggestion (typo):** Correct agreement in "longueur caption optimal par réseau".
Consider changing this to “longueur de caption optimale par réseau” so that “optimale” matches “longueur” and the missing “de” is added.
```suggestion
Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden
hour LinkedIn ; longueur de caption optimale par réseau)
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| @@ -0,0 +1,313 @@ | |||
| # v0.4.x Roadmap — Plan de bataille | |||
|
|
|||
| > Statut : **proposed**, rédigé 2026-05-11 après research compétitive + audit codebase. | |||
There was a problem hiding this comment.
nitpick (typo): Clarifier la formulation de « research compétitive » pour éviter que cela ne ressemble à une faute de frappe.
Comme le reste de la phrase est en français, envisagez d’utiliser « recherche compétitive » afin de garder une langue cohérente et d’éviter que cela ne semble être une insertion accidentelle d’anglais.
Suggested change
| > Statut : **proposed**, rédigé 2026-05-11 après research compétitive + audit codebase. | |
| > Statut : **proposed**, rédigé 2026-05-11 après recherche compétitive + audit codebase. |
Original comment in English
nitpick (typo): Clarify phrasing of "research compétitive" to avoid looking like a typo.
Since the rest of the phrase is in French, consider using "recherche compétitive" to keep the language consistent and avoid this looking like an accidental English insertion.
Suggested change
| > Statut : **proposed**, rédigé 2026-05-11 après research compétitive + audit codebase. | |
| > Statut : **proposed**, rédigé 2026-05-11 après recherche compétitive + audit codebase. |
Comment on lines
+306
to
+307
| Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden | ||
| hour LinkedIn ; longueur caption optimal par réseau) |
There was a problem hiding this comment.
suggestion (typo): Corriger l’accord dans « longueur caption optimal par réseau ».
Vous pouvez remplacer par « longueur de caption optimale par réseau » afin que « optimale » s’accorde avec « longueur » et que le « de » manquant soit ajouté.
Suggested change
| Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden | |
| hour LinkedIn ; longueur caption optimal par réseau) | |
| Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden | |
| hour LinkedIn ; longueur de caption optimale par réseau) |
Original comment in English
suggestion (typo): Correct agreement in "longueur caption optimal par réseau".
Consider changing this to “longueur de caption optimale par réseau” so that “optimale” matches “longueur” and the missing “de” is added.
Suggested change
| Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden | |
| hour LinkedIn ; longueur caption optimal par réseau) | |
| Instagram + LinkedIn 2026 (DM shares > saves > comments > likes ; golden | |
| hour LinkedIn ; longueur de caption optimale par réseau) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Recherche → plan stratégique
Carte blanche reçue de @Thierry pour planifier v0.4.x sur la base de research plutôt que ses préférences. Quatre features prioritisées par ROI + intégration des items UX issue #62 + plan de couverture des modules sans tests.
TL;DR
v0.3.x a posé les fondations. v0.4.x ferme le gap fonctionnel sur Buffer / Later / Hypefury 2026 sans casser le moat local-first / BYOK :
Issue #62 (10 items UX) saupoudrés dans v0.4.0 / v0.4.1 / v0.4.3 selon impact-difficulté.
Test coverage : modules sans tests (
commands/calendar.rs,commands/settings.rs,adapters/instagram.rs,commands/logs.rs) attaqués au fil des PRs qui touchent ces modules + 1 PR "test sweep" v0.4.0 pour le bas-hanging.Différenciation maintenue
Tous les concurrents 2026 sont cloud + abonnement $15-99/mois. Aucune feature v0.4.x ne demande un backend cloud — tout reste local-first + BYOK (~$0.15/mois usage typique).
Calendrier
~3 semaines réelles sur v0.4.x complète au pace soutenu de v0.3.9-10 (1 PR/jour avec smoke utilisateur intercalé).
Document
docs/roadmap-v0.4.md— 313 lignes, rationale complet, success criteria par version, sources externes (Buffer/Hypefury/Later reviews 2026, Tokio scheduling patterns) + sources internes (memory research viral 2026, codebase audit).Pas de code touché. Pure docs ratifiables.
🤖 Generated with Claude Code
Summary by Sourcery
Ajouter un document complet de feuille de route produit et ingénierie v0.4.x couvrant les fonctionnalités prévues, le séquencement, la stratégie de test et les critères de réussite.
Documentation :
Original summary in English
Summary by Sourcery
Add a comprehensive v0.4.x product and engineering roadmap document covering planned features, sequencing, test strategy, and success criteria.
Documentation: