build(deps-dev): bump eslint-config-next from 16.1.6 to 16.2.2 in /web#9
Closed
dependabot[bot] wants to merge 1 commit into
Closed
build(deps-dev): bump eslint-config-next from 16.1.6 to 16.2.2 in /web#9dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [eslint-config-next](https://github.com/vercel/next.js/tree/HEAD/packages/eslint-config-next) from 16.1.6 to 16.2.2. - [Release notes](https://github.com/vercel/next.js/releases) - [Changelog](https://github.com/vercel/next.js/blob/canary/release.js) - [Commits](https://github.com/vercel/next.js/commits/v16.2.2/packages/eslint-config-next) --- updated-dependencies: - dependency-name: eslint-config-next dependency-version: 16.2.2 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
leopu00
deleted the
dependabot/npm_and_yarn/web/eslint-config-next-16.2.2
branch
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
leopu00
added a commit
that referenced
this pull request
May 17, 2026
Estrazione conversazione @mentor (6 messaggi utente, 6 risposte Mentor) e ultimi 3 messaggi Capitano sul tema. Nuovi bug: - #9 alta: skill submit-application mancante (3 draft ready 0 inviati) - #10 bassa: Mentor non ha canale tmux-send verso Capitano - #11 insight: Mentor stile conversazionale = reference positiva - #12 alta: Scout hit-rate non migliora (loop Critic→Scout assente) con strategia ε-greedy 70/30 exploit/explore - #13 bassa: Capitano invia template shell $(cat ...) non espanso Validazioni empiriche dal Capitano stesso (msg #28 00:42:25): "Sbloccare apply sui 2 draft ready — dipende da te" conferma #9. "SC-04 inviolabile" conferma #12 a livello architetturale. Update operativi successivi (msg #29-#30): proj 91% on-target, 3a candidatura PASS (Gr4vy) — pattern PASS stabile 3/3 conferma che il loop #12 è banale da iniziare. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
Terza sessione grafici on-demand del Capitano (08:59-13:45 UTC).
Salto qualitativo: prima dashboard aggregata + timeline agenti.
9 PNG portati in repo:
- pipeline_overview.png: prima dashboard JHT con bar pipeline + 4 KPI
cards + stato 7 agenti. Production-grade.
- usage_timeline_3windows.png: 3 finestre consecutive (~15h) con
usage + projection.
- usage_window_{1..5}_final.png: 5 PNG per le 5 finestre Kimi del
16-17 mag, ognuna con subplot timeline agenti sotto il grafico
usage (NUOVO: mostra quando ogni agente era attivo).
- scout2_linkedin_{canonical,yo,mbg}.png: 3 screenshot Scout-2
esplorazione LinkedIn post-RESET, tutti bloccati da cookie wall +
login. Conferma necessita source-blacklist (bug #12).
Validazioni empiriche bug emersi:
- #9 confermato visualmente: Applied=0 con Ready=12 in dashboard
- #16 rinforzato: pipeline_overview e' il template per auto-report
periodici
- #17 visibile nelle gaps timeline agenti (periodi a 0 agenti attivi)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
Conversazione 13:45-13:50 UTC: - 13:45: utente "usage settimanale a che punto sta?" -> Capitano OK - 13:46: utente "quanto manca al reset settimanale?" -> Capitano "non ho il dato preciso nel log... se lo conosci tu, dimmelo" - 13:48: utente "indaga e trovalo - hai le skill" - 13:50: Capitano grep + trova "Reset settimanale: 17:11 UTC (tra ~3h 21m)" Doppia faccia: A. sentinel-data.jsonl logga weekly_usage ma NON weekly_reset_at (solo reset_at della finestra 5h). Bridge dovrebbe estrarre anche weekly reset da UI Kimi e includerlo nel JSON tick. B. Capitano dichiara "non ho il dato" senza tentare grep/find/read sources. Le skill check_usage.py + usage_record.py ce l'avevano. Fix: A) parser bridge + nuovo campo JSON. B) regola C-06 "indaga prima di dichiarare 'non lo so'" con 4 fallback obbligatori. Famiglia con #3, #9, #17 (Capitano riconosce ma non agisce). #11 (Mentor) come reference: mai dichiara "non lo so" — fa subito query. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
Screenshot utente 2026-05-17 rivela: jobhunterteam.ai/reports mostra
9 candidature, 33% tasso risposta, TechFlow/Acme/DataWise/CloudBase/
CodeLab/NetPrime come top aziende. NESSUNA di queste aziende esiste
nel team (real: Bending Spoons, Rinse, Gr4vy, Canonical, MLabs, JUMO,
INDI, ION, Dacomat, etc.).
Causa: web/app/api/reports/route.ts e' 100% hardcoded mock. Calcoli
con Math.sin() sui seed mensili, phaseTimes hardcoded (3.2/8.5/14.1/
21.7/12.3 giorni), topCompanies inventate, avgResponseDays=5.4 fisso.
Zero createClient(), zero .from("applications").
Stato reale: 12 applications.status='ready', 0 'sent' (bug #9 mai
chiuso), 0 risposte, 0 colloqui, 0 offerte.
Impatti: (1) falsifica UX prodotto, (2) maschera bug #9 auto-nascondendolo,
(3) discredita sistema quando scoperto, (4) blocca decisioni reali del
Mentor su pattern aziende.
Fix: query supabase per applications/responses/interviews/offers
filtrate user_id+periodo. Accept che mostrera' 0 finche' bug #9 aperto.
Empty state UI esplicito.
Dipendenze: #9 (sent count), #14 (phase times). Audit collaterale su
/responses /growth /applications per altre pagine mock.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
…ic PASS Snapshot pagina /ready 2026-05-17: CV PRONTI 0, IN ATTESA CV 13. Ma Capitano dice "12 CV ready" e pipeline_overview.png mostra Ready: 12. Tre verita' diverse. Diagnosi via DB locale /jht_home/jobs.db (SQLite container): - applications: 31 totali, TUTTE status='draft' - positions: 62 excluded, 13 ready, 10 scored Pagina web e' corretta. Bug a monte: nessuno aggiorna applications.status da 'draft' a 'ready' dopo Critic PASS. Lo step di promotion semplicemente manca dal flow Scrittore->Critic->PDF. Fix opzione A: aggiungere step 4 in critic-loop/SKILL.md "su PASS, UPDATE applications SET status='ready'". Gate single-writer in db-update: "applications.status='ready' solo dal Critic". Retrofit SQL una tantum per le 12 application con verdict='PASS' attualmente in draft. Sblocca catena di 3 bug: #9 (submit-application avra' record da spedire), #20 (/reports potra' mostrare numeri reali), #14 (la promotion diventa event log). Collegato a #17 (Capitano avrebbe dovuto fare SELECT di verifica ma non lo fa mai). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
… attuali) Revisione utente 2026-05-17: #9 (submit-application) - FALSO BUG: design intenzionale "user-curated apply". JHT e' CV-tailoring assistant, non auto-applier massivo. Il team deve fermarsi a applications.status='ready', utente sceglie quale spedire e fa apply manuale. Annullato ~2 settimane di lavoro previsto. #12 (Scout hit-rate) - RIDOTTO da alta a media. Analisi nuovi dati DB (snapshot 14:30 UTC vs Mentor 12h prima): - positions: 27 -> 90 (+233%) - PASS: 2 -> 13 (+550%) - aziende PASS distinte: 2 -> 11 (+450%) - hit-rate(PASS/positions): 7% -> 14% (raddoppiato) - hit-rate(PASS/applications): 22% -> 42% (raddoppiato) Il sistema STA migliorando da solo. Non serve skill scout-strategy ad-hoc: basta formalizzare il comportamento exploration/exploitation nei prompt base degli agenti (regola SC-05 in scout.md + T14 in team-rules.md + naming canonico [STACK]/[LAUREA]/etc in critic-loop). Effort: piccolo. Riepilogo priorità aggiornato. Pattern emergente B riscritto: il vero gap di prodotto è il GATE di stato DB (#21), non la chiusura del loop end-to-end. L'utente fa l'apply manualmente by design. Aggiornate 10+ citazioni di #9 nel file (#10, #18, #20, #21 ecc) per coerenza. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
Indagine DB live: 14 Canonical su 90 posizioni totali (15%!). 2 dup confermati: job 7814327 visto 2x in 21h via canonical.com + Greenhouse. Job 2166631 visto 2x in 12h, secondo via euremotejobs reskinning. Inoltre: 9 altre aziende con duplicati 2x (Affirm, B2C2, Dacomat, Fliff, GetYourGuide, Gr4vy, ION Group, IT Partner, JUMO). URL esatto 4803615101 (Remote People) salvato 2 volte. PEGGIO: CV PDF sovrascritti. app#17 (pos#28 Canonical Observability) e app#30 (pos#62 Canonical Junior Ubuntu) puntano allo stesso path /jht_user/cv/CV_LeoneEmanuelPuglisi_Canonical.pdf. Secondo PDF sovrascrive primo. Utente apre "CV per Observability" legge contenuto "Junior Ubuntu" = data corruption silente. Fix 3 livelli: A. Scout SC-06: estrai external_id canonico (canonical:2166631) prima di INSERT, skip duplicati. Per board reskinning (euremotejobs) fetch + scraping per real source URL. B. DB: ALTER TABLE positions ADD external_id + UNIQUE INDEX. Cleanup retroattivo dei 14+9 duplicati con UPDATE status='excluded' [DEDUP]. C. Scrittore: naming CV_<name>_<pos_id>_<company-slug>_<title-slug>.pdf garantisce unicita' assoluta + retrofit 31 PDF esistenti. Impatto: 50-70% di 1 finestra Kimi (5h) sprecata su Canonical only. Rischio reputazionale per utente che fa apply manuale (#9) con CV sbagliato per la posizione. Bug correlati: #12 (source-blacklist sovrainsieme), #21, #9. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
Snapshot DB+disk 15:50 UTC rivela: 27 PDF su disk, solo 22 in DB. 5 PDF orfani = doppio problema: A. 2 PASS top-score INVISIBILI in dashboard /ready perche' cv_pdf_path=NULL: - app#20 Sisal 7.5/10 PASS (TOP score sessione!) — file esiste - app#19 Leadtech 5.5 PASS — file esiste - app#21 Canonical Commercial 5.5 PASS — no file Utente non vede 2 opportunita' lavoro valide. Sisal e' il PASS piu' alto in assoluto. B. 3 CV generati per posizioni gia' EXCLUDED/REJECT (spreco budget): - Canonical_ContainerImages (pos #34 excluded) - Canonical_K8s (pos #35 excluded) - Deloitte (REJECT Critic) Stima 3-5% di una finestra Kimi sprecata. Cause sospette: - Race Scrittore↔DB: mv PDF eseguito, UPDATE SQL fallisce. Sisal e Leadtech generati 04:30-04:43 UTC = finestra F3 con EMERGENZA freeze 07:42, plausibile kill mid-write. - Scrittore non rispetta status filter pre-generazione. Fix: W-03: atomic write PDF + DB UPDATE stessa transaction. W-04: pre-check status, ABORT se excluded/rejected. Cleanup retroattivo: UPDATE Sisal+Leadtech, archive 3 sprecati in /jht_user/cv/_excluded/. Healthcheck cv-disk-audit periodico (dipende da #18 Dottore). Bug correlati: #25 #21 #9 #18. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
…acking Ripasso #19 con scoperta strategica utente: 1. Fix A (weekly_reset_at log): resta valido, ~10 righe parser bridge. Task #55 ridotto a questo solo. 2. Fix B (C-06 indaga): cugino di #23 (leggi fonte non memoria), pattern gia' coperto. No action separato. 3. SCOPERTA: monitoraggio settimanale NON implementato di proposito. "Intenzionale, allenare team a gestire finestre". Ora finestre OK (4/5 in G-spot), tempo di salire al livello settimanale. NUOVE FEATURE estratte: F-3 Weekly budget distribution dinamica (task #64, alta, medio-grande): - candidate_profile.work_schedule con 4 mode preset + custom_slots - Helper weekly-distribute.py calcola next_window_target dinamico - Sentinella S-06: G-spot non piu' fissa 90-95% ma dinamica - 4 scenari: sprint 1.5gg, solo_notte 4gg, spalmato 7gg, weekday eve - Niente hardcoded, tutto in base preferenze utente F-4 Job offer expiration tracking (task #65, media, medio): - A. Estrazione deadline dal JD via regex (Scout/Analista) - B. Re-check periodica positions vecchie (Analista 6h refetch) - C. Alert utente proattivo "CV X scade in 2gg, spedisci" - Protezione user-curated apply (#9) da inattivita' utente Bug correlati: F-3 ↔ #15 timezone, #19 Fix A, #24 Sentinella fasi. F-4 ↔ #26 (visibility) + #9 (manual apply). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 17, 2026
Bug latente F-4: utente accumula 50 CV ready, si dimentica di applicare per 2 giorni, top opportunità (Sisal PASS 7.5) scadono in silenzio. Pipeline user-curated apply (bug #9 declassato) richiede alert proattivo sennò il valore del team viene vanificato. 3 componenti — A e C implementati, B (re-check periodica) deferred. A — shared/skills/deadline_extract.py Parser conservativo da stdin/--jd, ritorna ISO date o stringa vuota. Supporta: YYYY-MM-DD, dd/mm/yyyy EU, "Month dd[, yyyy]" EN+IT, "expires in N days" / "scade fra N giorni". 6/6 test pattern OK, "no deadline mentioned" correttamente → None (meglio NULL che inventata). C — shared/skills/expiration_alerts.py Query JOIN applications(status=ready) + positions(deadline NON NULL, < NOW()+72h). Idempotency state in $JHT_HOME/state/expiration_alerts_sent.json (set di (app_id, deadline_iso) — 1 alert per coppia, no spam giornaliero). Output 1 riga per app a rischio, pronto per jht-telegram-send. agents/_skills/expiration-tracking/SKILL.md Doc per Scout/Analista (popolare deadline al INSERT) + Mentor/Capitano (invocare alert post-tick). Anti-pattern espliciti su "no deadline → NULL" e idempotency. E2E test locale: Sisal con deadline DOMANI → alerta; Acme con deadline +10gg → silente (oltre HORIZON_DAYS=3); rerun → idempotent. Closes F-4 A+C. B (Analista re-check periodica) tracked, depende da estensione liveness-check skill. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
May 31, 2026
Sweep di coerenza dopo la chiusura di 4 P0 oggi. Trovati e fixati: cloud-sync-architecture.md: - "Gap critico noto" sul writer-on-demand offline → riformulato come "Gap critico (chiuso 2026-05-31)" — il loop pull-at-boot + tick daemon + route cloud-mode lo ha chiuso end-to-end - Sezione Pending: rimosse le 5 voci ✅ DONE che duplicavano la tabella Done sopra (creavano confusione tipo "9. ✅ già fatto" in mezzo a roba da fare). Rinumerazione sequenziale 1-14 - 2 nuove voci esplicite nella sezione Pending: P1 #9 (filtro deleted_at IS NULL su ~30 query queries.ts) e P1 #10 (cron hard- delete 30d) — erano nel commit message tombstone ma non in lista - Riferimenti incrociati fixati: "gap P1 #6 e #7" → "P1 #2 e #3"; edge case "stessa famiglia P0 #1" riformulato; "P0 #2 — CHECK SQLite commit 3602d42" → riferimento diretto al commit (P0 #2 ora è tombstone, non più CHECK) INFRA.md riga 44: nota bootstrap diceva ancora "il sync è push-only". Riscritta come "ibrido push macro-events + pull desired-state" con link al living doc. ROADMAP.md sezione "Cloud sync direction": stessa correzione, modello documentato come Kubernetes-style con riferimento al refactor 2026-05-23 + writer-on-demand 2026-05-29 + pull-desired-state 2026-05-31. Anchor [JHT-CLOUDSYNC-01] aggiunto alla lista task. BACKLOG.md voce storica [JHT-DESKTOP-SYNC]: nota inline che il modello push-only del 2026-05-13 è stato esteso (preserva la storia del task done, ma evita di disinformare chi legge oggi).
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Estrazione conversazione @mentor (6 messaggi utente, 6 risposte Mentor) e ultimi 3 messaggi Capitano sul tema. Nuovi bug: - #9 alta: skill submit-application mancante (3 draft ready 0 inviati) - #10 bassa: Mentor non ha canale tmux-send verso Capitano - #11 insight: Mentor stile conversazionale = reference positiva - #12 alta: Scout hit-rate non migliora (loop Critic→Scout assente) con strategia ε-greedy 70/30 exploit/explore - #13 bassa: Capitano invia template shell $(cat ...) non espanso Validazioni empiriche dal Capitano stesso (msg #28 00:42:25): "Sbloccare apply sui 2 draft ready — dipende da te" conferma #9. "SC-04 inviolabile" conferma #12 a livello architetturale. Update operativi successivi (msg #29-#30): proj 91% on-target, 3a candidatura PASS (Gr4vy) — pattern PASS stabile 3/3 conferma che il loop #12 è banale da iniziare. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Terza sessione grafici on-demand del Capitano (08:59-13:45 UTC).
Salto qualitativo: prima dashboard aggregata + timeline agenti.
9 PNG portati in repo:
- pipeline_overview.png: prima dashboard JHT con bar pipeline + 4 KPI
cards + stato 7 agenti. Production-grade.
- usage_timeline_3windows.png: 3 finestre consecutive (~15h) con
usage + projection.
- usage_window_{1..5}_final.png: 5 PNG per le 5 finestre Kimi del
16-17 mag, ognuna con subplot timeline agenti sotto il grafico
usage (NUOVO: mostra quando ogni agente era attivo).
- scout2_linkedin_{canonical,yo,mbg}.png: 3 screenshot Scout-2
esplorazione LinkedIn post-RESET, tutti bloccati da cookie wall +
login. Conferma necessita source-blacklist (bug #12).
Validazioni empiriche bug emersi:
- #9 confermato visualmente: Applied=0 con Ready=12 in dashboard
- #16 rinforzato: pipeline_overview e' il template per auto-report
periodici
- #17 visibile nelle gaps timeline agenti (periodi a 0 agenti attivi)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Conversazione 13:45-13:50 UTC: - 13:45: utente "usage settimanale a che punto sta?" -> Capitano OK - 13:46: utente "quanto manca al reset settimanale?" -> Capitano "non ho il dato preciso nel log... se lo conosci tu, dimmelo" - 13:48: utente "indaga e trovalo - hai le skill" - 13:50: Capitano grep + trova "Reset settimanale: 17:11 UTC (tra ~3h 21m)" Doppia faccia: A. sentinel-data.jsonl logga weekly_usage ma NON weekly_reset_at (solo reset_at della finestra 5h). Bridge dovrebbe estrarre anche weekly reset da UI Kimi e includerlo nel JSON tick. B. Capitano dichiara "non ho il dato" senza tentare grep/find/read sources. Le skill check_usage.py + usage_record.py ce l'avevano. Fix: A) parser bridge + nuovo campo JSON. B) regola C-06 "indaga prima di dichiarare 'non lo so'" con 4 fallback obbligatori. Famiglia con #3, #9, #17 (Capitano riconosce ma non agisce). #11 (Mentor) come reference: mai dichiara "non lo so" — fa subito query. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Screenshot utente 2026-05-17 rivela: jobhunterteam.ai/reports mostra
9 candidature, 33% tasso risposta, TechFlow/Acme/DataWise/CloudBase/
CodeLab/NetPrime come top aziende. NESSUNA di queste aziende esiste
nel team (real: Bending Spoons, Rinse, Gr4vy, Canonical, MLabs, JUMO,
INDI, ION, Dacomat, etc.).
Causa: web/app/api/reports/route.ts e' 100% hardcoded mock. Calcoli
con Math.sin() sui seed mensili, phaseTimes hardcoded (3.2/8.5/14.1/
21.7/12.3 giorni), topCompanies inventate, avgResponseDays=5.4 fisso.
Zero createClient(), zero .from("applications").
Stato reale: 12 applications.status='ready', 0 'sent' (bug #9 mai
chiuso), 0 risposte, 0 colloqui, 0 offerte.
Impatti: (1) falsifica UX prodotto, (2) maschera bug #9 auto-nascondendolo,
(3) discredita sistema quando scoperto, (4) blocca decisioni reali del
Mentor su pattern aziende.
Fix: query supabase per applications/responses/interviews/offers
filtrate user_id+periodo. Accept che mostrera' 0 finche' bug #9 aperto.
Empty state UI esplicito.
Dipendenze: #9 (sent count), #14 (phase times). Audit collaterale su
/responses /growth /applications per altre pagine mock.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
…ic PASS Snapshot pagina /ready 2026-05-17: CV PRONTI 0, IN ATTESA CV 13. Ma Capitano dice "12 CV ready" e pipeline_overview.png mostra Ready: 12. Tre verita' diverse. Diagnosi via DB locale /jht_home/jobs.db (SQLite container): - applications: 31 totali, TUTTE status='draft' - positions: 62 excluded, 13 ready, 10 scored Pagina web e' corretta. Bug a monte: nessuno aggiorna applications.status da 'draft' a 'ready' dopo Critic PASS. Lo step di promotion semplicemente manca dal flow Scrittore->Critic->PDF. Fix opzione A: aggiungere step 4 in critic-loop/SKILL.md "su PASS, UPDATE applications SET status='ready'". Gate single-writer in db-update: "applications.status='ready' solo dal Critic". Retrofit SQL una tantum per le 12 application con verdict='PASS' attualmente in draft. Sblocca catena di 3 bug: #9 (submit-application avra' record da spedire), #20 (/reports potra' mostrare numeri reali), #14 (la promotion diventa event log). Collegato a #17 (Capitano avrebbe dovuto fare SELECT di verifica ma non lo fa mai). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
… attuali) Revisione utente 2026-05-17: #9 (submit-application) - FALSO BUG: design intenzionale "user-curated apply". JHT e' CV-tailoring assistant, non auto-applier massivo. Il team deve fermarsi a applications.status='ready', utente sceglie quale spedire e fa apply manuale. Annullato ~2 settimane di lavoro previsto. #12 (Scout hit-rate) - RIDOTTO da alta a media. Analisi nuovi dati DB (snapshot 14:30 UTC vs Mentor 12h prima): - positions: 27 -> 90 (+233%) - PASS: 2 -> 13 (+550%) - aziende PASS distinte: 2 -> 11 (+450%) - hit-rate(PASS/positions): 7% -> 14% (raddoppiato) - hit-rate(PASS/applications): 22% -> 42% (raddoppiato) Il sistema STA migliorando da solo. Non serve skill scout-strategy ad-hoc: basta formalizzare il comportamento exploration/exploitation nei prompt base degli agenti (regola SC-05 in scout.md + T14 in team-rules.md + naming canonico [STACK]/[LAUREA]/etc in critic-loop). Effort: piccolo. Riepilogo priorità aggiornato. Pattern emergente B riscritto: il vero gap di prodotto è il GATE di stato DB (#21), non la chiusura del loop end-to-end. L'utente fa l'apply manualmente by design. Aggiornate 10+ citazioni di #9 nel file (#10, #18, #20, #21 ecc) per coerenza. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Indagine DB live: 14 Canonical su 90 posizioni totali (15%!). 2 dup confermati: job 7814327 visto 2x in 21h via canonical.com + Greenhouse. Job 2166631 visto 2x in 12h, secondo via euremotejobs reskinning. Inoltre: 9 altre aziende con duplicati 2x (Affirm, B2C2, Dacomat, Fliff, GetYourGuide, Gr4vy, ION Group, IT Partner, JUMO). URL esatto 4803615101 (Remote People) salvato 2 volte. PEGGIO: CV PDF sovrascritti. app#17 (pos#28 Canonical Observability) e app#30 (pos#62 Canonical Junior Ubuntu) puntano allo stesso path /jht_user/cv/CV_LeoneEmanuelPuglisi_Canonical.pdf. Secondo PDF sovrascrive primo. Utente apre "CV per Observability" legge contenuto "Junior Ubuntu" = data corruption silente. Fix 3 livelli: A. Scout SC-06: estrai external_id canonico (canonical:2166631) prima di INSERT, skip duplicati. Per board reskinning (euremotejobs) fetch + scraping per real source URL. B. DB: ALTER TABLE positions ADD external_id + UNIQUE INDEX. Cleanup retroattivo dei 14+9 duplicati con UPDATE status='excluded' [DEDUP]. C. Scrittore: naming CV_<name>_<pos_id>_<company-slug>_<title-slug>.pdf garantisce unicita' assoluta + retrofit 31 PDF esistenti. Impatto: 50-70% di 1 finestra Kimi (5h) sprecata su Canonical only. Rischio reputazionale per utente che fa apply manuale (#9) con CV sbagliato per la posizione. Bug correlati: #12 (source-blacklist sovrainsieme), #21, #9. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Snapshot DB+disk 15:50 UTC rivela: 27 PDF su disk, solo 22 in DB. 5 PDF orfani = doppio problema: A. 2 PASS top-score INVISIBILI in dashboard /ready perche' cv_pdf_path=NULL: - app#20 Sisal 7.5/10 PASS (TOP score sessione!) — file esiste - app#19 Leadtech 5.5 PASS — file esiste - app#21 Canonical Commercial 5.5 PASS — no file Utente non vede 2 opportunita' lavoro valide. Sisal e' il PASS piu' alto in assoluto. B. 3 CV generati per posizioni gia' EXCLUDED/REJECT (spreco budget): - Canonical_ContainerImages (pos #34 excluded) - Canonical_K8s (pos #35 excluded) - Deloitte (REJECT Critic) Stima 3-5% di una finestra Kimi sprecata. Cause sospette: - Race Scrittore↔DB: mv PDF eseguito, UPDATE SQL fallisce. Sisal e Leadtech generati 04:30-04:43 UTC = finestra F3 con EMERGENZA freeze 07:42, plausibile kill mid-write. - Scrittore non rispetta status filter pre-generazione. Fix: W-03: atomic write PDF + DB UPDATE stessa transaction. W-04: pre-check status, ABORT se excluded/rejected. Cleanup retroattivo: UPDATE Sisal+Leadtech, archive 3 sprecati in /jht_user/cv/_excluded/. Healthcheck cv-disk-audit periodico (dipende da #18 Dottore). Bug correlati: #25 #21 #9 #18. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
…acking Ripasso #19 con scoperta strategica utente: 1. Fix A (weekly_reset_at log): resta valido, ~10 righe parser bridge. Task #55 ridotto a questo solo. 2. Fix B (C-06 indaga): cugino di #23 (leggi fonte non memoria), pattern gia' coperto. No action separato. 3. SCOPERTA: monitoraggio settimanale NON implementato di proposito. "Intenzionale, allenare team a gestire finestre". Ora finestre OK (4/5 in G-spot), tempo di salire al livello settimanale. NUOVE FEATURE estratte: F-3 Weekly budget distribution dinamica (task #64, alta, medio-grande): - candidate_profile.work_schedule con 4 mode preset + custom_slots - Helper weekly-distribute.py calcola next_window_target dinamico - Sentinella S-06: G-spot non piu' fissa 90-95% ma dinamica - 4 scenari: sprint 1.5gg, solo_notte 4gg, spalmato 7gg, weekday eve - Niente hardcoded, tutto in base preferenze utente F-4 Job offer expiration tracking (task #65, media, medio): - A. Estrazione deadline dal JD via regex (Scout/Analista) - B. Re-check periodica positions vecchie (Analista 6h refetch) - C. Alert utente proattivo "CV X scade in 2gg, spedisci" - Protezione user-curated apply (#9) da inattivita' utente Bug correlati: F-3 ↔ #15 timezone, #19 Fix A, #24 Sentinella fasi. F-4 ↔ #26 (visibility) + #9 (manual apply). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Bug latente F-4: utente accumula 50 CV ready, si dimentica di applicare per 2 giorni, top opportunità (Sisal PASS 7.5) scadono in silenzio. Pipeline user-curated apply (bug #9 declassato) richiede alert proattivo sennò il valore del team viene vanificato. 3 componenti — A e C implementati, B (re-check periodica) deferred. A — shared/skills/deadline_extract.py Parser conservativo da stdin/--jd, ritorna ISO date o stringa vuota. Supporta: YYYY-MM-DD, dd/mm/yyyy EU, "Month dd[, yyyy]" EN+IT, "expires in N days" / "scade fra N giorni". 6/6 test pattern OK, "no deadline mentioned" correttamente → None (meglio NULL che inventata). C — shared/skills/expiration_alerts.py Query JOIN applications(status=ready) + positions(deadline NON NULL, < NOW()+72h). Idempotency state in $JHT_HOME/state/expiration_alerts_sent.json (set di (app_id, deadline_iso) — 1 alert per coppia, no spam giornaliero). Output 1 riga per app a rischio, pronto per jht-telegram-send. agents/_skills/expiration-tracking/SKILL.md Doc per Scout/Analista (popolare deadline al INSERT) + Mentor/Capitano (invocare alert post-tick). Anti-pattern espliciti su "no deadline → NULL" e idempotency. E2E test locale: Sisal con deadline DOMANI → alerta; Acme con deadline +10gg → silente (oltre HORIZON_DAYS=3); rerun → idempotent. Closes F-4 A+C. B (Analista re-check periodica) tracked, depende da estensione liveness-check skill. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Sweep di coerenza dopo la chiusura di 4 P0 oggi. Trovati e fixati: cloud-sync-architecture.md: - "Gap critico noto" sul writer-on-demand offline → riformulato come "Gap critico (chiuso 2026-05-31)" — il loop pull-at-boot + tick daemon + route cloud-mode lo ha chiuso end-to-end - Sezione Pending: rimosse le 5 voci ✅ DONE che duplicavano la tabella Done sopra (creavano confusione tipo "9. ✅ già fatto" in mezzo a roba da fare). Rinumerazione sequenziale 1-14 - 2 nuove voci esplicite nella sezione Pending: P1 #9 (filtro deleted_at IS NULL su ~30 query queries.ts) e P1 #10 (cron hard- delete 30d) — erano nel commit message tombstone ma non in lista - Riferimenti incrociati fixati: "gap P1 #6 e #7" → "P1 #2 e #3"; edge case "stessa famiglia P0 #1" riformulato; "P0 #2 — CHECK SQLite commit 9e37932" → riferimento diretto al commit (P0 #2 ora è tombstone, non più CHECK) INFRA.md riga 44: nota bootstrap diceva ancora "il sync è push-only". Riscritta come "ibrido push macro-events + pull desired-state" con link al living doc. ROADMAP.md sezione "Cloud sync direction": stessa correzione, modello documentato come Kubernetes-style con riferimento al refactor 2026-05-23 + writer-on-demand 2026-05-29 + pull-desired-state 2026-05-31. Anchor [JHT-CLOUDSYNC-01] aggiunto alla lista task. BACKLOG.md voce storica [JHT-DESKTOP-SYNC]: nota inline che il modello push-only del 2026-05-13 è stato esteso (preserva la storia del task done, ma evita di disinformare chi legge oggi).
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
…ontainer (#9) handleSimulate chiamava sempre 'docker exec jht python3 ...', ma il wrapper jht esegue gia DENTRO il container (JHT_SHELL_VIA=docker:jht) dove il binario docker non esiste → 'spawn docker ENOENT' (mentre gli altri sottocomandi jht girano python diretto e funzionano). dockerExec ora rileva il contesto via existsSync('/app/shared/skills'): dentro il container esegue il comando diretto, solo dall'host vero passa da docker exec. Tracker #9. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Estrazione conversazione @mentor (6 messaggi utente, 6 risposte Mentor) e ultimi 3 messaggi Capitano sul tema. Nuovi bug: - #9 alta: skill submit-application mancante (3 draft ready 0 inviati) - #10 bassa: Mentor non ha canale tmux-send verso Capitano - #11 insight: Mentor stile conversazionale = reference positiva - #12 alta: Scout hit-rate non migliora (loop Critic→Scout assente) con strategia ε-greedy 70/30 exploit/explore - #13 bassa: Capitano invia template shell $(cat ...) non espanso Validazioni empiriche dal Capitano stesso (msg #28 00:42:25): "Sbloccare apply sui 2 draft ready — dipende da te" conferma #9. "SC-04 inviolabile" conferma #12 a livello architetturale. Update operativi successivi (msg #29-#30): proj 91% on-target, 3a candidatura PASS (Gr4vy) — pattern PASS stabile 3/3 conferma che il loop #12 è banale da iniziare. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Terza sessione grafici on-demand del Capitano (08:59-13:45 UTC).
Salto qualitativo: prima dashboard aggregata + timeline agenti.
9 PNG portati in repo:
- pipeline_overview.png: prima dashboard JHT con bar pipeline + 4 KPI
cards + stato 7 agenti. Production-grade.
- usage_timeline_3windows.png: 3 finestre consecutive (~15h) con
usage + projection.
- usage_window_{1..5}_final.png: 5 PNG per le 5 finestre Kimi del
16-17 mag, ognuna con subplot timeline agenti sotto il grafico
usage (NUOVO: mostra quando ogni agente era attivo).
- scout2_linkedin_{canonical,yo,mbg}.png: 3 screenshot Scout-2
esplorazione LinkedIn post-RESET, tutti bloccati da cookie wall +
login. Conferma necessita source-blacklist (bug #12).
Validazioni empiriche bug emersi:
- #9 confermato visualmente: Applied=0 con Ready=12 in dashboard
- #16 rinforzato: pipeline_overview e' il template per auto-report
periodici
- #17 visibile nelle gaps timeline agenti (periodi a 0 agenti attivi)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Conversazione 13:45-13:50 UTC: - 13:45: utente "usage settimanale a che punto sta?" -> Capitano OK - 13:46: utente "quanto manca al reset settimanale?" -> Capitano "non ho il dato preciso nel log... se lo conosci tu, dimmelo" - 13:48: utente "indaga e trovalo - hai le skill" - 13:50: Capitano grep + trova "Reset settimanale: 17:11 UTC (tra ~3h 21m)" Doppia faccia: A. sentinel-data.jsonl logga weekly_usage ma NON weekly_reset_at (solo reset_at della finestra 5h). Bridge dovrebbe estrarre anche weekly reset da UI Kimi e includerlo nel JSON tick. B. Capitano dichiara "non ho il dato" senza tentare grep/find/read sources. Le skill check_usage.py + usage_record.py ce l'avevano. Fix: A) parser bridge + nuovo campo JSON. B) regola C-06 "indaga prima di dichiarare 'non lo so'" con 4 fallback obbligatori. Famiglia con #3, #9, #17 (Capitano riconosce ma non agisce). #11 (Mentor) come reference: mai dichiara "non lo so" — fa subito query. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Screenshot utente 2026-05-17 rivela: jobhunterteam.ai/reports mostra
9 candidature, 33% tasso risposta, TechFlow/Acme/DataWise/CloudBase/
CodeLab/NetPrime come top aziende. NESSUNA di queste aziende esiste
nel team (real: Bending Spoons, Rinse, Gr4vy, Company 033, MLabs, JUMO,
INDI, ION, Dacomat, etc.).
Causa: web/app/api/reports/route.ts e' 100% hardcoded mock. Calcoli
con Math.sin() sui seed mensili, phaseTimes hardcoded (3.2/8.5/14.1/
21.7/12.3 giorni), topCompanies inventate, avgResponseDays=5.4 fisso.
Zero createClient(), zero .from("applications").
Stato reale: 12 applications.status='ready', 0 'sent' (bug #9 mai
chiuso), 0 risposte, 0 colloqui, 0 offerte.
Impatti: (1) falsifica UX prodotto, (2) maschera bug #9 auto-nascondendolo,
(3) discredita sistema quando scoperto, (4) blocca decisioni reali del
Mentor su pattern aziende.
Fix: query supabase per applications/responses/interviews/offers
filtrate user_id+periodo. Accept che mostrera' 0 finche' bug #9 aperto.
Empty state UI esplicito.
Dipendenze: #9 (sent count), #14 (phase times). Audit collaterale su
/responses /growth /applications per altre pagine mock.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
…ic PASS Snapshot pagina /ready 2026-05-17: CV PRONTI 0, IN ATTESA CV 13. Ma Capitano dice "12 CV ready" e pipeline_overview.png mostra Ready: 12. Tre verita' diverse. Diagnosi via DB locale /jht_home/jobs.db (SQLite container): - applications: 31 totali, TUTTE status='draft' - positions: 62 excluded, 13 ready, 10 scored Pagina web e' corretta. Bug a monte: nessuno aggiorna applications.status da 'draft' a 'ready' dopo Critic PASS. Lo step di promotion semplicemente manca dal flow Scrittore->Critic->PDF. Fix opzione A: aggiungere step 4 in critic-loop/SKILL.md "su PASS, UPDATE applications SET status='ready'". Gate single-writer in db-update: "applications.status='ready' solo dal Critic". Retrofit SQL una tantum per le 12 application con verdict='PASS' attualmente in draft. Sblocca catena di 3 bug: #9 (submit-application avra' record da spedire), #20 (/reports potra' mostrare numeri reali), #14 (la promotion diventa event log). Collegato a #17 (Capitano avrebbe dovuto fare SELECT di verifica ma non lo fa mai). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
… attuali) Revisione utente 2026-05-17: #9 (submit-application) - FALSO BUG: design intenzionale "user-curated apply". JHT e' CV-tailoring assistant, non auto-applier massivo. Il team deve fermarsi a applications.status='ready', utente sceglie quale spedire e fa apply manuale. Annullato ~2 settimane di lavoro previsto. #12 (Scout hit-rate) - RIDOTTO da alta a media. Analisi nuovi dati DB (snapshot 14:30 UTC vs Mentor 12h prima): - positions: 27 -> 90 (+233%) - PASS: 2 -> 13 (+550%) - aziende PASS distinte: 2 -> 11 (+450%) - hit-rate(PASS/positions): 7% -> 14% (raddoppiato) - hit-rate(PASS/applications): 22% -> 42% (raddoppiato) Il sistema STA migliorando da solo. Non serve skill scout-strategy ad-hoc: basta formalizzare il comportamento exploration/exploitation nei prompt base degli agenti (regola SC-05 in scout.md + T14 in team-rules.md + naming canonico [STACK]/[LAUREA]/etc in critic-loop). Effort: piccolo. Riepilogo priorità aggiornato. Pattern emergente B riscritto: il vero gap di prodotto è il GATE di stato DB (#21), non la chiusura del loop end-to-end. L'utente fa l'apply manualmente by design. Aggiornate 10+ citazioni di #9 nel file (#10, #18, #20, #21 ecc) per coerenza. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Indagine DB live: 14 Company 033 su 90 posizioni totali (15%!). 2 dup confermati: job 7814327 visto 2x in 21h via canonical.com + Greenhouse. Job 2166631 visto 2x in 12h, secondo via euremotejobs reskinning. Inoltre: 9 altre aziende con duplicati 2x (Affirm, B2C2, Dacomat, Fliff, GetYourGuide, Gr4vy, ION Group, IT Partner, JUMO). URL esatto 4803615101 (Remote People) salvato 2 volte. PEGGIO: CV PDF sovrascritti. app#17 (pos#28 Company 033 Observability) e app#30 (pos#62 Company 033 Junior Ubuntu) puntano allo stesso path /jht_user/cv/CV_LeoneEmanuelPuglisi_Company 033.pdf. Secondo PDF sovrascrive primo. Utente apre "CV per Observability" legge contenuto "Junior Ubuntu" = data corruption silente. Fix 3 livelli: A. Scout SC-06: estrai external_id canonico (canonical:2166631) prima di INSERT, skip duplicati. Per board reskinning (euremotejobs) fetch + scraping per real source URL. B. DB: ALTER TABLE positions ADD external_id + UNIQUE INDEX. Cleanup retroattivo dei 14+9 duplicati con UPDATE status='excluded' [DEDUP]. C. Scrittore: naming CV_<name>_<pos_id>_<company-slug>_<title-slug>.pdf garantisce unicita' assoluta + retrofit 31 PDF esistenti. Impatto: 50-70% di 1 finestra Kimi (5h) sprecata su Company 033 only. Rischio reputazionale per utente che fa apply manuale (#9) con CV sbagliato per la posizione. Bug correlati: #12 (source-blacklist sovrainsieme), #21, #9. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Snapshot DB+disk 15:50 UTC rivela: 27 PDF su disk, solo 22 in DB. 5 PDF orfani = doppio problema: A. 2 PASS top-score INVISIBILI in dashboard /ready perche' cv_pdf_path=NULL: - app#20 Sisal 7.5/10 PASS (TOP score sessione!) — file esiste - app#19 Leadtech 5.5 PASS — file esiste - app#21 Company 033 Commercial 5.5 PASS — no file Utente non vede 2 opportunita' lavoro valide. Sisal e' il PASS piu' alto in assoluto. B. 3 CV generati per posizioni gia' EXCLUDED/REJECT (spreco budget): - Company 033_ContainerImages (pos #34 excluded) - Company 033_K8s (pos #35 excluded) - Deloitte (REJECT Critic) Stima 3-5% di una finestra Kimi sprecata. Cause sospette: - Race Scrittore↔DB: mv PDF eseguito, UPDATE SQL fallisce. Sisal e Leadtech generati 04:30-04:43 UTC = finestra F3 con EMERGENZA freeze 07:42, plausibile kill mid-write. - Scrittore non rispetta status filter pre-generazione. Fix: W-03: atomic write PDF + DB UPDATE stessa transaction. W-04: pre-check status, ABORT se excluded/rejected. Cleanup retroattivo: UPDATE Sisal+Leadtech, archive 3 sprecati in /jht_user/cv/_excluded/. Healthcheck cv-disk-audit periodico (dipende da #18 Dottore). Bug correlati: #25 #21 #9 #18. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
…acking Ripasso #19 con scoperta strategica utente: 1. Fix A (weekly_reset_at log): resta valido, ~10 righe parser bridge. Task #55 ridotto a questo solo. 2. Fix B (C-06 indaga): cugino di #23 (leggi fonte non memoria), pattern gia' coperto. No action separato. 3. SCOPERTA: monitoraggio settimanale NON implementato di proposito. "Intenzionale, allenare team a gestire finestre". Ora finestre OK (4/5 in G-spot), tempo di salire al livello settimanale. NUOVE FEATURE estratte: F-3 Weekly budget distribution dinamica (task #64, alta, medio-grande): - candidate_profile.work_schedule con 4 mode preset + custom_slots - Helper weekly-distribute.py calcola next_window_target dinamico - Sentinella S-06: G-spot non piu' fissa 90-95% ma dinamica - 4 scenari: sprint 1.5gg, solo_notte 4gg, spalmato 7gg, weekday eve - Niente hardcoded, tutto in base preferenze utente F-4 Job offer expiration tracking (task #65, media, medio): - A. Estrazione deadline dal JD via regex (Scout/Analista) - B. Re-check periodica positions vecchie (Analista 6h refetch) - C. Alert utente proattivo "CV X scade in 2gg, spedisci" - Protezione user-curated apply (#9) da inattivita' utente Bug correlati: F-3 ↔ #15 timezone, #19 Fix A, #24 Sentinella fasi. F-4 ↔ #26 (visibility) + #9 (manual apply). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Bug latente F-4: utente accumula 50 CV ready, si dimentica di applicare per 2 giorni, top opportunità (Sisal PASS 7.5) scadono in silenzio. Pipeline user-curated apply (bug #9 declassato) richiede alert proattivo sennò il valore del team viene vanificato. 3 componenti — A e C implementati, B (re-check periodica) deferred. A — shared/skills/deadline_extract.py Parser conservativo da stdin/--jd, ritorna ISO date o stringa vuota. Supporta: YYYY-MM-DD, dd/mm/yyyy EU, "Month dd[, yyyy]" EN+IT, "expires in N days" / "scade fra N giorni". 6/6 test pattern OK, "no deadline mentioned" correttamente → None (meglio NULL che inventata). C — shared/skills/expiration_alerts.py Query JOIN applications(status=ready) + positions(deadline NON NULL, < NOW()+72h). Idempotency state in $JHT_HOME/state/expiration_alerts_sent.json (set di (app_id, deadline_iso) — 1 alert per coppia, no spam giornaliero). Output 1 riga per app a rischio, pronto per jht-telegram-send. agents/_skills/expiration-tracking/SKILL.md Doc per Scout/Analista (popolare deadline al INSERT) + Mentor/Capitano (invocare alert post-tick). Anti-pattern espliciti su "no deadline → NULL" e idempotency. E2E test locale: Sisal con deadline DOMANI → alerta; Acme con deadline +10gg → silente (oltre HORIZON_DAYS=3); rerun → idempotent. Closes F-4 A+C. B (Analista re-check periodica) tracked, depende da estensione liveness-check skill. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
Sweep di coerenza dopo la chiusura di 4 P0 oggi. Trovati e fixati: cloud-sync-architecture.md: - "Gap critico noto" sul writer-on-demand offline → riformulato come "Gap critico (chiuso 2026-05-31)" — il loop pull-at-boot + tick daemon + route cloud-mode lo ha chiuso end-to-end - Sezione Pending: rimosse le 5 voci ✅ DONE che duplicavano la tabella Done sopra (creavano confusione tipo "9. ✅ già fatto" in mezzo a roba da fare). Rinumerazione sequenziale 1-14 - 2 nuove voci esplicite nella sezione Pending: P1 #9 (filtro deleted_at IS NULL su ~30 query queries.ts) e P1 #10 (cron hard- delete 30d) — erano nel commit message tombstone ma non in lista - Riferimenti incrociati fixati: "gap P1 #6 e #7" → "P1 #2 e #3"; edge case "stessa famiglia P0 #1" riformulato; "P0 #2 — CHECK SQLite commit bc071c5" → riferimento diretto al commit (P0 #2 ora è tombstone, non più CHECK) INFRA.md riga 44: nota bootstrap diceva ancora "il sync è push-only". Riscritta come "ibrido push macro-events + pull desired-state" con link al living doc. ROADMAP.md sezione "Cloud sync direction": stessa correzione, modello documentato come Kubernetes-style con riferimento al refactor 2026-05-23 + writer-on-demand 2026-05-29 + pull-desired-state 2026-05-31. Anchor [JHT-CLOUDSYNC-01] aggiunto alla lista task. BACKLOG.md voce storica [JHT-DESKTOP-SYNC]: nota inline che il modello push-only del 2026-05-13 è stato esteso (preserva la storia del task done, ma evita di disinformare chi legge oggi).
leopu00
added a commit
that referenced
this pull request
Jun 4, 2026
…ontainer (#9) handleSimulate chiamava sempre 'docker exec jht python3 ...', ma il wrapper jht esegue gia DENTRO il container (JHT_SHELL_VIA=docker:jht) dove il binario docker non esiste → 'spawn docker ENOENT' (mentre gli altri sottocomandi jht girano python diretto e funzionano). dockerExec ora rileva il contesto via existsSync('/app/shared/skills'): dentro il container esegue il comando diretto, solo dall'host vero passa da docker exec. Tracker #9. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Bumps eslint-config-next from 16.1.6 to 16.2.2.
Release notes
Sourced from eslint-config-next's releases.
... (truncated)
Commits
52faae3v16.2.2ed7d2cev16.2.1c5c94dfv16.2.03683192v16.2.0-canary.1046689814v16.2.0-canary.103ad66dbcv16.2.0-canary.102b856498v16.2.0-canary.101136b77ev16.2.0-canary.1000f59973v16.2.0-canary.99792522dv16.2.0-canary.98Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)