instar 1.3.181 → 1.3.182
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/commands/server.d.ts.map +1 -1
- package/dist/commands/server.js +18 -22
- package/dist/commands/server.js.map +1 -1
- package/dist/core/TelegramRelay.d.ts +52 -0
- package/dist/core/TelegramRelay.d.ts.map +1 -0
- package/dist/core/TelegramRelay.js +80 -0
- package/dist/core/TelegramRelay.js.map +1 -0
- package/dist/server/routes.d.ts.map +1 -1
- package/dist/server/routes.js +7 -2
- package/dist/server/routes.js.map +1 -1
- package/package.json +1 -1
- package/src/data/builtin-manifest.json +46 -46
- package/upgrades/1.3.180.md +58 -45
- package/upgrades/1.3.182.md +59 -0
- package/upgrades/side-effects/telegram-relay-timeout-observability.md +37 -0
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "./builtin-manifest.schema.json",
|
|
3
3
|
"schemaVersion": 1,
|
|
4
|
-
"generatedAt": "2026-06-
|
|
5
|
-
"instarVersion": "1.3.
|
|
4
|
+
"generatedAt": "2026-06-01T04:23:33.472Z",
|
|
5
|
+
"instarVersion": "1.3.182",
|
|
6
6
|
"entryCount": 193,
|
|
7
7
|
"entries": {
|
|
8
8
|
"hook:session-start": {
|
|
@@ -409,7 +409,7 @@
|
|
|
409
409
|
"type": "route-group",
|
|
410
410
|
"domain": "monitoring",
|
|
411
411
|
"sourcePath": "src/server/routes.ts",
|
|
412
|
-
"contentHash": "
|
|
412
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
413
413
|
"since": "2025-01-01"
|
|
414
414
|
},
|
|
415
415
|
"route-group:agents": {
|
|
@@ -417,7 +417,7 @@
|
|
|
417
417
|
"type": "route-group",
|
|
418
418
|
"domain": "sessions",
|
|
419
419
|
"sourcePath": "src/server/routes.ts",
|
|
420
|
-
"contentHash": "
|
|
420
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
421
421
|
"since": "2025-01-01"
|
|
422
422
|
},
|
|
423
423
|
"route-group:backups": {
|
|
@@ -425,7 +425,7 @@
|
|
|
425
425
|
"type": "route-group",
|
|
426
426
|
"domain": "operations",
|
|
427
427
|
"sourcePath": "src/server/routes.ts",
|
|
428
|
-
"contentHash": "
|
|
428
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
429
429
|
"since": "2025-01-01"
|
|
430
430
|
},
|
|
431
431
|
"route-group:git": {
|
|
@@ -433,7 +433,7 @@
|
|
|
433
433
|
"type": "route-group",
|
|
434
434
|
"domain": "coordination",
|
|
435
435
|
"sourcePath": "src/server/routes.ts",
|
|
436
|
-
"contentHash": "
|
|
436
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
437
437
|
"since": "2025-01-01"
|
|
438
438
|
},
|
|
439
439
|
"route-group:memory": {
|
|
@@ -441,7 +441,7 @@
|
|
|
441
441
|
"type": "route-group",
|
|
442
442
|
"domain": "memory",
|
|
443
443
|
"sourcePath": "src/server/routes.ts",
|
|
444
|
-
"contentHash": "
|
|
444
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
445
445
|
"since": "2025-01-01"
|
|
446
446
|
},
|
|
447
447
|
"route-group:semantic": {
|
|
@@ -449,7 +449,7 @@
|
|
|
449
449
|
"type": "route-group",
|
|
450
450
|
"domain": "memory",
|
|
451
451
|
"sourcePath": "src/server/routes.ts",
|
|
452
|
-
"contentHash": "
|
|
452
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
453
453
|
"since": "2025-01-01"
|
|
454
454
|
},
|
|
455
455
|
"route-group:status": {
|
|
@@ -457,7 +457,7 @@
|
|
|
457
457
|
"type": "route-group",
|
|
458
458
|
"domain": "monitoring",
|
|
459
459
|
"sourcePath": "src/server/routes.ts",
|
|
460
|
-
"contentHash": "
|
|
460
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
461
461
|
"since": "2025-01-01"
|
|
462
462
|
},
|
|
463
463
|
"route-group:capabilities": {
|
|
@@ -465,7 +465,7 @@
|
|
|
465
465
|
"type": "route-group",
|
|
466
466
|
"domain": "mapping",
|
|
467
467
|
"sourcePath": "src/server/routes.ts",
|
|
468
|
-
"contentHash": "
|
|
468
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
469
469
|
"since": "2025-01-01"
|
|
470
470
|
},
|
|
471
471
|
"route-group:project-map": {
|
|
@@ -473,7 +473,7 @@
|
|
|
473
473
|
"type": "route-group",
|
|
474
474
|
"domain": "mapping",
|
|
475
475
|
"sourcePath": "src/server/routes.ts",
|
|
476
|
-
"contentHash": "
|
|
476
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
477
477
|
"since": "2025-01-01"
|
|
478
478
|
},
|
|
479
479
|
"route-group:coherence": {
|
|
@@ -481,7 +481,7 @@
|
|
|
481
481
|
"type": "route-group",
|
|
482
482
|
"domain": "coherence",
|
|
483
483
|
"sourcePath": "src/server/routes.ts",
|
|
484
|
-
"contentHash": "
|
|
484
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
485
485
|
"since": "2025-01-01"
|
|
486
486
|
},
|
|
487
487
|
"route-group:topic-bindings": {
|
|
@@ -489,7 +489,7 @@
|
|
|
489
489
|
"type": "route-group",
|
|
490
490
|
"domain": "sessions",
|
|
491
491
|
"sourcePath": "src/server/routes.ts",
|
|
492
|
-
"contentHash": "
|
|
492
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
493
493
|
"since": "2025-01-01"
|
|
494
494
|
},
|
|
495
495
|
"route-group:context": {
|
|
@@ -497,7 +497,7 @@
|
|
|
497
497
|
"type": "route-group",
|
|
498
498
|
"domain": "context",
|
|
499
499
|
"sourcePath": "src/server/routes.ts",
|
|
500
|
-
"contentHash": "
|
|
500
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
501
501
|
"since": "2025-01-01"
|
|
502
502
|
},
|
|
503
503
|
"route-group:scope-coherence": {
|
|
@@ -505,7 +505,7 @@
|
|
|
505
505
|
"type": "route-group",
|
|
506
506
|
"domain": "coherence",
|
|
507
507
|
"sourcePath": "src/server/routes.ts",
|
|
508
|
-
"contentHash": "
|
|
508
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
509
509
|
"since": "2025-01-01"
|
|
510
510
|
},
|
|
511
511
|
"route-group:canonical-state": {
|
|
@@ -513,7 +513,7 @@
|
|
|
513
513
|
"type": "route-group",
|
|
514
514
|
"domain": "state",
|
|
515
515
|
"sourcePath": "src/server/routes.ts",
|
|
516
|
-
"contentHash": "
|
|
516
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
517
517
|
"since": "2025-01-01"
|
|
518
518
|
},
|
|
519
519
|
"route-group:ci": {
|
|
@@ -521,7 +521,7 @@
|
|
|
521
521
|
"type": "route-group",
|
|
522
522
|
"domain": "monitoring",
|
|
523
523
|
"sourcePath": "src/server/routes.ts",
|
|
524
|
-
"contentHash": "
|
|
524
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
525
525
|
"since": "2025-01-01"
|
|
526
526
|
},
|
|
527
527
|
"route-group:sessions": {
|
|
@@ -529,7 +529,7 @@
|
|
|
529
529
|
"type": "route-group",
|
|
530
530
|
"domain": "sessions",
|
|
531
531
|
"sourcePath": "src/server/routes.ts",
|
|
532
|
-
"contentHash": "
|
|
532
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
533
533
|
"since": "2025-01-01"
|
|
534
534
|
},
|
|
535
535
|
"route-group:jobs": {
|
|
@@ -537,7 +537,7 @@
|
|
|
537
537
|
"type": "route-group",
|
|
538
538
|
"domain": "scheduling",
|
|
539
539
|
"sourcePath": "src/server/routes.ts",
|
|
540
|
-
"contentHash": "
|
|
540
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
541
541
|
"since": "2025-01-01"
|
|
542
542
|
},
|
|
543
543
|
"route-group:skip-ledger": {
|
|
@@ -545,7 +545,7 @@
|
|
|
545
545
|
"type": "route-group",
|
|
546
546
|
"domain": "scheduling",
|
|
547
547
|
"sourcePath": "src/server/routes.ts",
|
|
548
|
-
"contentHash": "
|
|
548
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
549
549
|
"since": "2025-01-01"
|
|
550
550
|
},
|
|
551
551
|
"route-group:telegram": {
|
|
@@ -553,7 +553,7 @@
|
|
|
553
553
|
"type": "route-group",
|
|
554
554
|
"domain": "communication",
|
|
555
555
|
"sourcePath": "src/server/routes.ts",
|
|
556
|
-
"contentHash": "
|
|
556
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
557
557
|
"since": "2025-01-01"
|
|
558
558
|
},
|
|
559
559
|
"route-group:attention": {
|
|
@@ -561,7 +561,7 @@
|
|
|
561
561
|
"type": "route-group",
|
|
562
562
|
"domain": "communication",
|
|
563
563
|
"sourcePath": "src/server/routes.ts",
|
|
564
|
-
"contentHash": "
|
|
564
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
565
565
|
"since": "2025-01-01"
|
|
566
566
|
},
|
|
567
567
|
"route-group:relationships": {
|
|
@@ -569,7 +569,7 @@
|
|
|
569
569
|
"type": "route-group",
|
|
570
570
|
"domain": "relationships",
|
|
571
571
|
"sourcePath": "src/server/routes.ts",
|
|
572
|
-
"contentHash": "
|
|
572
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
573
573
|
"since": "2025-01-01"
|
|
574
574
|
},
|
|
575
575
|
"route-group:feedback": {
|
|
@@ -577,7 +577,7 @@
|
|
|
577
577
|
"type": "route-group",
|
|
578
578
|
"domain": "feedback",
|
|
579
579
|
"sourcePath": "src/server/routes.ts",
|
|
580
|
-
"contentHash": "
|
|
580
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
581
581
|
"since": "2025-01-01"
|
|
582
582
|
},
|
|
583
583
|
"route-group:updates": {
|
|
@@ -585,7 +585,7 @@
|
|
|
585
585
|
"type": "route-group",
|
|
586
586
|
"domain": "updates",
|
|
587
587
|
"sourcePath": "src/server/routes.ts",
|
|
588
|
-
"contentHash": "
|
|
588
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
589
589
|
"since": "2025-01-01"
|
|
590
590
|
},
|
|
591
591
|
"route-group:dispatches": {
|
|
@@ -593,7 +593,7 @@
|
|
|
593
593
|
"type": "route-group",
|
|
594
594
|
"domain": "dispatches",
|
|
595
595
|
"sourcePath": "src/server/routes.ts",
|
|
596
|
-
"contentHash": "
|
|
596
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
597
597
|
"since": "2025-01-01"
|
|
598
598
|
},
|
|
599
599
|
"route-group:quota": {
|
|
@@ -601,7 +601,7 @@
|
|
|
601
601
|
"type": "route-group",
|
|
602
602
|
"domain": "monitoring",
|
|
603
603
|
"sourcePath": "src/server/routes.ts",
|
|
604
|
-
"contentHash": "
|
|
604
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
605
605
|
"since": "2025-01-01"
|
|
606
606
|
},
|
|
607
607
|
"route-group:publishing": {
|
|
@@ -609,7 +609,7 @@
|
|
|
609
609
|
"type": "route-group",
|
|
610
610
|
"domain": "publishing",
|
|
611
611
|
"sourcePath": "src/server/routes.ts",
|
|
612
|
-
"contentHash": "
|
|
612
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
613
613
|
"since": "2025-01-01"
|
|
614
614
|
},
|
|
615
615
|
"route-group:private-views": {
|
|
@@ -617,7 +617,7 @@
|
|
|
617
617
|
"type": "route-group",
|
|
618
618
|
"domain": "publishing",
|
|
619
619
|
"sourcePath": "src/server/routes.ts",
|
|
620
|
-
"contentHash": "
|
|
620
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
621
621
|
"since": "2025-01-01"
|
|
622
622
|
},
|
|
623
623
|
"route-group:tunnel": {
|
|
@@ -625,7 +625,7 @@
|
|
|
625
625
|
"type": "route-group",
|
|
626
626
|
"domain": "networking",
|
|
627
627
|
"sourcePath": "src/server/routes.ts",
|
|
628
|
-
"contentHash": "
|
|
628
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
629
629
|
"since": "2025-01-01"
|
|
630
630
|
},
|
|
631
631
|
"route-group:events": {
|
|
@@ -633,7 +633,7 @@
|
|
|
633
633
|
"type": "route-group",
|
|
634
634
|
"domain": "networking",
|
|
635
635
|
"sourcePath": "src/server/routes.ts",
|
|
636
|
-
"contentHash": "
|
|
636
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
637
637
|
"since": "2025-01-01"
|
|
638
638
|
},
|
|
639
639
|
"route-group:evolution": {
|
|
@@ -641,7 +641,7 @@
|
|
|
641
641
|
"type": "route-group",
|
|
642
642
|
"domain": "evolution",
|
|
643
643
|
"sourcePath": "src/server/routes.ts",
|
|
644
|
-
"contentHash": "
|
|
644
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
645
645
|
"since": "2025-01-01"
|
|
646
646
|
},
|
|
647
647
|
"route-group:watchdog": {
|
|
@@ -649,7 +649,7 @@
|
|
|
649
649
|
"type": "route-group",
|
|
650
650
|
"domain": "monitoring",
|
|
651
651
|
"sourcePath": "src/server/routes.ts",
|
|
652
|
-
"contentHash": "
|
|
652
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
653
653
|
"since": "2025-01-01"
|
|
654
654
|
},
|
|
655
655
|
"route-group:topic-memory": {
|
|
@@ -657,7 +657,7 @@
|
|
|
657
657
|
"type": "route-group",
|
|
658
658
|
"domain": "memory",
|
|
659
659
|
"sourcePath": "src/server/routes.ts",
|
|
660
|
-
"contentHash": "
|
|
660
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
661
661
|
"since": "2025-01-01"
|
|
662
662
|
},
|
|
663
663
|
"route-group:state-sync": {
|
|
@@ -665,7 +665,7 @@
|
|
|
665
665
|
"type": "route-group",
|
|
666
666
|
"domain": "coordination",
|
|
667
667
|
"sourcePath": "src/server/routes.ts",
|
|
668
|
-
"contentHash": "
|
|
668
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
669
669
|
"since": "2025-01-01"
|
|
670
670
|
},
|
|
671
671
|
"route-group:intent": {
|
|
@@ -673,7 +673,7 @@
|
|
|
673
673
|
"type": "route-group",
|
|
674
674
|
"domain": "intent",
|
|
675
675
|
"sourcePath": "src/server/routes.ts",
|
|
676
|
-
"contentHash": "
|
|
676
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
677
677
|
"since": "2025-01-01"
|
|
678
678
|
},
|
|
679
679
|
"route-group:triage": {
|
|
@@ -681,7 +681,7 @@
|
|
|
681
681
|
"type": "route-group",
|
|
682
682
|
"domain": "safety",
|
|
683
683
|
"sourcePath": "src/server/routes.ts",
|
|
684
|
-
"contentHash": "
|
|
684
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
685
685
|
"since": "2025-01-01"
|
|
686
686
|
},
|
|
687
687
|
"route-group:operations": {
|
|
@@ -689,7 +689,7 @@
|
|
|
689
689
|
"type": "route-group",
|
|
690
690
|
"domain": "safety",
|
|
691
691
|
"sourcePath": "src/server/routes.ts",
|
|
692
|
-
"contentHash": "
|
|
692
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
693
693
|
"since": "2025-01-01"
|
|
694
694
|
},
|
|
695
695
|
"route-group:sentinel": {
|
|
@@ -697,7 +697,7 @@
|
|
|
697
697
|
"type": "route-group",
|
|
698
698
|
"domain": "safety",
|
|
699
699
|
"sourcePath": "src/server/routes.ts",
|
|
700
|
-
"contentHash": "
|
|
700
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
701
701
|
"since": "2025-01-01"
|
|
702
702
|
},
|
|
703
703
|
"route-group:trust": {
|
|
@@ -705,7 +705,7 @@
|
|
|
705
705
|
"type": "route-group",
|
|
706
706
|
"domain": "safety",
|
|
707
707
|
"sourcePath": "src/server/routes.ts",
|
|
708
|
-
"contentHash": "
|
|
708
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
709
709
|
"since": "2025-01-01"
|
|
710
710
|
},
|
|
711
711
|
"route-group:monitoring": {
|
|
@@ -713,7 +713,7 @@
|
|
|
713
713
|
"type": "route-group",
|
|
714
714
|
"domain": "monitoring",
|
|
715
715
|
"sourcePath": "src/server/routes.ts",
|
|
716
|
-
"contentHash": "
|
|
716
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
717
717
|
"since": "2025-01-01"
|
|
718
718
|
},
|
|
719
719
|
"route-group:commitments": {
|
|
@@ -721,7 +721,7 @@
|
|
|
721
721
|
"type": "route-group",
|
|
722
722
|
"domain": "commitments",
|
|
723
723
|
"sourcePath": "src/server/routes.ts",
|
|
724
|
-
"contentHash": "
|
|
724
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
725
725
|
"since": "2025-01-01"
|
|
726
726
|
},
|
|
727
727
|
"route-group:episodes": {
|
|
@@ -729,7 +729,7 @@
|
|
|
729
729
|
"type": "route-group",
|
|
730
730
|
"domain": "memory",
|
|
731
731
|
"sourcePath": "src/server/routes.ts",
|
|
732
|
-
"contentHash": "
|
|
732
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
733
733
|
"since": "2025-01-01"
|
|
734
734
|
},
|
|
735
735
|
"route-group:messages": {
|
|
@@ -737,7 +737,7 @@
|
|
|
737
737
|
"type": "route-group",
|
|
738
738
|
"domain": "coordination",
|
|
739
739
|
"sourcePath": "src/server/routes.ts",
|
|
740
|
-
"contentHash": "
|
|
740
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
741
741
|
"since": "2025-01-01"
|
|
742
742
|
},
|
|
743
743
|
"route-group:system-reviews": {
|
|
@@ -745,7 +745,7 @@
|
|
|
745
745
|
"type": "route-group",
|
|
746
746
|
"domain": "monitoring",
|
|
747
747
|
"sourcePath": "src/server/routes.ts",
|
|
748
|
-
"contentHash": "
|
|
748
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
749
749
|
"since": "2025-01-01"
|
|
750
750
|
},
|
|
751
751
|
"route-group:machine-mesh": {
|
|
@@ -761,7 +761,7 @@
|
|
|
761
761
|
"type": "route-group",
|
|
762
762
|
"domain": "security",
|
|
763
763
|
"sourcePath": "src/server/routes.ts",
|
|
764
|
-
"contentHash": "
|
|
764
|
+
"contentHash": "786073149c3ee781b92e50f0defe8ce348751ad61ee6511d06a13d70eb17211f",
|
|
765
765
|
"since": "2025-01-01"
|
|
766
766
|
},
|
|
767
767
|
"cli:init": {
|
package/upgrades/1.3.180.md
CHANGED
|
@@ -5,22 +5,6 @@
|
|
|
5
5
|
|
|
6
6
|
## What Changed
|
|
7
7
|
|
|
8
|
-
**Agent-to-agent reply-waits no longer flood the user's chat with "⏳ awaiting
|
|
9
|
-
reply" heartbeats.** When an agent sent a Threadline message to another agent,
|
|
10
|
-
`TopicLinkageHandler` created the reply-tracking commitment with
|
|
11
|
-
`beaconEnabled: true` **and** the user's topic id attached. `PromiseBeacon` then
|
|
12
|
-
fired cadenced `⏳ … awaiting reply` heartbeats straight into the user's Telegram
|
|
13
|
-
topic for what is purely an agent-to-agent conversation — observed in the wild as
|
|
14
|
-
dozens of heartbeats burying one topic, making real work invisible and reading as
|
|
15
|
-
"stuck."
|
|
16
|
-
|
|
17
|
-
The reply already routes back on its own: the threadline-reply commitment carries
|
|
18
|
-
`relatedThreadId` + `topicId`, and the inbound dispatch matches on those when the
|
|
19
|
-
reply lands — entirely independent of the beacon. So the heartbeat was pure
|
|
20
|
-
housekeeping noise. The fix sets `beaconEnabled: false` on these reply-wait
|
|
21
|
-
commitments. This is a direct application of the **Near-Silent Notifications**
|
|
22
|
-
standard: routine agent-to-agent status belongs in logs, never the user's chat.
|
|
23
|
-
|
|
24
8
|
The per-feature LLM metrics now actually collect data. Phase 1a added the ledger
|
|
25
9
|
+ `GET /metrics/features`; **Phase 1b adds the funnel tap** — the one shared LLM
|
|
26
10
|
call (`CircuitBreakingIntelligenceProvider.evaluate`) now records, per gate/
|
|
@@ -51,36 +35,52 @@ This is intended for the instar developer's own agent (always-current is
|
|
|
51
35
|
required when you build and dogfood the fleet). It is **off by default**, so the
|
|
52
36
|
fleet's existing session-aware + window-aware restart deferral is unchanged.
|
|
53
37
|
|
|
54
|
-
|
|
38
|
+
**A moved conversation's reply no longer hangs silently when the other machine
|
|
39
|
+
is briefly unreachable.** When you move a conversation to another machine, that
|
|
40
|
+
machine relays its replies through the machine that holds the Telegram
|
|
41
|
+
connection. That relay had two operational defects, both found by driving the
|
|
42
|
+
multi-machine feature live: it had no time limit (so when the receiving machine's
|
|
43
|
+
connection was momentarily restarting, the reply hung for over a minute with no
|
|
44
|
+
result), and it failed completely silently (a dropped reply wrote nothing to the
|
|
45
|
+
log, so there was no way to tell why it didn't arrive).
|
|
46
|
+
|
|
47
|
+
The relay is now bounded and observable: it gives the receiving machine a fixed
|
|
48
|
+
window (15 seconds by default, adjustable) and then fails fast, and every failure
|
|
49
|
+
writes one clear line saying exactly what went wrong (no reachable machine, a
|
|
50
|
+
rejection with its status code, or a timeout). The relay logic was also extracted
|
|
51
|
+
into its own well-tested unit.
|
|
52
|
+
|
|
53
|
+
It also no longer reports a false success: previously the relay could report
|
|
54
|
+
"delivered" even when the message never actually reached the chat (it accepted a
|
|
55
|
+
response that carried no real message id). Now the receiving machine returns the
|
|
56
|
+
real message id and the relay only counts a reply as delivered when that id is
|
|
57
|
+
present — otherwise it's treated as undelivered and surfaced, so a busy or flaky
|
|
58
|
+
moment becomes a real, visible failure (and a retry candidate) instead of a
|
|
59
|
+
silent loss dressed up as success.
|
|
55
60
|
|
|
56
|
-
|
|
57
|
-
no longer spam your chat with "⏳ awaiting reply" heartbeats while it waits for a
|
|
58
|
-
peer — the peer's reply still arrives and routes to the right place exactly as
|
|
59
|
-
before. Beacons that were already running before this update auto-pause on their
|
|
60
|
-
own; new ones won't be created.
|
|
61
|
+
## What to Tell Your User
|
|
61
62
|
|
|
62
|
-
Nothing required. If asked:
|
|
63
|
-
often each check runs, and how often it hits a
|
|
64
|
-
lets us tune the checks with evidence.
|
|
63
|
+
Nothing required. If asked: the per-feature metrics endpoint now shows real
|
|
64
|
+
per-check cost (latency), how often each check runs, and how often it hits a
|
|
65
|
+
rate-limit wait — the data that lets us tune the checks with evidence.
|
|
65
66
|
|
|
66
|
-
Nothing required. If asked:
|
|
67
|
-
and how often it fires
|
|
68
|
-
instead of guesses.
|
|
67
|
+
Nothing required. If asked: the agent can now report, per safety check, how
|
|
68
|
+
much it costs and how often it fires (via a new per-feature metrics endpoint) —
|
|
69
|
+
which is what lets us tune the checks with data instead of guesses.
|
|
69
70
|
|
|
70
71
|
Nothing for almost everyone — this is off by default and changes nothing unless
|
|
71
|
-
you explicitly
|
|
72
|
-
latest build,
|
|
73
|
-
restart does not close your sessions
|
|
74
|
-
only cost is a brief
|
|
75
|
-
|
|
72
|
+
you explicitly enable it. If you run the kind of agent that must always be on the
|
|
73
|
+
latest build, enable the restart-immediately option in your agent config. A
|
|
74
|
+
server restart does **not** close your sessions (they resume via CONTINUATION);
|
|
75
|
+
the only cost is a brief messaging blip while the server bounces. The updates
|
|
76
|
+
status endpoint now reports whether it's on, so you can confirm it.
|
|
76
77
|
|
|
77
|
-
|
|
78
|
+
Nothing to configure. If you run across more than one machine and move a
|
|
79
|
+
conversation between them, a reply that can't be delivered now fails quickly with
|
|
80
|
+
a clear reason in the log, instead of hanging for over a minute and vanishing
|
|
81
|
+
without explanation. Single-machine setups are unaffected.
|
|
78
82
|
|
|
79
|
-
|
|
80
|
-
`beaconEnabled: false` — the reply-routing (relatedThreadId + topicId) is
|
|
81
|
-
preserved; only the user-facing heartbeat is suppressed.
|
|
82
|
-
- No change to user-facing PromiseBeacons for genuine commitments *to the user*;
|
|
83
|
-
this scopes the suppression to agent-to-agent reply-waits only.
|
|
83
|
+
## Summary of New Capabilities
|
|
84
84
|
|
|
85
85
|
- `CircuitBreakingIntelligenceProvider` instruments every LLM call into the
|
|
86
86
|
`FeatureMetricsLedger` via a module-level recorder (`setFeatureMetricsRecorder`),
|
|
@@ -103,13 +103,13 @@ I can turn it on and confirm it's active.
|
|
|
103
103
|
- Observability: both `UpdateGate.getStatus()` and `AutoUpdater.getStatus()` /
|
|
104
104
|
`GET /updates/status` surface the active value.
|
|
105
105
|
|
|
106
|
-
|
|
106
|
+
- `relayOutbound` (`src/core/TelegramRelay.ts`) — the tokenless-standby reply
|
|
107
|
+
relay, extracted as a pure injectable unit with a bounded `AbortController`
|
|
108
|
+
timeout and a log line on every failure path. `server.ts` wires
|
|
109
|
+
`telegram.outboundRelay` to it. New optional `multiMachine.relayTimeoutMs`
|
|
110
|
+
(default 15000).
|
|
107
111
|
|
|
108
|
-
|
|
109
|
-
asserts `beaconEnabled === false` (regression pin).
|
|
110
|
-
- `tests/unit/CommitmentTracker-threadline-reply.test.ts` — the tracker still
|
|
111
|
-
honors an explicit `beaconEnabled: true` (mechanism unchanged); stale "matches
|
|
112
|
-
call-site" comment corrected. 32/32 green across both files.
|
|
112
|
+
## Evidence
|
|
113
113
|
|
|
114
114
|
- Spec: `docs/specs/llm-feature-metrics-spec.md` (Phase 1b; approved Telegram 13435).
|
|
115
115
|
- Tests: `tests/unit/CircuitBreaking-feature-metrics-tap.test.ts` (+8, incl. an
|
|
@@ -131,3 +131,16 @@ I can turn it on and confirm it's active.
|
|
|
131
131
|
toggle both directions) and `tests/unit/AutoUpdater.test.ts` (+2: default
|
|
132
132
|
false; `restartImmediately:true` reflected in status via the real gate). All
|
|
133
133
|
19 UpdateGate + 18 AutoUpdater tests pass; `npm run lint` (tsc) clean.
|
|
134
|
+
|
|
135
|
+
- Reproduction (live, 2026-06-01): driving the multi-machine reply proof, a
|
|
136
|
+
relayed reply hung 25s then 70s with no result and no log line; root cause was
|
|
137
|
+
the holder's tunnel being mid-restart, and the relay `fetch` having no timeout.
|
|
138
|
+
Once the tunnel was back, the relay completed (a tone-gate response and an `ok`
|
|
139
|
+
came back through the full standby→holder chain), confirming the path itself
|
|
140
|
+
works — but the hang + silence were real operational defects on the way there.
|
|
141
|
+
- Tests: `tests/unit/telegram-relay-timeout-observability.test.ts` (7) drive the
|
|
142
|
+
real `relayOutbound` with an injected fetch + logger: 2xx returns messageId and
|
|
143
|
+
posts the right URL + `Bearer` header; self-hold no-ops; no-peer-URL logs;
|
|
144
|
+
non-2xx logs the status; **a hanging holder aborts within the timeout (elapsed
|
|
145
|
+
under 2s) and logs `timeout after Nms`**; a network error logs its message; the
|
|
146
|
+
`silent` flag passes through. 7/7 green; `tsc` clean.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Upgrade Guide — vNEXT
|
|
2
|
+
|
|
3
|
+
<!-- assembled-by: assemble-next-md -->
|
|
4
|
+
<!-- bump: patch -->
|
|
5
|
+
|
|
6
|
+
## What Changed
|
|
7
|
+
|
|
8
|
+
**A moved conversation's reply no longer hangs silently when the other machine
|
|
9
|
+
is briefly unreachable.** When you move a conversation to another machine, that
|
|
10
|
+
machine relays its replies through the machine that holds the Telegram
|
|
11
|
+
connection. That relay had two operational defects, both found by driving the
|
|
12
|
+
multi-machine feature live: it had no time limit (so when the receiving machine's
|
|
13
|
+
connection was momentarily restarting, the reply hung for over a minute with no
|
|
14
|
+
result), and it failed completely silently (a dropped reply wrote nothing to the
|
|
15
|
+
log, so there was no way to tell why it didn't arrive).
|
|
16
|
+
|
|
17
|
+
The relay is now bounded and observable: it gives the receiving machine a fixed
|
|
18
|
+
window (15 seconds by default, adjustable) and then fails fast, and every failure
|
|
19
|
+
writes one clear line saying exactly what went wrong (no reachable machine, a
|
|
20
|
+
rejection with its status code, or a timeout). The relay logic was also extracted
|
|
21
|
+
into its own well-tested unit.
|
|
22
|
+
|
|
23
|
+
It also no longer reports a false success: previously the relay could report
|
|
24
|
+
"delivered" even when the message never actually reached the chat (it accepted a
|
|
25
|
+
response that carried no real message id). Now the receiving machine returns the
|
|
26
|
+
real message id and the relay only counts a reply as delivered when that id is
|
|
27
|
+
present — otherwise it's treated as undelivered and surfaced, so a busy or flaky
|
|
28
|
+
moment becomes a real, visible failure (and a retry candidate) instead of a
|
|
29
|
+
silent loss dressed up as success.
|
|
30
|
+
|
|
31
|
+
## What to Tell Your User
|
|
32
|
+
|
|
33
|
+
Nothing to configure. If you run across more than one machine and move a
|
|
34
|
+
conversation between them, a reply that can't be delivered now fails quickly with
|
|
35
|
+
a clear reason in the log, instead of hanging for over a minute and vanishing
|
|
36
|
+
without explanation. Single-machine setups are unaffected.
|
|
37
|
+
|
|
38
|
+
## Summary of New Capabilities
|
|
39
|
+
|
|
40
|
+
- `relayOutbound` (`src/core/TelegramRelay.ts`) — the tokenless-standby reply
|
|
41
|
+
relay, extracted as a pure injectable unit with a bounded `AbortController`
|
|
42
|
+
timeout and a log line on every failure path. `server.ts` wires
|
|
43
|
+
`telegram.outboundRelay` to it. New optional `multiMachine.relayTimeoutMs`
|
|
44
|
+
(default 15000).
|
|
45
|
+
|
|
46
|
+
## Evidence
|
|
47
|
+
|
|
48
|
+
- Reproduction (live, 2026-06-01): driving the multi-machine reply proof, a
|
|
49
|
+
relayed reply hung 25s then 70s with no result and no log line; root cause was
|
|
50
|
+
the holder's tunnel being mid-restart, and the relay `fetch` having no timeout.
|
|
51
|
+
Once the tunnel was back, the relay completed (a tone-gate response and an `ok`
|
|
52
|
+
came back through the full standby→holder chain), confirming the path itself
|
|
53
|
+
works — but the hang + silence were real operational defects on the way there.
|
|
54
|
+
- Tests: `tests/unit/telegram-relay-timeout-observability.test.ts` (7) drive the
|
|
55
|
+
real `relayOutbound` with an injected fetch + logger: 2xx returns messageId and
|
|
56
|
+
posts the right URL + `Bearer` header; self-hold no-ops; no-peer-URL logs;
|
|
57
|
+
non-2xx logs the status; **a hanging holder aborts within the timeout (elapsed
|
|
58
|
+
under 2s) and logs `timeout after Nms`**; a network error logs its message; the
|
|
59
|
+
`silent` flag passes through. 7/7 green; `tsc` clean.
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Side effects — tokenless-standby relay timeout + observability
|
|
2
|
+
|
|
3
|
+
## What changes at runtime
|
|
4
|
+
|
|
5
|
+
The tokenless-standby outbound Telegram relay (`outboundRelay`, used only when a
|
|
6
|
+
pool standby serves a moved session) now (a) aborts after a bounded timeout
|
|
7
|
+
instead of hanging, and (b) logs one explanatory line on every failure path.
|
|
8
|
+
Logic extracted into `src/core/TelegramRelay.ts`; success behavior unchanged.
|
|
9
|
+
|
|
10
|
+
## Who is affected
|
|
11
|
+
|
|
12
|
+
- **Single-machine agents:** zero behavior change. `outboundRelay` is only wired
|
|
13
|
+
in the multi-machine session-pool branch and is only invoked by `sendToTopic`
|
|
14
|
+
when the adapter has no usable bot token (a standby). A single-machine agent
|
|
15
|
+
never relays.
|
|
16
|
+
- **Multi-machine standbys (a moved session replying):** a relay to an
|
|
17
|
+
unreachable/slow holder now fails after `relayTimeoutMs` (default 15s) instead
|
|
18
|
+
of hanging indefinitely, and the failure is logged with its cause.
|
|
19
|
+
|
|
20
|
+
## Blast radius
|
|
21
|
+
|
|
22
|
+
- New file `src/core/TelegramRelay.ts` + a wiring change in `src/commands/server.ts`
|
|
23
|
+
(the `outboundRelay` assignment) + one import. No route, schema, config-key, or
|
|
24
|
+
migration change. New optional config `multiMachine.relayTimeoutMs` (absent →
|
|
25
|
+
15s default).
|
|
26
|
+
- Compiled source only — no agent-installed file/hook/skill, so no
|
|
27
|
+
PostUpdateMigrator change; agents get it on the normal server update.
|
|
28
|
+
|
|
29
|
+
## Failure modes considered
|
|
30
|
+
|
|
31
|
+
- **Timeout too aggressive:** default 15s is generous for a tunnel round-trip;
|
|
32
|
+
tunable up via config if a deployment needs it. On timeout the reply fails
|
|
33
|
+
(logged) rather than hangs — strictly better than the prior unbounded hang.
|
|
34
|
+
- **Log noise:** one line per failed relay only (success is silent), so a
|
|
35
|
+
healthy multi-machine setup adds no log volume.
|
|
36
|
+
- **Behavior parity:** the success path (POST holder, return messageId, pass
|
|
37
|
+
`silent` through) is byte-equivalent to the original; covered by a 2xx test.
|