@kitkat-vn/kitcode 0.2.0-staging.13 → 0.2.0-staging.14

package/README.md

@@ -189,22 +189,22 @@ The time targets are fixed, each milestone's own (below): no flag or variable ch
 Each milestone needs both enough active time and enough counted `=`, each counted from the moment the milestone before it
 was reached: `30%` from install, `50%` from the moment `30%` was reached, `100%` from the moment `50%` was. Nothing earned
 before that moment counts toward it, neither time earned while waiting for `=` nor `=` while waiting for time, so `100%`
-takes 16 hours and 1,800 `=` in all. What was reached stays reached.
+takes 108 minutes and 36 `=` in all in a tester build. What was reached stays reached.
 
 ### Milestones
 
 | Milestone | Active time, from the milestone before | Counted `=`, from the milestone before |
 | ---: | ---: | ---: |
-| `30%` | 3 hours (10800 s), from install | 300, from install |
-| `50%` | 5 hours (18000 s) | 500 |
-| `100%` | 8 hours (28800 s) | 1,000 |
-
-Every build counts by these numbers: the tester table, which every tester build counts by, and the production table, which
-a production release counts by, hold the same ones. `MILESTONE_TABLE` in `src/integration-spec.mjs` says which this package
-counts by, and `kitcode summary` names what the next milestone still needs.
-Until 2026-10-08 there were 10% and 20% milestones too, and until 2026-10-20 every milestone counted from install. Until
-2026-10-21 a tester build counted 18 minutes and 9 `=`, 30 minutes and 12, and 60 minutes and 15: 108 minutes and 36 `=` to
-`100%`.
+| `30%` | 18 minutes (1080 s), from install | 9, from install |
+| `50%` | 30 minutes (1800 s) | 12 |
+| `100%` | 60 minutes (3600 s) | 15 |
+
+This is the tester table, which every tester build counts by. A production release counts by the production table: 3 hours
+(10800 s) and 300 `=`, 5 hours (18000 s) and 500, 8 hours (28800 s) and 1,000, so 16 hours and 1,800 `=` to `100%`.
+`MILESTONE_TABLE` in `src/integration-spec.mjs` says which this package counts by, and `kitcode summary` names what the next
+milestone still needs.
+Until 2026-10-08 there were 10% and 20% milestones too, and until 2026-10-20 every milestone counted from install. From
+2026-10-21 to 2026-10-22 the tester table held the production table's numbers; since 2026-10-22 it is the short one again.
 
 Once a milestone is reached, the dashboard shows its message: the campaign's own words, which the campaign's server gives each milestone. The prompt hook and the desktop notification say only that a milestone was reached. `summary` and `awards` show which are ready.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kitkat-vn/kitcode",
-  "version": "0.2.0-staging.13",
+  "version": "0.2.0-staging.14",
   "description": "Local aggregate activity server for KitCode.",
   "license": "MIT",
   "repository": {
@@ -37,5 +37,5 @@
   "optionalDependencies": {
     "electron": "^43.0.0"
   },
-  "gitHead": "ba4547df17d044bcf364625e341afe590b0453fe"
+  "gitHead": "9bb9ffad62d8fc739287dbf8b76e0505f412b7c2"
 }

package/src/integration-spec.mjs

@@ -48,11 +48,17 @@ export const RUNNER_DISPLAY_PATH = `~/${RUNNER_PATH_PARTS.join('/')}`;
 // decision 4 for the tester table; the production table's numbers are no longer drafts, and its 100 % is 8 h where the
 // draft said 10. The two tables stay two, equal, so that production's can differ again by one table's edit (a ruling,
 // docs/reward-rules.md §2). Until then the tester table was 1080 s and 9 =, 1800 s and 12 =, 3600 s and 15 =.
+//
+// Since 2026-10-22 the tester table is that short one again (the operator: "scale down the focus time and = requirements as
+// the previous time for staging for testing easier, keep the same for production"): 18 minutes and 9 =, 30 and 12, 60 and
+// 15, so 108 minutes and 36 = in all to reach 100 %, each still counted fresh. The production table keeps the operator's
+// numbers of 2026-10-21, and the two differ again. The claim backend holds a claim to its own MILESTONE_* settings, which
+// staging's server sets to the tester table by hand (docs/deployment-target.md).
 export const MILESTONE_TABLES = Object.freeze({
   tester: Object.freeze([
-    Object.freeze({percent: 30, requiredSeconds: 10800, requiredEquals: 300}),
-    Object.freeze({percent: 50, requiredSeconds: 18000, requiredEquals: 500}),
-    Object.freeze({percent: 100, requiredSeconds: 28800, requiredEquals: 1000}),
+    Object.freeze({percent: 30, requiredSeconds: 1080, requiredEquals: 9}),
+    Object.freeze({percent: 50, requiredSeconds: 1800, requiredEquals: 12}),
+    Object.freeze({percent: 100, requiredSeconds: 3600, requiredEquals: 15}),
   ]),
   production: Object.freeze([
     Object.freeze({percent: 30, requiredSeconds: 10800, requiredEquals: 300}),
@@ -269,7 +275,8 @@ function targetTime(seconds) {
 
 // Since 2026-10-20 each line says where its milestone counts from: install for the first, and for each other the moment the
 // one before it was reached (docs/reward-rules.md §2). Since 2026-10-21 each names its time, "3h of tracked time", where it
-// said "enough tracked time": with the operator's targets of that day a milestone's time is 3 to 8 hours.
+// said "enough tracked time": with the operator's targets of that day a milestone's time is 3 to 8 hours. Since 2026-10-22
+// the tester table's times read "18m", "30m" and "1h", the production table's still "3h", "5h" and "8h".
 function milestoneLines() {
   const milestones = [...KITCODE_REWARD_TIERS, ...KITCODE_DISPLAY_MILESTONES];
 

package/src/reward.mjs

@@ -17,8 +17,8 @@ export const MILESTONE_PERCENTS = REWARD_MILESTONES.map((milestone) => milestone
 // §3). Until then it was a setting, down to 1 s: --reward-seconds, KITCODE_REWARD_SECONDS, and
 // rewardSettings.requiredSeconds in state.json. A requiredSeconds an older KitCode stored stays in the
 // file, unread, as the removed requiredEquals does. Since 2026-10-20 each milestone names its own time in the table
-// (integration-spec.mjs), where it was this × its percent: the same numbers in the tester table until 2026-10-21, and since
-// then the operator's, 100 %'s 8 h, 28800 s.
+// (integration-spec.mjs), where it was this × its percent: the same numbers in the tester table, which held the operator's
+// from 2026-10-21 to 2026-10-22, 100 %'s 8 h, and since then its own again, 100 %'s 3600 s.
 const LAST_MILESTONE = REWARD_MILESTONES[REWARD_MILESTONES.length - 1];
 export const REWARD_SECONDS = LAST_MILESTONE.requiredSeconds;
 // The = the last milestone needs. The = targets are the table's; no setting changes them (the