@nac3/forge-cli 1.0.58 → 1.0.59
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/chat/doctrine_digest.d.ts.map +1 -1
- package/dist/chat/doctrine_digest.js +12 -0
- package/dist/chat/doctrine_digest.js.map +1 -1
- package/dist/chat/panel.d.ts.map +1 -1
- package/dist/chat/panel.js +171 -76
- package/dist/chat/panel.js.map +1 -1
- package/dist/chat/server.d.ts.map +1 -1
- package/dist/chat/server.js +9 -1
- package/dist/chat/server.js.map +1 -1
- package/dist/docs/doctrine/concurrency-scale.md +54 -0
- package/dist/semantic_graph/last_change.d.ts +9 -0
- package/dist/semantic_graph/last_change.d.ts.map +1 -0
- package/dist/semantic_graph/last_change.js +93 -0
- package/dist/semantic_graph/last_change.js.map +1 -0
- package/dist/version.d.ts +1 -1
- package/dist/version.js +1 -1
- package/docs/doctrine/concurrency-scale.md +54 -0
- package/package.json +1 -1
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# Concurrency & scale doctrine
|
|
2
|
+
|
|
3
|
+
Every application Forge designs MUST be sized to its expected
|
|
4
|
+
concurrency from day one. Scale is a RELEVAMIENTO input, not an
|
|
5
|
+
afterthought bolted on when the app falls over.
|
|
6
|
+
|
|
7
|
+
## 1. Ask it during requirements
|
|
8
|
+
|
|
9
|
+
During the greenfield relevamiento -- and when scoping a corrective /
|
|
10
|
+
evolutive change that touches a load-bearing path -- ASK, before
|
|
11
|
+
choosing an architecture:
|
|
12
|
+
|
|
13
|
+
- Peak SIMULTANEOUS users / requests? Give an order of magnitude:
|
|
14
|
+
tens, hundreds, thousands, 10k+.
|
|
15
|
+
- Read-heavy or write-heavy? Steady or bursty (spikes)?
|
|
16
|
+
- Latency budget: interactive (< ~200 ms) or batch/async?
|
|
17
|
+
- Growth horizon: will it 10x within a year?
|
|
18
|
+
- Consistency needs: strong (banking) or eventual (feeds)?
|
|
19
|
+
|
|
20
|
+
If the user does not know, PROPOSE a reasonable default AND write the
|
|
21
|
+
assumption explicitly in the spec / `<root>/.forge/sumi-context.md`.
|
|
22
|
+
Never silently assume "a handful of users".
|
|
23
|
+
|
|
24
|
+
## 2. Design a multi-layer architecture with no bottleneck at any tier
|
|
25
|
+
|
|
26
|
+
Pick the layers that the target number actually needs, and make each
|
|
27
|
+
one non-blocking:
|
|
28
|
+
|
|
29
|
+
- Client: pagination, debounce, optimistic UI, local cache -- do not
|
|
30
|
+
fetch the world on every keystroke.
|
|
31
|
+
- Edge / CDN: serve static + cacheable responses close to the user.
|
|
32
|
+
- App tier: STATELESS request handlers so nodes scale horizontally.
|
|
33
|
+
No in-process session/user state that pins a user to one node
|
|
34
|
+
(put it in a shared store / signed token).
|
|
35
|
+
- Concurrency control: connection pools sized to the DB; queues +
|
|
36
|
+
backpressure to absorb spikes; idempotency keys for retried writes;
|
|
37
|
+
rate limits / circuit breakers on hot paths.
|
|
38
|
+
- Data tier (the usual bottleneck): indexed queries; read replicas
|
|
39
|
+
for read-heavy loads; a cache (Redis / KV) in front of hot reads;
|
|
40
|
+
async jobs for slow writes; partition / shard ONLY when the numbers
|
|
41
|
+
demand it.
|
|
42
|
+
- Realtime: fan out via a broker (Redis pub/sub, a queue, a hub), not
|
|
43
|
+
an N-app-node polling loop.
|
|
44
|
+
|
|
45
|
+
## 3. Proportionality (do not gold-plate)
|
|
46
|
+
|
|
47
|
+
Match the architecture to the number. A 20-user internal tool gets a
|
|
48
|
+
simple single-tier design -- adding sharding + a message broker there
|
|
49
|
+
is a defect too. A 10k-concurrent public app gets the full multi-layer
|
|
50
|
+
treatment. The rule is "no bottleneck AND no gold-plating", sized to
|
|
51
|
+
the stated concurrency.
|
|
52
|
+
|
|
53
|
+
Record the target concurrency and the tier decisions in the spec so
|
|
54
|
+
they are traceable and can be revisited when the number changes.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
/** relPath (posix slashes) -> unix seconds of the file's most recent commit.
|
|
2
|
+
* Empty map when git is unavailable / not a repo (caller falls to mtime). */
|
|
3
|
+
export declare function fileLastChangeMap(projectRoot: string): Promise<Map<string, number>>;
|
|
4
|
+
/** Resolve a node's last-change ts: git map by path, else fs mtime, else 0. */
|
|
5
|
+
export declare function nodeLastChange(projectRoot: string, relPath: string, gitMap: Map<string, number>): Promise<number>;
|
|
6
|
+
/** Server-side twin of the panel's graphNodePath: the last path-like
|
|
7
|
+
* parenthetical in a node's purpose/detail ("... (src/foo.py)."). */
|
|
8
|
+
export declare function pathFromPurpose(purpose: string): string;
|
|
9
|
+
//# sourceMappingURL=last_change.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"last_change.d.ts","sourceRoot":"","sources":["../../src/semantic_graph/last_change.ts"],"names":[],"mappings":"AAaA;8EAC8E;AAC9E,wBAAgB,iBAAiB,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAoBnF;AAED,+EAA+E;AAC/E,wBAAsB,cAAc,CAClC,WAAW,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,GAChE,OAAO,CAAC,MAAM,CAAC,CAOjB;AAED;sEACsE;AACtE,wBAAgB,eAAe,CAAC,OAAO,EAAE,MAAM,GAAG,MAAM,CA4BvD"}
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Per-file "last change" timestamp for the galaxy graph colouring (Pablo,
|
|
3
|
+
* 2026-07-05). One `git log` pass yields the most-recent commit time per
|
|
4
|
+
* tracked file; the filesystem mtime is the fallback for untracked files.
|
|
5
|
+
* The panel normalises these across nodes and colours newest -> blue,
|
|
6
|
+
* oldest -> red (full spectrum).
|
|
7
|
+
*
|
|
8
|
+
* ASCII-only.
|
|
9
|
+
*/
|
|
10
|
+
import { execFile } from 'node:child_process';
|
|
11
|
+
import { stat } from 'node:fs/promises';
|
|
12
|
+
import { join } from 'node:path';
|
|
13
|
+
/** relPath (posix slashes) -> unix seconds of the file's most recent commit.
|
|
14
|
+
* Empty map when git is unavailable / not a repo (caller falls to mtime). */
|
|
15
|
+
export function fileLastChangeMap(projectRoot) {
|
|
16
|
+
return new Promise((resolve) => {
|
|
17
|
+
execFile('git', ['log', '--format=%ct', '--name-only', '--no-renames'], { cwd: projectRoot, maxBuffer: 128 * 1024 * 1024, windowsHide: true }, (err, stdout) => {
|
|
18
|
+
const map = new Map();
|
|
19
|
+
if (err || !stdout) {
|
|
20
|
+
resolve(map);
|
|
21
|
+
return;
|
|
22
|
+
}
|
|
23
|
+
let ts = 0;
|
|
24
|
+
for (const raw of String(stdout).split('\n')) {
|
|
25
|
+
const line = raw.trim();
|
|
26
|
+
if (!line)
|
|
27
|
+
continue;
|
|
28
|
+
if (/^\d+$/.test(line)) {
|
|
29
|
+
ts = parseInt(line, 10);
|
|
30
|
+
continue;
|
|
31
|
+
}
|
|
32
|
+
const rel = line.replace(/\\/g, '/');
|
|
33
|
+
if (!map.has(rel))
|
|
34
|
+
map.set(rel, ts); // git log is newest-first: first wins
|
|
35
|
+
}
|
|
36
|
+
resolve(map);
|
|
37
|
+
});
|
|
38
|
+
});
|
|
39
|
+
}
|
|
40
|
+
/** Resolve a node's last-change ts: git map by path, else fs mtime, else 0. */
|
|
41
|
+
export async function nodeLastChange(projectRoot, relPath, gitMap) {
|
|
42
|
+
if (!relPath)
|
|
43
|
+
return 0;
|
|
44
|
+
const rel = relPath.replace(/\\/g, '/');
|
|
45
|
+
const g = gitMap.get(rel);
|
|
46
|
+
if (g)
|
|
47
|
+
return g;
|
|
48
|
+
try {
|
|
49
|
+
const st = await stat(join(projectRoot, rel));
|
|
50
|
+
return Math.floor(st.mtimeMs / 1000);
|
|
51
|
+
}
|
|
52
|
+
catch {
|
|
53
|
+
return 0;
|
|
54
|
+
}
|
|
55
|
+
}
|
|
56
|
+
/** Server-side twin of the panel's graphNodePath: the last path-like
|
|
57
|
+
* parenthetical in a node's purpose/detail ("... (src/foo.py)."). */
|
|
58
|
+
export function pathFromPurpose(purpose) {
|
|
59
|
+
const d = String(purpose || '');
|
|
60
|
+
const cands = [];
|
|
61
|
+
let i = 0;
|
|
62
|
+
while (i < d.length) {
|
|
63
|
+
const open = d.indexOf('(', i);
|
|
64
|
+
if (open < 0)
|
|
65
|
+
break;
|
|
66
|
+
const close = d.indexOf(')', open + 1);
|
|
67
|
+
if (close < 0)
|
|
68
|
+
break;
|
|
69
|
+
cands.push(d.slice(open + 1, close).trim());
|
|
70
|
+
i = close + 1;
|
|
71
|
+
}
|
|
72
|
+
for (let k = cands.length - 1; k >= 0; k--) {
|
|
73
|
+
let inner = cands[k] || '';
|
|
74
|
+
if (!inner || inner.length > 240)
|
|
75
|
+
continue;
|
|
76
|
+
while (inner.length && '.,;'.indexOf(inner.charAt(inner.length - 1)) >= 0)
|
|
77
|
+
inner = inner.slice(0, -1);
|
|
78
|
+
const hasSep = inner.indexOf('/') >= 0 || inner.indexOf('\\') >= 0;
|
|
79
|
+
let hasExt = false;
|
|
80
|
+
const dot = inner.lastIndexOf('.');
|
|
81
|
+
if (dot > 0 && dot < inner.length - 1) {
|
|
82
|
+
const ext = inner.slice(dot + 1);
|
|
83
|
+
hasExt = ext.length <= 8 && /^[a-z0-9]+$/i.test(ext);
|
|
84
|
+
}
|
|
85
|
+
if (!hasSep && !hasExt)
|
|
86
|
+
continue;
|
|
87
|
+
if (inner.indexOf(' ') >= 0 && !hasSep)
|
|
88
|
+
continue;
|
|
89
|
+
return inner;
|
|
90
|
+
}
|
|
91
|
+
return '';
|
|
92
|
+
}
|
|
93
|
+
//# sourceMappingURL=last_change.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"last_change.js","sourceRoot":"","sources":["../../src/semantic_graph/last_change.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,oBAAoB,CAAC;AAC9C,OAAO,EAAE,IAAI,EAAE,MAAM,kBAAkB,CAAC;AACxC,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAEjC;8EAC8E;AAC9E,MAAM,UAAU,iBAAiB,CAAC,WAAmB;IACnD,OAAO,IAAI,OAAO,CAAC,CAAC,OAAO,EAAE,EAAE;QAC7B,QAAQ,CACN,KAAK,EAAE,CAAC,KAAK,EAAE,cAAc,EAAE,aAAa,EAAE,cAAc,CAAC,EAC7D,EAAE,GAAG,EAAE,WAAW,EAAE,SAAS,EAAE,GAAG,GAAG,IAAI,GAAG,IAAI,EAAE,WAAW,EAAE,IAAI,EAAE,EACrE,CAAC,GAAG,EAAE,MAAM,EAAE,EAAE;YACd,MAAM,GAAG,GAAG,IAAI,GAAG,EAAkB,CAAC;YACtC,IAAI,GAAG,IAAI,CAAC,MAAM,EAAE,CAAC;gBAAC,OAAO,CAAC,GAAG,CAAC,CAAC;gBAAC,OAAO;YAAC,CAAC;YAC7C,IAAI,EAAE,GAAG,CAAC,CAAC;YACX,KAAK,MAAM,GAAG,IAAI,MAAM,CAAC,MAAM,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;gBAC7C,MAAM,IAAI,GAAG,GAAG,CAAC,IAAI,EAAE,CAAC;gBACxB,IAAI,CAAC,IAAI;oBAAE,SAAS;gBACpB,IAAI,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;oBAAC,EAAE,GAAG,QAAQ,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;oBAAC,SAAS;gBAAC,CAAC;gBAC9D,MAAM,GAAG,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,GAAG,CAAC,CAAC;gBACrC,IAAI,CAAC,GAAG,CAAC,GAAG,CAAC,GAAG,CAAC;oBAAE,GAAG,CAAC,GAAG,CAAC,GAAG,EAAE,EAAE,CAAC,CAAC,CAAC,sCAAsC;YAC7E,CAAC;YACD,OAAO,CAAC,GAAG,CAAC,CAAC;QACf,CAAC,CACF,CAAC;IACJ,CAAC,CAAC,CAAC;AACL,CAAC;AAED,+EAA+E;AAC/E,MAAM,CAAC,KAAK,UAAU,cAAc,CAClC,WAAmB,EAAE,OAAe,EAAE,MAA2B;IAEjE,IAAI,CAAC,OAAO;QAAE,OAAO,CAAC,CAAC;IACvB,MAAM,GAAG,GAAG,OAAO,CAAC,OAAO,CAAC,KAAK,EAAE,GAAG,CAAC,CAAC;IACxC,MAAM,CAAC,GAAG,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;IAC1B,IAAI,CAAC;QAAE,OAAO,CAAC,CAAC;IAChB,IAAI,CAAC;QAAC,MAAM,EAAE,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,CAAC;QAAC,OAAO,IAAI,CAAC,KAAK,CAAC,EAAE,CAAC,OAAO,GAAG,IAAI,CAAC,CAAC;IAAC,CAAC;IAC5F,MAAM,CAAC;QAAC,OAAO,CAAC,CAAC;IAAC,CAAC;AACrB,CAAC;AAED;sEACsE;AACtE,MAAM,UAAU,eAAe,CAAC,OAAe;IAC7C,MAAM,CAAC,GAAG,MAAM,CAAC,OAAO,IAAI,EAAE,CAAC,CAAC;IAChC,MAAM,KAAK,GAAa,EAAE,CAAC;IAC3B,IAAI,CAAC,GAAG,CAAC,CAAC;IACV,OAAO,CAAC,GAAG,CAAC,CAAC,MAAM,EAAE,CAAC;QACpB,MAAM,IAAI,GAAG,CAAC,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,CAAC,CAAC;QAC/B,IAAI,IAAI,GAAG,CAAC;YAAE,MAAM;QACpB,MAAM,KAAK,GAAG,CAAC,CAAC,OAAO,CAAC,GAAG,EAAE,IAAI,GAAG,CAAC,CAAC,CAAC;QACvC,IAAI,KAAK,GAAG,CAAC;YAAE,MAAM;QACrB,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,KAAK,CAAC,IAAI,GAAG,CAAC,EAAE,KAAK,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC;QAC5C,CAAC,GAAG,KAAK,GAAG,CAAC,CAAC;IAChB,CAAC;IACD,KAAK,IAAI,CAAC,GAAG,KAAK,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC,IAAI,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC;QAC3C,IAAI,KAAK,GAAG,KAAK,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;QAC3B,IAAI,CAAC,KAAK,IAAI,KAAK,CAAC,MAAM,GAAG,GAAG;YAAE,SAAS;QAC3C,OAAO,KAAK,CAAC,MAAM,IAAI,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,MAAM,CAAC,KAAK,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC;YAAE,KAAK,GAAG,KAAK,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC;QACtG,MAAM,MAAM,GAAG,KAAK,CAAC,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QACnE,IAAI,MAAM,GAAG,KAAK,CAAC;QACnB,MAAM,GAAG,GAAG,KAAK,CAAC,WAAW,CAAC,GAAG,CAAC,CAAC;QACnC,IAAI,GAAG,GAAG,CAAC,IAAI,GAAG,GAAG,KAAK,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YACtC,MAAM,GAAG,GAAG,KAAK,CAAC,KAAK,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC;YACjC,MAAM,GAAG,GAAG,CAAC,MAAM,IAAI,CAAC,IAAI,cAAc,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;QACvD,CAAC;QACD,IAAI,CAAC,MAAM,IAAI,CAAC,MAAM;YAAE,SAAS;QACjC,IAAI,KAAK,CAAC,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM;YAAE,SAAS;QACjD,OAAO,KAAK,CAAC;IACf,CAAC;IACD,OAAO,EAAE,CAAC;AACZ,CAAC"}
|
package/dist/version.d.ts
CHANGED
|
@@ -2,5 +2,5 @@
|
|
|
2
2
|
* Yujin Forge CLI version. Kept in sync with package.json by the npm
|
|
3
3
|
* "version" lifecycle (scripts/sync_version.mjs) so the two never drift.
|
|
4
4
|
*/
|
|
5
|
-
export declare const VERSION = "1.0.
|
|
5
|
+
export declare const VERSION = "1.0.59";
|
|
6
6
|
//# sourceMappingURL=version.d.ts.map
|
package/dist/version.js
CHANGED
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# Concurrency & scale doctrine
|
|
2
|
+
|
|
3
|
+
Every application Forge designs MUST be sized to its expected
|
|
4
|
+
concurrency from day one. Scale is a RELEVAMIENTO input, not an
|
|
5
|
+
afterthought bolted on when the app falls over.
|
|
6
|
+
|
|
7
|
+
## 1. Ask it during requirements
|
|
8
|
+
|
|
9
|
+
During the greenfield relevamiento -- and when scoping a corrective /
|
|
10
|
+
evolutive change that touches a load-bearing path -- ASK, before
|
|
11
|
+
choosing an architecture:
|
|
12
|
+
|
|
13
|
+
- Peak SIMULTANEOUS users / requests? Give an order of magnitude:
|
|
14
|
+
tens, hundreds, thousands, 10k+.
|
|
15
|
+
- Read-heavy or write-heavy? Steady or bursty (spikes)?
|
|
16
|
+
- Latency budget: interactive (< ~200 ms) or batch/async?
|
|
17
|
+
- Growth horizon: will it 10x within a year?
|
|
18
|
+
- Consistency needs: strong (banking) or eventual (feeds)?
|
|
19
|
+
|
|
20
|
+
If the user does not know, PROPOSE a reasonable default AND write the
|
|
21
|
+
assumption explicitly in the spec / `<root>/.forge/sumi-context.md`.
|
|
22
|
+
Never silently assume "a handful of users".
|
|
23
|
+
|
|
24
|
+
## 2. Design a multi-layer architecture with no bottleneck at any tier
|
|
25
|
+
|
|
26
|
+
Pick the layers that the target number actually needs, and make each
|
|
27
|
+
one non-blocking:
|
|
28
|
+
|
|
29
|
+
- Client: pagination, debounce, optimistic UI, local cache -- do not
|
|
30
|
+
fetch the world on every keystroke.
|
|
31
|
+
- Edge / CDN: serve static + cacheable responses close to the user.
|
|
32
|
+
- App tier: STATELESS request handlers so nodes scale horizontally.
|
|
33
|
+
No in-process session/user state that pins a user to one node
|
|
34
|
+
(put it in a shared store / signed token).
|
|
35
|
+
- Concurrency control: connection pools sized to the DB; queues +
|
|
36
|
+
backpressure to absorb spikes; idempotency keys for retried writes;
|
|
37
|
+
rate limits / circuit breakers on hot paths.
|
|
38
|
+
- Data tier (the usual bottleneck): indexed queries; read replicas
|
|
39
|
+
for read-heavy loads; a cache (Redis / KV) in front of hot reads;
|
|
40
|
+
async jobs for slow writes; partition / shard ONLY when the numbers
|
|
41
|
+
demand it.
|
|
42
|
+
- Realtime: fan out via a broker (Redis pub/sub, a queue, a hub), not
|
|
43
|
+
an N-app-node polling loop.
|
|
44
|
+
|
|
45
|
+
## 3. Proportionality (do not gold-plate)
|
|
46
|
+
|
|
47
|
+
Match the architecture to the number. A 20-user internal tool gets a
|
|
48
|
+
simple single-tier design -- adding sharding + a message broker there
|
|
49
|
+
is a defect too. A 10k-concurrent public app gets the full multi-layer
|
|
50
|
+
treatment. The rule is "no bottleneck AND no gold-plating", sized to
|
|
51
|
+
the stated concurrency.
|
|
52
|
+
|
|
53
|
+
Record the target concurrency and the tier decisions in the spec so
|
|
54
|
+
they are traceable and can be revisited when the number changes.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@nac3/forge-cli",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.59",
|
|
4
4
|
"description": "Yujin Forge -- voice-first NAC-3 React development framework. CLI + chat panel + spec ingest + 10-format document reader + voice loop.",
|
|
5
5
|
"license": "SEE LICENSE IN LICENSE",
|
|
6
6
|
"author": "Pablo Kuschnirof <pablo@rpaforce.com>",
|