helixevo 0.4.0 → 0.5.0
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/CHANGELOG.md +16 -0
- package/README.md +15 -2
- package/dashboard/app/api/ontology/route.ts +89 -0
- package/dashboard/app/coevolution/client.tsx +11 -1
- package/dashboard/app/coevolution/page.tsx +3 -2
- package/dashboard/app/commands/page.tsx +23 -0
- package/dashboard/app/guide/page.tsx +438 -185
- package/dashboard/app/ontology/client.tsx +247 -0
- package/dashboard/app/ontology/page.tsx +9 -0
- package/dashboard/app/page.tsx +12 -2
- package/dashboard/app/topology/client.tsx +1 -0
- package/dashboard/components/sidebar-nav.tsx +1 -0
- package/dashboard/lib/data.ts +325 -4
- package/dist/cli.js +614 -1
- package/package.json +1 -1
|
@@ -9,6 +9,9 @@ const TOC = [
|
|
|
9
9
|
{ id: 'quickstart', label: 'Quick Start', icon: '▸' },
|
|
10
10
|
{ id: 'commands', label: 'Commands', icon: '⌘' },
|
|
11
11
|
{ id: 'architecture', label: 'Architecture', icon: '◎' },
|
|
12
|
+
{ id: 'brainstack', label: 'Brain Stack', icon: '◈' },
|
|
13
|
+
{ id: 'loop', label: 'Adaptation Loop', icon: '↺' },
|
|
14
|
+
{ id: 'surfaces', label: 'Surface Map', icon: '▦' },
|
|
12
15
|
{ id: 'watch', label: 'Always-On Learning', icon: '⚡' },
|
|
13
16
|
{ id: 'evolution', label: 'Evolution Pipeline', icon: '⟳' },
|
|
14
17
|
{ id: 'judges', label: 'Multi-Judge System', icon: '⚖' },
|
|
@@ -21,8 +24,10 @@ const TOC = [
|
|
|
21
24
|
{ id: 'network', label: 'Skill Network', icon: '⬡' },
|
|
22
25
|
{ id: 'config', label: 'Configuration', icon: '⚙' },
|
|
23
26
|
{ id: 'data', label: 'Data & Storage', icon: '◫' },
|
|
27
|
+
{ id: 'maturity', label: 'Maturity & Safety', icon: '⛉' },
|
|
24
28
|
{ id: 'manage', label: 'Skill Management', icon: '✎' },
|
|
25
29
|
{ id: 'craft', label: 'Craft Agent', icon: '⚡' },
|
|
30
|
+
{ id: 'glossary', label: 'Glossary', icon: '✦' },
|
|
26
31
|
{ id: 'faq', label: 'FAQ', icon: '?' },
|
|
27
32
|
]
|
|
28
33
|
|
|
@@ -229,7 +234,7 @@ export default function GuidePage() {
|
|
|
229
234
|
<div>
|
|
230
235
|
<div className="guide-toc-title">Field Guide</div>
|
|
231
236
|
<div style={{ fontSize: 11, color: 'var(--text-muted)', marginTop: 4, lineHeight: 1.45 }}>
|
|
232
|
-
|
|
237
|
+
Operator manual and brain architecture map for the current HelixEvo release.
|
|
233
238
|
</div>
|
|
234
239
|
</div>
|
|
235
240
|
<div className="guide-toc-version">v{VERSION}</div>
|
|
@@ -240,8 +245,8 @@ export default function GuidePage() {
|
|
|
240
245
|
</div>
|
|
241
246
|
<div style={{ display: 'flex', gap: 6, flexWrap: 'wrap' }}>
|
|
242
247
|
<a href="#quickstart" className="hero-chip hero-chip-blue" style={{ textDecoration: 'none' }}>Quick Start</a>
|
|
243
|
-
<a href="#
|
|
244
|
-
<a href="#
|
|
248
|
+
<a href="#brainstack" className="hero-chip hero-chip-green" style={{ textDecoration: 'none' }}>Brain Stack</a>
|
|
249
|
+
<a href="#surfaces" className="hero-chip hero-chip-purple" style={{ textDecoration: 'none' }}>Surface Map</a>
|
|
245
250
|
</div>
|
|
246
251
|
</div>
|
|
247
252
|
{TOC.map(item => (
|
|
@@ -261,227 +266,249 @@ export default function GuidePage() {
|
|
|
261
266
|
<div className="guide-content">
|
|
262
267
|
{/* Hero */}
|
|
263
268
|
<div className="guide-hero">
|
|
264
|
-
<div className="guide-hero-badge">
|
|
265
|
-
<h1 className="guide-hero-title">HelixEvo Guide</h1>
|
|
269
|
+
<div className="guide-hero-badge">Operator Manual</div>
|
|
270
|
+
<h1 className="guide-hero-title">HelixEvo Brain Guide</h1>
|
|
266
271
|
<p className="guide-hero-desc">
|
|
267
|
-
A
|
|
268
|
-
|
|
269
|
-
|
|
272
|
+
A structured guide to the current HelixEvo brain: semantic kernel, observation memory,
|
|
273
|
+
pressure, governed response, transfer, topology review, and rollbackable reviewed execution.
|
|
274
|
+
Use it as both an operator manual and a theory-to-product map.
|
|
270
275
|
</p>
|
|
271
276
|
<div className="hero-chip-row" style={{ marginTop: 18 }}>
|
|
272
277
|
<span className="hero-chip hero-chip-blue">v{VERSION}</span>
|
|
273
278
|
<span className="hero-chip hero-chip-purple">{TOC.length} sections</span>
|
|
274
|
-
<span className="hero-chip hero-chip-green">
|
|
275
|
-
<span className="hero-chip hero-chip-yellow">
|
|
279
|
+
<span className="hero-chip hero-chip-green">operator path + theory path</span>
|
|
280
|
+
<span className="hero-chip hero-chip-yellow">governed plasticity reference</span>
|
|
276
281
|
</div>
|
|
277
282
|
|
|
278
283
|
<div className="grid-3" style={{ marginTop: 24, marginBottom: 24 }}>
|
|
279
284
|
<div className="card" style={{ padding: '18px 18px 16px' }}>
|
|
280
|
-
<div style={{ fontSize: 10, fontWeight: 700, color: 'var(--text-muted)', textTransform: 'uppercase', letterSpacing: 0.7, marginBottom: 8 }}>Start
|
|
281
|
-
<div style={{ fontSize: 15, fontWeight: 700, color: 'var(--text)', marginBottom: 6 }}>
|
|
282
|
-
<div style={{ fontSize: 12.5, color: 'var(--text-dim)', lineHeight: 1.6 }}>
|
|
285
|
+
<div style={{ fontSize: 10, fontWeight: 700, color: 'var(--text-muted)', textTransform: 'uppercase', letterSpacing: 0.7, marginBottom: 8 }}>Start operating</div>
|
|
286
|
+
<div style={{ fontSize: 15, fontWeight: 700, color: 'var(--text)', marginBottom: 6 }}>Project setup → Watch / Capture → Co-Evolution → Topology</div>
|
|
287
|
+
<div style={{ fontSize: 12.5, color: 'var(--text-dim)', lineHeight: 1.6 }}>This is the shortest path to seeing pressure, governed response, and structural control in the live product.</div>
|
|
283
288
|
</div>
|
|
284
289
|
<div className="card" style={{ padding: '18px 18px 16px' }}>
|
|
285
|
-
<div style={{ fontSize: 10, fontWeight: 700, color: 'var(--text-muted)', textTransform: 'uppercase', letterSpacing: 0.7, marginBottom: 8 }}>
|
|
286
|
-
<div style={{ fontSize: 15, fontWeight: 700, color: 'var(--text)', marginBottom: 6 }}>
|
|
287
|
-
<div style={{ fontSize: 12.5, color: 'var(--text-dim)', lineHeight: 1.6 }}>The system
|
|
290
|
+
<div style={{ fontSize: 10, fontWeight: 700, color: 'var(--text-muted)', textTransform: 'uppercase', letterSpacing: 0.7, marginBottom: 8 }}>Understand the brain</div>
|
|
291
|
+
<div style={{ fontSize: 15, fontWeight: 700, color: 'var(--text)', marginBottom: 6 }}>Read the stack, then trace one signal through the loop</div>
|
|
292
|
+
<div style={{ fontSize: 12.5, color: 'var(--text-dim)', lineHeight: 1.6 }}>The current system is best understood as layered cognition: semantic kernel → observation → pressure → response → transfer → governance → topology.</div>
|
|
288
293
|
</div>
|
|
289
294
|
<div className="card" style={{ padding: '18px 18px 16px' }}>
|
|
290
295
|
<div style={{ fontSize: 10, fontWeight: 700, color: 'var(--text-muted)', textTransform: 'uppercase', letterSpacing: 0.7, marginBottom: 8 }}>Fast jumps</div>
|
|
291
296
|
<div style={{ display: 'flex', gap: 8, flexWrap: 'wrap' }}>
|
|
292
297
|
<a href="#quickstart" className="hero-chip hero-chip-blue" style={{ textDecoration: 'none' }}>Quick Start</a>
|
|
293
|
-
<a href="#
|
|
294
|
-
<a href="#
|
|
295
|
-
<a href="#
|
|
298
|
+
<a href="#brainstack" className="hero-chip hero-chip-purple" style={{ textDecoration: 'none' }}>Brain Stack</a>
|
|
299
|
+
<a href="#surfaces" className="hero-chip hero-chip-green" style={{ textDecoration: 'none' }}>Surface Map</a>
|
|
300
|
+
<a href="#maturity" className="hero-chip hero-chip-yellow" style={{ textDecoration: 'none' }}>Safety</a>
|
|
296
301
|
</div>
|
|
297
302
|
</div>
|
|
298
303
|
</div>
|
|
299
304
|
|
|
300
305
|
<div className="guide-hero-features">
|
|
301
|
-
<FeatureCard icon="⚡" title="
|
|
302
|
-
<FeatureCard icon="
|
|
303
|
-
<FeatureCard icon="
|
|
304
|
-
<FeatureCard icon="
|
|
306
|
+
<FeatureCard icon="⚡" title="Pressure-Aware" desc="Failures and project gaps become explicit adaptation demand rather than hidden friction" />
|
|
307
|
+
<FeatureCard icon="⇄" title="Governed Routing" desc="Response lanes stay visible: research, specialize, evolve, generalize, and manual review" />
|
|
308
|
+
<FeatureCard icon="◎" title="Topology Control" desc="Reviewed structural changes can now move through prepare, apply, and rollback" />
|
|
309
|
+
<FeatureCard icon="📊" title="Closed-Loop Proof" desc="Backtesting and operator visibility show whether the brain is actually improving" />
|
|
305
310
|
</div>
|
|
306
311
|
</div>
|
|
307
312
|
|
|
308
313
|
{/* ─── Overview ─── */}
|
|
309
|
-
<Section id="overview" title="Overview" subtitle="
|
|
314
|
+
<Section id="overview" title="Overview" subtitle="HelixEvo is now best understood as a governed co-evolving brain.">
|
|
310
315
|
<p className="guide-text">
|
|
311
|
-
HelixEvo
|
|
312
|
-
|
|
313
|
-
|
|
314
|
-
being deployed with a 3-day canary period.
|
|
316
|
+
HelixEvo still captures failures, proposes skill mutations, evaluates them with judges, and deploys improvements carefully.
|
|
317
|
+
What changed over the recent milestone arc is that these mutation mechanics now live inside a larger architecture that senses pressure,
|
|
318
|
+
routes intervention under governance, records transfer evidence, reviews topology, and can execute a safe reviewed subset of structural change with rollback.
|
|
315
319
|
</p>
|
|
316
320
|
<p className="guide-text">
|
|
317
|
-
|
|
318
|
-
|
|
321
|
+
That means the current product should not be explained as only “capture → evolve → validate.” The more truthful frame is:
|
|
322
|
+
<strong> semantic kernel → observation → pressure → response → transfer → governance → topology review → topology execution → operator surfaces.</strong>
|
|
319
323
|
</p>
|
|
320
324
|
<div className="guide-directions">
|
|
321
325
|
<div className="guide-direction">
|
|
322
|
-
<div className="guide-direction-arrow" style={{ color: 'var(--
|
|
326
|
+
<div className="guide-direction-arrow" style={{ color: 'var(--blue)' }}>◎</div>
|
|
323
327
|
<div>
|
|
324
|
-
<strong>
|
|
325
|
-
<span>
|
|
328
|
+
<strong>Sense</strong>
|
|
329
|
+
<span>Failures, project analysis, and activation traces reveal where the system is under demand</span>
|
|
326
330
|
</div>
|
|
327
331
|
</div>
|
|
328
332
|
<div className="guide-direction">
|
|
329
|
-
<div className="guide-direction-arrow" style={{ color: 'var(--
|
|
333
|
+
<div className="guide-direction-arrow" style={{ color: 'var(--purple)' }}>⇄</div>
|
|
330
334
|
<div>
|
|
331
|
-
<strong>
|
|
332
|
-
<span>
|
|
335
|
+
<strong>Respond</strong>
|
|
336
|
+
<span>Governed routes choose whether pressure should drive research, specialize, evolve, generalize, or manual review</span>
|
|
333
337
|
</div>
|
|
334
338
|
</div>
|
|
335
339
|
<div className="guide-direction">
|
|
336
|
-
<div className="guide-direction-arrow" style={{ color: 'var(--
|
|
340
|
+
<div className="guide-direction-arrow" style={{ color: 'var(--green)' }}>⛉</div>
|
|
337
341
|
<div>
|
|
338
|
-
<strong>
|
|
339
|
-
<span>
|
|
342
|
+
<strong>Restructure</strong>
|
|
343
|
+
<span>Accepted topology review can now become prepared, applied, and rollbackable structural change</span>
|
|
340
344
|
</div>
|
|
341
345
|
</div>
|
|
342
346
|
</div>
|
|
343
347
|
<Callout type="tip">
|
|
344
|
-
|
|
345
|
-
|
|
346
|
-
Skill Network, Topology, Projects, Research, and Evolution surfaces.
|
|
348
|
+
Read this guide in two modes: <strong>operator path</strong> if you want to know what to run and which tab to use,
|
|
349
|
+
or <strong>theory path</strong> if you want to understand how ontology, pressure, governance, transfer, and topology now fit together.
|
|
347
350
|
</Callout>
|
|
348
351
|
</Section>
|
|
349
352
|
|
|
350
353
|
{/* ─── Quick Start ─── */}
|
|
351
|
-
<Section id="quickstart" title="Quick Start" subtitle="
|
|
354
|
+
<Section id="quickstart" title="Quick Start" subtitle="The shortest operator path through the current HelixEvo brain loop.">
|
|
352
355
|
<Callout type="info">
|
|
353
356
|
<strong>Prerequisites:</strong> Node.js 18+, <a href="https://bun.sh">Bun</a> (for building),
|
|
354
357
|
and <a href="https://docs.anthropic.com/en/docs/claude-code">Claude CLI</a> with a Claude Max plan.
|
|
355
358
|
Prefer <code>claude auth login</code> managed credentials over exporting a hardcoded <code>CLAUDE_CODE_OAUTH_TOKEN</code>.
|
|
356
359
|
</Callout>
|
|
357
360
|
|
|
358
|
-
<Step n={1} title="Install HelixEvo">
|
|
359
|
-
<Code title="Terminal">{`#
|
|
361
|
+
<Step n={1} title="Install and initialize HelixEvo">
|
|
362
|
+
<Code title="Terminal">{`# Install from npm
|
|
360
363
|
npm install -g helixevo
|
|
361
364
|
|
|
362
|
-
#
|
|
363
|
-
|
|
364
|
-
cd helixevo && npm install && npm run build && npm link`}</Code>
|
|
365
|
-
</Step>
|
|
366
|
-
|
|
367
|
-
<Step n={2} title="Initialize your skill ecosystem">
|
|
368
|
-
<Code title="Terminal">{`helixevo init`}</Code>
|
|
365
|
+
# Initialize your skill ecosystem
|
|
366
|
+
helixevo init`}</Code>
|
|
369
367
|
<p className="guide-text-sm">
|
|
370
|
-
|
|
371
|
-
and generates skill tests for each skill. It also creates the data directory at <code>~/.helix/</code>.
|
|
368
|
+
Initialization imports existing skills, generates regression tests, and creates the runtime memory under <code>~/.helix/</code>.
|
|
372
369
|
</p>
|
|
373
370
|
</Step>
|
|
374
371
|
|
|
375
|
-
<Step n={
|
|
376
|
-
<Code title="Terminal">{
|
|
372
|
+
<Step n={2} title="Analyze a real project so the brain has context">
|
|
373
|
+
<Code title="Terminal">{`# Analyze the current repository
|
|
374
|
+
helixevo project-setup .
|
|
375
|
+
|
|
376
|
+
# Or analyze another project path
|
|
377
|
+
helixevo project-setup ~/myapp --verbose`}</Code>
|
|
377
378
|
<p className="guide-text-sm">
|
|
378
|
-
|
|
379
|
-
as structured failure records.
|
|
379
|
+
<code>project-setup</code> is now a key operator entry point because it persists project context, activation traces, and pressure signals instead of leaving the dashboard blind to real project demand.
|
|
380
380
|
</p>
|
|
381
381
|
</Step>
|
|
382
382
|
|
|
383
|
-
<Step n={
|
|
384
|
-
<Code title="Terminal">{
|
|
383
|
+
<Step n={3} title="Feed the observation layer">
|
|
384
|
+
<Code title="Terminal">{`# Continuous observation
|
|
385
|
+
helixevo watch --project myapp
|
|
386
|
+
|
|
387
|
+
# Or one-off capture
|
|
388
|
+
helixevo capture path/to/session.json --project myapp`}</Code>
|
|
385
389
|
<p className="guide-text-sm">
|
|
386
|
-
|
|
387
|
-
improvements as canaries. Use <code>--dry-run</code> to preview without applying.
|
|
390
|
+
Observation is where corrections become structured memory. Without this layer, the response and topology layers have nothing truthful to operate on.
|
|
388
391
|
</p>
|
|
389
392
|
</Step>
|
|
390
393
|
|
|
391
|
-
<Step n={
|
|
392
|
-
<Code title="Terminal">{`#
|
|
393
|
-
helixevo
|
|
394
|
+
<Step n={4} title="Run the response loop">
|
|
395
|
+
<Code title="Terminal">{`# Proposal-level evolution
|
|
396
|
+
helixevo evolve --verbose
|
|
394
397
|
|
|
395
|
-
#
|
|
396
|
-
helixevo
|
|
397
|
-
|
|
398
|
-
|
|
399
|
-
|
|
398
|
+
# Structural review + execution status
|
|
399
|
+
helixevo graph --optimize
|
|
400
|
+
helixevo topology --status`}</Code>
|
|
401
|
+
<p className="guide-text-sm">
|
|
402
|
+
<code>evolve</code> mutates skills directly, while <code>graph --optimize</code> and <code>topology</code> expose the higher-level structural review and execution loop.
|
|
403
|
+
</p>
|
|
404
|
+
</Step>
|
|
400
405
|
|
|
401
|
-
|
|
402
|
-
helixevo
|
|
406
|
+
<Step n={5} title="Use the dashboard as the operator cockpit">
|
|
407
|
+
<Code title="Terminal">{`helixevo dashboard
|
|
408
|
+
# Then visit Overview → Co-Evolution → Topology → Network`}</Code>
|
|
403
409
|
<p className="guide-text-sm">
|
|
404
|
-
The dashboard prefers port <code>3847</code
|
|
410
|
+
The dashboard prefers port <code>3847</code>, reuses a known managed dashboard when possible, and otherwise falls forward to the next open port.
|
|
411
|
+
Use <strong>Co-Evolution</strong> for routed pressure and <strong>Topology</strong> for reviewed structural control.
|
|
405
412
|
</p>
|
|
406
413
|
</Step>
|
|
407
414
|
</Section>
|
|
408
415
|
|
|
409
416
|
{/* ─── Commands ─── */}
|
|
410
|
-
<Section id="commands" title="Commands" subtitle="
|
|
417
|
+
<Section id="commands" title="Commands" subtitle="Command surfaces grouped by the job they do in the current brain loop.">
|
|
418
|
+
<p className="guide-text">
|
|
419
|
+
The CLI is now easier to reason about if you group commands by role: <strong>observe</strong>, <strong>respond</strong>,
|
|
420
|
+
<strong>restructure</strong>, and <strong>prove</strong>. The Guide now explicitly includes the current release-critical additions
|
|
421
|
+
such as <code>project-setup</code> and <code>topology</code>.
|
|
422
|
+
</p>
|
|
411
423
|
<div className="guide-command-grid">
|
|
412
424
|
{[
|
|
413
425
|
{
|
|
414
|
-
cmd: 'helixevo
|
|
415
|
-
desc: '
|
|
416
|
-
flags: ['--
|
|
417
|
-
},
|
|
418
|
-
{
|
|
419
|
-
cmd: 'helixevo metrics',
|
|
420
|
-
desc: 'Show correction rates per skill, trends over time, and whether each evolution actually reduced corrections. The proof that HelixEvo works.',
|
|
421
|
-
flags: ['--verbose'],
|
|
426
|
+
cmd: 'helixevo init',
|
|
427
|
+
desc: 'Initialize the skill ecosystem, generate tests, and build the first local brain memory under ~/.helix/.',
|
|
428
|
+
flags: ['--skills-paths <paths...>', '--skip-tests'],
|
|
422
429
|
},
|
|
423
430
|
{
|
|
424
|
-
cmd: 'helixevo
|
|
425
|
-
desc: '
|
|
426
|
-
flags: ['--verbose'],
|
|
431
|
+
cmd: 'helixevo project-setup <path>',
|
|
432
|
+
desc: 'Analyze a project, persist a project profile, emit activation traces, and turn missing capability into project-level pressure.',
|
|
433
|
+
flags: ['--dry-run', '--verbose'],
|
|
427
434
|
},
|
|
428
435
|
{
|
|
429
|
-
cmd: 'helixevo
|
|
430
|
-
desc: '
|
|
431
|
-
flags: ['--verbose'],
|
|
436
|
+
cmd: 'helixevo watch',
|
|
437
|
+
desc: 'Always-on observation mode. Watches for corrections in real time, captures failures automatically, and triggers evolution when thresholds are met.',
|
|
438
|
+
flags: ['--project <name>', '--events <path>', '--verbose', '--no-evolve'],
|
|
432
439
|
},
|
|
433
440
|
{
|
|
434
441
|
cmd: 'helixevo capture <session>',
|
|
435
|
-
desc: 'Extract failure records from a
|
|
442
|
+
desc: 'Extract failure records from a session file when you want one-off observation instead of continuous watch mode.',
|
|
436
443
|
flags: ['--project <name>', '--verbose'],
|
|
437
444
|
},
|
|
438
445
|
{
|
|
439
446
|
cmd: 'helixevo evolve',
|
|
440
|
-
desc: 'Run the
|
|
447
|
+
desc: 'Run the proposal-level mutation pipeline: cluster failures, propose changes, judge them, regression test them, and admit winners.',
|
|
441
448
|
flags: ['--dry-run', '--verbose', '--max-proposals <n>'],
|
|
442
449
|
},
|
|
443
450
|
{
|
|
444
|
-
cmd: 'helixevo
|
|
445
|
-
desc: '
|
|
446
|
-
flags: ['--dry-run', '--verbose'],
|
|
451
|
+
cmd: 'helixevo research',
|
|
452
|
+
desc: 'Run the discovery lane for missing capability, frontier practices, and experimental skill opportunities.',
|
|
453
|
+
flags: ['--project <path>', '--max-hypotheses <n>', '--dry-run', '--verbose'],
|
|
447
454
|
},
|
|
448
455
|
{
|
|
449
456
|
cmd: 'helixevo specialize --project <name>',
|
|
450
|
-
desc: '
|
|
457
|
+
desc: 'Push knowledge downward into project-specific variants when local context matters more than shared abstraction.',
|
|
451
458
|
flags: ['--dry-run', '--verbose'],
|
|
452
459
|
},
|
|
453
460
|
{
|
|
454
|
-
cmd: 'helixevo
|
|
455
|
-
desc: '
|
|
456
|
-
flags: ['--
|
|
461
|
+
cmd: 'helixevo generalize',
|
|
462
|
+
desc: 'Push recurring multi-project motifs upward into reusable shared knowledge with transfer evidence.',
|
|
463
|
+
flags: ['--dry-run', '--verbose'],
|
|
457
464
|
},
|
|
458
465
|
{
|
|
459
466
|
cmd: 'helixevo graph',
|
|
460
|
-
desc: '
|
|
461
|
-
flags: ['--mermaid', '--obsidian <vault>', '--rebuild', '--optimize'],
|
|
467
|
+
desc: 'Inspect the network and, with --optimize, refresh topology review candidates for structural issues and opportunities.',
|
|
468
|
+
flags: ['--mermaid', '--obsidian <vault>', '--rebuild', '--optimize', '--verbose'],
|
|
469
|
+
},
|
|
470
|
+
{
|
|
471
|
+
cmd: 'helixevo ontology',
|
|
472
|
+
desc: 'Govern the ontology frontier explicitly. Refresh concept hypotheses from recurring evidence, review them with promote/reject/defer decisions, and deprecate approved extensions without allowing free-form semantic drift.',
|
|
473
|
+
flags: ['--status', '--refresh', '--review <conceptId>', '--decision <promote|reject|defer>', '--rationale <text>', '--deprecate <conceptId>', '--verbose'],
|
|
474
|
+
},
|
|
475
|
+
{
|
|
476
|
+
cmd: 'helixevo topology',
|
|
477
|
+
desc: 'Move accepted topology review through prepare, apply, and rollback. This is the explicit control surface for reviewed structural execution.',
|
|
478
|
+
flags: ['--status', '--prepare <candidateId>', '--apply <planId>', '--rollback <planId>', '--verbose'],
|
|
479
|
+
},
|
|
480
|
+
{
|
|
481
|
+
cmd: 'helixevo health',
|
|
482
|
+
desc: 'Assess cohesion, coverage, balance, and transfer so you can tell whether the network is learning in a reusable and connected way.',
|
|
483
|
+
flags: ['--verbose'],
|
|
484
|
+
},
|
|
485
|
+
{
|
|
486
|
+
cmd: 'helixevo metrics',
|
|
487
|
+
desc: 'Measure whether evolution actually reduces corrections over time. This is the primary proof command.',
|
|
488
|
+
flags: ['--verbose'],
|
|
462
489
|
},
|
|
463
490
|
{
|
|
464
491
|
cmd: 'helixevo dashboard',
|
|
465
|
-
desc: 'Open the
|
|
492
|
+
desc: 'Open the premium operator dashboard. It prefers localhost:3847, reuses a known managed dashboard, falls forward if needed, and can auto-update before launch.',
|
|
466
493
|
flags: ['--background', '--stop', '--port <port>', '--no-auto-update'],
|
|
467
494
|
},
|
|
468
495
|
{
|
|
469
496
|
cmd: 'helixevo status',
|
|
470
|
-
desc: 'Show system
|
|
497
|
+
desc: 'Show fast system state without deeper LLM analysis.',
|
|
471
498
|
flags: [],
|
|
472
499
|
},
|
|
473
500
|
{
|
|
474
501
|
cmd: 'helixevo report',
|
|
475
|
-
desc: 'Generate a
|
|
476
|
-
flags: ['--
|
|
502
|
+
desc: 'Generate a human-readable summary of evolution activity over a time window.',
|
|
503
|
+
flags: ['--days <n>', '--output <path>'],
|
|
477
504
|
},
|
|
478
|
-
].map(c => (
|
|
505
|
+
].map((c) => (
|
|
479
506
|
<div key={c.cmd} className="guide-command-card">
|
|
480
507
|
<code className="guide-command-name">{c.cmd}</code>
|
|
481
508
|
<p className="guide-command-desc">{c.desc}</p>
|
|
482
509
|
{c.flags.length > 0 && (
|
|
483
510
|
<div className="guide-command-flags">
|
|
484
|
-
{c.flags.map(f => <code key={f} className="guide-command-flag">{f}</code>)}
|
|
511
|
+
{c.flags.map((f) => <code key={f} className="guide-command-flag">{f}</code>)}
|
|
485
512
|
</div>
|
|
486
513
|
)}
|
|
487
514
|
</div>
|
|
@@ -489,46 +516,180 @@ helixevo status`}</Code>
|
|
|
489
516
|
</div>
|
|
490
517
|
|
|
491
518
|
<Callout type="tip">
|
|
492
|
-
|
|
493
|
-
|
|
519
|
+
A good mental grouping is: <strong>observe</strong> with <code>project-setup</code>, <code>watch</code>, and <code>capture</code>;
|
|
520
|
+
<strong>respond</strong> with <code>research</code>, <code>specialize</code>, <code>evolve</code>, and <code>generalize</code>;
|
|
521
|
+
<strong>restructure</strong> with <code>graph --optimize</code> plus <code>topology</code>; and <strong>prove</strong> with <code>metrics</code>, <code>health</code>, and <code>report</code>.
|
|
494
522
|
</Callout>
|
|
495
523
|
</Section>
|
|
496
524
|
|
|
497
525
|
{/* ─── Architecture ─── */}
|
|
498
|
-
<Section id="architecture" title="Architecture" subtitle="How the
|
|
499
|
-
<h3 className="guide-h3">
|
|
526
|
+
<Section id="architecture" title="Architecture" subtitle="How the classic evolution pipeline now sits inside a broader co-evolving brain.">
|
|
527
|
+
<h3 className="guide-h3">Classic mutation pipeline</h3>
|
|
500
528
|
<p className="guide-text">
|
|
501
|
-
|
|
502
|
-
|
|
529
|
+
The original HelixEvo mutation pipeline is still real and still important. Capture, clustering, proposal generation,
|
|
530
|
+
judging, regression, and canary deployment remain the core mutation engine. What changed in the recent milestone arc is that
|
|
531
|
+
this engine now operates inside a bigger system that senses pressure, routes intervention, persists governance,
|
|
532
|
+
reviews topology, and executes a safe subset of structural changes with rollback.
|
|
503
533
|
</p>
|
|
504
534
|
<ArchitectureDiagram />
|
|
505
535
|
|
|
506
|
-
<h3 className="guide-h3">Brain
|
|
536
|
+
<h3 className="guide-h3">Brain foundation</h3>
|
|
507
537
|
<div className="grid-2" style={{ gap: 12, marginBottom: 20 }}>
|
|
508
|
-
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
|
|
513
|
-
|
|
514
|
-
|
|
515
|
-
|
|
516
|
-
|
|
517
|
-
|
|
518
|
-
|
|
519
|
-
|
|
520
|
-
|
|
521
|
-
<div style={{ fontSize: 11, fontWeight: 700, color: 'var(--yellow)', textTransform: 'uppercase', letterSpacing: 1 }}>Pressure signals</div>
|
|
522
|
-
<div style={{ fontSize: 12, color: 'var(--text-dim)', marginTop: 4 }}>Turn failures and project gaps into explicit adaptation demand, routing attention into Network, Projects, and Research.</div>
|
|
523
|
-
</div>
|
|
538
|
+
{[
|
|
539
|
+
['Ontology', 'var(--blue)', 'Stable semantic kernel for skills, projects, tasks, capabilities, artifacts, and mutations.'],
|
|
540
|
+
['Activation traces', 'var(--green)', 'Observation memory showing which skills and gaps were active when capture or project analysis occurred.'],
|
|
541
|
+
['Pressure signals', 'var(--yellow)', 'Explicit adaptation demand derived from failures and project gaps.'],
|
|
542
|
+
['Interventions', 'var(--purple)', 'The response ledger across research, specialize, evolve, generalize, and manual-review lanes.'],
|
|
543
|
+
['Governance', 'var(--blue)', 'Derived or operator-selected routing bias that explains why the system is steering one way rather than another.'],
|
|
544
|
+
['Topology memory', 'var(--green)', 'Review candidates, decisions, apply plans, snapshots, artifacts, and rollbackable structural state.'],
|
|
545
|
+
].map(([label, color, desc]) => (
|
|
546
|
+
<div key={String(label)} className="guide-dimension-card" style={{ borderLeftColor: String(color) }}>
|
|
547
|
+
<div style={{ fontSize: 11, fontWeight: 700, color: String(color), textTransform: 'uppercase', letterSpacing: 1 }}>{label}</div>
|
|
548
|
+
<div style={{ fontSize: 12, color: 'var(--text-dim)', marginTop: 4 }}>{desc}</div>
|
|
549
|
+
</div>
|
|
550
|
+
))}
|
|
524
551
|
</div>
|
|
525
552
|
|
|
526
|
-
<h3 className="guide-h3">Three-
|
|
553
|
+
<h3 className="guide-h3">Three-layer skill hierarchy</h3>
|
|
527
554
|
<p className="guide-text">
|
|
528
|
-
|
|
529
|
-
while <code>
|
|
555
|
+
The skill hierarchy still matters. <code>specialize</code> pushes knowledge downward into project context,
|
|
556
|
+
while <code>generalize</code> promotes reusable knowledge upward into shared layers. The newer pressure, transfer, and topology work does not replace this hierarchy — it makes the hierarchy more governable.
|
|
530
557
|
</p>
|
|
531
558
|
<HierarchyDiagram />
|
|
559
|
+
|
|
560
|
+
<Callout type="tip">
|
|
561
|
+
The next three sections are the real bridge from theory to product: the <strong>9-layer conceptual stack</strong>,
|
|
562
|
+
a concrete <strong>end-to-end adaptation loop</strong>, and a <strong>dashboard surface map</strong> showing where each part of the brain becomes visible.
|
|
563
|
+
</Callout>
|
|
564
|
+
</Section>
|
|
565
|
+
|
|
566
|
+
{/* ─── Brain Stack ─── */}
|
|
567
|
+
<Section id="brainstack" title="Brain Stack" subtitle="The clearest current mental model for HelixEvo is a layered stack, not a flat feature list.">
|
|
568
|
+
<div className="grid-2" style={{ gap: 12 }}>
|
|
569
|
+
{[
|
|
570
|
+
{
|
|
571
|
+
title: '1. Semantic layer',
|
|
572
|
+
color: 'var(--blue)',
|
|
573
|
+
desc: 'Ontology and invariants define what kinds of things HelixEvo can talk about and persist truthfully.',
|
|
574
|
+
where: 'Visible in: ontology-aware graph summaries, skill metadata, and brain foundation summaries.'
|
|
575
|
+
},
|
|
576
|
+
{
|
|
577
|
+
title: '2. Observation layer',
|
|
578
|
+
color: 'var(--green)',
|
|
579
|
+
desc: 'Failures, project analysis, and activation traces record what happened, where it happened, and which skills were active.',
|
|
580
|
+
where: 'Visible in: capture, project-setup, Projects, and Evolution.'
|
|
581
|
+
},
|
|
582
|
+
{
|
|
583
|
+
title: '3. Pressure layer',
|
|
584
|
+
color: 'var(--yellow)',
|
|
585
|
+
desc: 'Pressure signals convert raw observation into explicit adaptation demand at local, project, and network scope. Motifs aggregate recurring patterns above single signals.',
|
|
586
|
+
where: 'Visible in: Overview, Co-Evolution, Network, Projects, and Research.'
|
|
587
|
+
},
|
|
588
|
+
{
|
|
589
|
+
title: '4. Response layer',
|
|
590
|
+
color: 'var(--purple)',
|
|
591
|
+
desc: 'Interventions route pressure into research, specialize, evolve, generalize, or manual review. This is where the system decides how to act.',
|
|
592
|
+
where: 'Visible in: Co-Evolution backlog, recent interventions, and route recommendations.'
|
|
593
|
+
},
|
|
594
|
+
{
|
|
595
|
+
title: '5. Transfer layer',
|
|
596
|
+
color: 'var(--blue)',
|
|
597
|
+
desc: 'Transfer events record when reusable knowledge was actually promoted, not just suggested. This is how motif-level closure becomes truthful.',
|
|
598
|
+
where: 'Visible in: Co-Evolution promotion queue, transfer evidence, and Research / Network transfer summaries.'
|
|
599
|
+
},
|
|
600
|
+
{
|
|
601
|
+
title: '6. Governance layer',
|
|
602
|
+
color: 'var(--green)',
|
|
603
|
+
desc: 'Governance selects the current routing posture: derived automatically from conditions or pinned manually by the operator.',
|
|
604
|
+
where: 'Visible in: Co-Evolution and Topology governance chips, rationale, and profile explanation.'
|
|
605
|
+
},
|
|
606
|
+
{
|
|
607
|
+
title: '7. Topology review layer',
|
|
608
|
+
color: 'var(--yellow)',
|
|
609
|
+
desc: 'Graph optimization and network health produce structural review candidates. Operator decisions persist review memory instead of disappearing into an ephemeral suggestion list.',
|
|
610
|
+
where: 'Visible in: graph --optimize, Topology review queue, and decision ledger.'
|
|
611
|
+
},
|
|
612
|
+
{
|
|
613
|
+
title: '8. Topology execution layer',
|
|
614
|
+
color: 'var(--purple)',
|
|
615
|
+
desc: 'Accepted safe candidates can now become apply plans with snapshots, artifacts, apply state, and rollback. Riskier classes remain bounded.',
|
|
616
|
+
where: 'Visible in: Topology accepted-ready queue, prepared queue, applied history, and /api/topology-apply.'
|
|
617
|
+
},
|
|
618
|
+
{
|
|
619
|
+
title: '9. Surface layer',
|
|
620
|
+
color: 'var(--blue)',
|
|
621
|
+
desc: 'The dashboard is not decoration; each tab exposes a different slice of the brain so operators can inspect, steer, and verify it.',
|
|
622
|
+
where: 'Visible in: Overview, Co-Evolution, Network, Topology, Projects, Research, Evolution, Commands, and Guide.'
|
|
623
|
+
},
|
|
624
|
+
].map((layer) => (
|
|
625
|
+
<div key={layer.title} className="guide-dimension-card" style={{ borderLeftColor: layer.color }}>
|
|
626
|
+
<div style={{ fontSize: 12, fontWeight: 700, color: layer.color, letterSpacing: 0.2 }}>{layer.title}</div>
|
|
627
|
+
<div style={{ fontSize: 12, color: 'var(--text-dim)', marginTop: 6, lineHeight: 1.6 }}>{layer.desc}</div>
|
|
628
|
+
<div style={{ fontSize: 11, color: 'var(--text-muted)', marginTop: 8, lineHeight: 1.55 }}>{layer.where}</div>
|
|
629
|
+
</div>
|
|
630
|
+
))}
|
|
631
|
+
</div>
|
|
632
|
+
</Section>
|
|
633
|
+
|
|
634
|
+
{/* ─── Adaptation Loop ─── */}
|
|
635
|
+
<Section id="loop" title="End-to-End Adaptation Loop" subtitle="One realistic signal can now travel through observation, pressure, response, review, and safe structural execution.">
|
|
636
|
+
<p className="guide-text">
|
|
637
|
+
This example is the easiest way to connect the theory to the product. It shows how a real capability gap can move through the current HelixEvo brain.
|
|
638
|
+
</p>
|
|
639
|
+
<Code title="Worked example">{`Project setup spots repeated UI architecture gaps
|
|
640
|
+
→ activation trace records the active skills + missing capability
|
|
641
|
+
→ pressure signal opens for the project and contributes to a recurring motif
|
|
642
|
+
→ governance biases the route toward research / specialize / generalize
|
|
643
|
+
→ an intervention is recorded in the response ledger
|
|
644
|
+
→ transfer events accumulate if reusable knowledge is promoted
|
|
645
|
+
→ graph --optimize surfaces a topology review candidate if the structure itself needs cleanup
|
|
646
|
+
→ operator accepts the candidate in /topology
|
|
647
|
+
→ helixevo topology --prepare creates an apply plan + snapshot + artifact
|
|
648
|
+
→ helixevo topology --apply changes the effective graph through the override layer
|
|
649
|
+
→ helixevo topology --rollback restores the before-apply snapshot if needed`}</Code>
|
|
650
|
+
|
|
651
|
+
<div className="guide-pipeline" style={{ marginTop: 18 }}>
|
|
652
|
+
<PipelineStep icon="1" title="Observe" color="var(--blue)" desc="Project analysis or failure capture persists activation-aware observation." />
|
|
653
|
+
<div className="guide-pipeline-connector" />
|
|
654
|
+
<PipelineStep icon="2" title="Pressurize" color="var(--yellow)" desc="Observation becomes explicit demand through pressure signals and recurring motifs." />
|
|
655
|
+
<div className="guide-pipeline-connector" />
|
|
656
|
+
<PipelineStep icon="3" title="Route" color="var(--purple)" desc="Governance biases the next lane: research, specialize, evolve, generalize, or manual review." />
|
|
657
|
+
<div className="guide-pipeline-connector" />
|
|
658
|
+
<PipelineStep icon="4" title="Restructure" color="var(--green)" desc="Topology review and execution handle cases where the structure itself, not just a skill rule, must change." />
|
|
659
|
+
<div className="guide-pipeline-connector" />
|
|
660
|
+
<PipelineStep icon="5" title="Prove" color="var(--blue)" desc="Metrics, transfer evidence, artifacts, and rollback discipline show whether the system improved truthfully." />
|
|
661
|
+
</div>
|
|
662
|
+
|
|
663
|
+
<Callout type="info">
|
|
664
|
+
A key current semantic rule is that <strong>motif-level transfer can address recurring network pressure without falsely claiming that every local signal is closed</strong>.
|
|
665
|
+
That rule is one of the biggest maturity improvements in the recent theory and implementation arc.
|
|
666
|
+
</Callout>
|
|
667
|
+
</Section>
|
|
668
|
+
|
|
669
|
+
{/* ─── Surface Map ─── */}
|
|
670
|
+
<Section id="surfaces" title="Dashboard Surface Map" subtitle="Each tab is a different control or observability surface for the same brain.">
|
|
671
|
+
<div className="grid-2" style={{ gap: 12 }}>
|
|
672
|
+
{[
|
|
673
|
+
['Overview', 'var(--blue)', 'Top-level cockpit for frontier state, brain foundation, pressure totals, topology review counts, and prepared/applied structural state.'],
|
|
674
|
+
['Co-Evolution', 'var(--purple)', 'The response cockpit. Use it to inspect routed pressure, governance mode, promotion queue, interventions, and transfer evidence.'],
|
|
675
|
+
['Skill Network', 'var(--green)', 'Graph-level understanding: relationships, co-evolution signals, inspector context, and structural handoff links.'],
|
|
676
|
+
['Ontology', 'var(--blue)', 'Semantic control surface for kernel visibility, frontier review, approved extensions, and ontology change events.'],
|
|
677
|
+
['Topology', 'var(--yellow)', 'Governed plasticity surface for review decisions, accepted-ready queue, prepared plans, apply, rollback, and execution history.'],
|
|
678
|
+
['Projects', 'var(--blue)', 'Project intake and project-aware pressure surface. Best for capability gaps, activation traces, and promotion feeders.'],
|
|
679
|
+
['Research', 'var(--purple)', 'Discovery-oriented view grounded in current pressure and routed recommendations rather than disconnected idea generation.'],
|
|
680
|
+
['Evolution', 'var(--green)', 'Proposal-centric evidence view: judge scores, artifact provenance, and iteration history.'],
|
|
681
|
+
['Commands + Guide', 'var(--yellow)', 'Reference surfaces: one for command execution semantics, one for operator mental model and architecture.'],
|
|
682
|
+
].map(([title, color, desc]) => (
|
|
683
|
+
<div key={String(title)} className="guide-dimension-card" style={{ borderLeftColor: String(color) }}>
|
|
684
|
+
<div style={{ fontSize: 12, fontWeight: 700, color: String(color), letterSpacing: 0.2 }}>{title}</div>
|
|
685
|
+
<div style={{ fontSize: 12, color: 'var(--text-dim)', marginTop: 6, lineHeight: 1.6 }}>{desc}</div>
|
|
686
|
+
</div>
|
|
687
|
+
))}
|
|
688
|
+
</div>
|
|
689
|
+
<Callout type="tip">
|
|
690
|
+
If you are debugging current state, the best sequence is usually: <strong>Overview → Co-Evolution → Topology → Skill Network → Projects / Research</strong>.
|
|
691
|
+
That path mirrors the stack from summary → routed demand → structural review/execution → graph context → project or discovery detail.
|
|
692
|
+
</Callout>
|
|
532
693
|
</Section>
|
|
533
694
|
|
|
534
695
|
{/* ─── Always-On Learning ─── */}
|
|
@@ -902,7 +1063,7 @@ generation: 3
|
|
|
902
1063
|
</Section>
|
|
903
1064
|
|
|
904
1065
|
{/* ─── Data & Storage ─── */}
|
|
905
|
-
<Section id="data" title="Data & Storage" subtitle="
|
|
1066
|
+
<Section id="data" title="Data & Storage" subtitle="The runtime memory is now easier to understand as grouped cognitive layers, not just a flat folder tree.">
|
|
906
1067
|
<Code title="~/.helix/ directory structure">{`~/.helix/
|
|
907
1068
|
├── config.json # Configuration
|
|
908
1069
|
├── failures.jsonl # Captured failure records (append-only)
|
|
@@ -921,45 +1082,118 @@ generation: 3
|
|
|
921
1082
|
├── evolution-artifacts.jsonl # Proposal/iteration evidence artifacts
|
|
922
1083
|
├── frontier.json # Pareto frontier (top-K programs)
|
|
923
1084
|
├── evolution-history.json # All evolution iterations + proposals
|
|
924
|
-
├── skill-tests.jsonl
|
|
1085
|
+
├── skill-tests.jsonl # Regression test cases (append-only)
|
|
925
1086
|
├── skill-graph.json # Cached network (nodes + edges + ontology version)
|
|
926
1087
|
├── canary-registry.json # Active canary deployments
|
|
927
1088
|
├── knowledge-buffer.json # Research discoveries + drafts
|
|
1089
|
+
├── ontology/
|
|
1090
|
+
│ ├── kernel.json # Materialized ontology kernel snapshot
|
|
1091
|
+
│ ├── extensions.json # Approved ontology extensions
|
|
1092
|
+
│ ├── frontier.json # Provisional frontier concepts awaiting review
|
|
1093
|
+
│ ├── reviews.jsonl # Ontology review decisions
|
|
1094
|
+
│ └── change-log.jsonl # Native ontology change events
|
|
928
1095
|
├── general/ # Skills (SKILL.md files)
|
|
929
1096
|
│ ├── my-skill/SKILL.md
|
|
930
1097
|
│ └── ...
|
|
931
1098
|
├── backups/ # Pre-canary skill backups
|
|
932
1099
|
└── reports/ # Generated evolution reports`}</Code>
|
|
933
1100
|
|
|
934
|
-
<h3 className="guide-h3">
|
|
935
|
-
<div className="grid-2" style={{ gap: 12 }}>
|
|
1101
|
+
<h3 className="guide-h3">Memory groups</h3>
|
|
1102
|
+
<div className="grid-2" style={{ gap: 12, marginBottom: 20 }}>
|
|
1103
|
+
{[
|
|
1104
|
+
['Observation memory', 'var(--blue)', 'failures.jsonl + activation-traces.jsonl capture what happened, where it happened, and which skills were active.'],
|
|
1105
|
+
['Pressure & response memory', 'var(--yellow)', 'pressure-signals.jsonl + pressure-interventions.jsonl + transfer-events.jsonl describe demand, routing, and reusable promotion evidence.'],
|
|
1106
|
+
['Ontology frontier memory', 'var(--blue)', 'ontology/kernel.json + ontology/frontier.json + ontology/extensions.json + ontology/reviews.jsonl + ontology/change-log.jsonl preserve semantic kernel state, provisional concepts, approved extensions, and review/change lineage.'],
|
|
1107
|
+
['Governance & review memory', 'var(--purple)', 'governance-state.json + topology-review-candidates.json + topology-review-decisions.jsonl preserve why structural decisions are being made.'],
|
|
1108
|
+
['Topology execution memory', 'var(--green)', 'topology-overrides.json + topology-snapshots.json + topology-apply-plans.json + topology-executions.jsonl + topology-artifacts.jsonl preserve reviewed structural execution and rollback.'],
|
|
1109
|
+
['Evaluation & frontier memory', 'var(--blue)', 'evolution-history.json + evolution-artifacts.jsonl + skill-tests.jsonl + canary-registry.json + frontier.json preserve proof, guardrails, and best configurations.'],
|
|
1110
|
+
['Discovery memory', 'var(--purple)', 'knowledge-buffer.json keeps research discoveries and drafts so failed experiments can be iterated instead of lost.'],
|
|
1111
|
+
].map(([title, color, desc]) => (
|
|
1112
|
+
<div key={String(title)} className="guide-dimension-card" style={{ borderLeftColor: String(color) }}>
|
|
1113
|
+
<div style={{ fontSize: 12, fontWeight: 700, color: String(color), letterSpacing: 0.2 }}>{title}</div>
|
|
1114
|
+
<div style={{ fontSize: 12, color: 'var(--text-dim)', marginTop: 6, lineHeight: 1.6 }}>{desc}</div>
|
|
1115
|
+
</div>
|
|
1116
|
+
))}
|
|
1117
|
+
</div>
|
|
1118
|
+
|
|
1119
|
+
<h3 className="guide-h3">Representative data formats</h3>
|
|
1120
|
+
<div className="grid-3" style={{ gap: 12 }}>
|
|
936
1121
|
<div className="guide-data-card">
|
|
937
1122
|
<div className="guide-data-title">Failure Record</div>
|
|
938
1123
|
<Code>{`{
|
|
939
1124
|
"id": "f_abc123",
|
|
940
1125
|
"sessionId": "session-001",
|
|
941
1126
|
"project": "myapp",
|
|
942
|
-
"userRequest": "Add a login page",
|
|
943
|
-
"agentAction": "Created login.tsx",
|
|
944
|
-
"correction": "Use the existing auth hook",
|
|
945
1127
|
"correctionType": "verbal",
|
|
946
1128
|
"skillsActive": ["react-patterns"],
|
|
947
1129
|
"resolved": false
|
|
948
1130
|
}`}</Code>
|
|
949
1131
|
</div>
|
|
950
1132
|
<div className="guide-data-card">
|
|
951
|
-
<div className="guide-data-title">
|
|
1133
|
+
<div className="guide-data-title">Pressure Intervention</div>
|
|
952
1134
|
<Code>{`{
|
|
953
|
-
"id": "
|
|
954
|
-
"
|
|
955
|
-
"
|
|
956
|
-
"
|
|
957
|
-
"
|
|
958
|
-
"
|
|
959
|
-
"consecutivePasses": 5
|
|
1135
|
+
"id": "pi_123",
|
|
1136
|
+
"interventionType": "generalize",
|
|
1137
|
+
"status": "completed",
|
|
1138
|
+
"impact": "structural",
|
|
1139
|
+
"projectId": "website-a",
|
|
1140
|
+
"reasonSummary": "Recurring motif now promotes shared UI guidance"
|
|
960
1141
|
}`}</Code>
|
|
961
1142
|
</div>
|
|
1143
|
+
<div className="guide-data-card">
|
|
1144
|
+
<div className="guide-data-title">Topology Apply Plan</div>
|
|
1145
|
+
<Code>{`{
|
|
1146
|
+
"id": "topology_plan_abc",
|
|
1147
|
+
"candidateId": "topology_rewire_xyz",
|
|
1148
|
+
"executionMode": "apply",
|
|
1149
|
+
"safeToApply": true,
|
|
1150
|
+
"beforeSnapshotId": "topology_snapshot_001",
|
|
1151
|
+
"plannedGraphChanges": [
|
|
1152
|
+
"Suppress 1 conflict edge covered by the reviewed rewire decision"
|
|
1153
|
+
]
|
|
1154
|
+
}`}</Code>
|
|
1155
|
+
</div>
|
|
1156
|
+
</div>
|
|
1157
|
+
</Section>
|
|
1158
|
+
|
|
1159
|
+
{/* ─── Maturity & Safety ─── */}
|
|
1160
|
+
<Section id="maturity" title="Current Maturity & Safety" subtitle="What is real now, what is bounded, and what should not be overstated.">
|
|
1161
|
+
<div className="grid-3" style={{ gap: 12 }}>
|
|
1162
|
+
<div className="guide-dimension-card" style={{ borderLeftColor: 'var(--green)' }}>
|
|
1163
|
+
<div style={{ fontSize: 12, fontWeight: 700, color: 'var(--green)' }}>Operational now</div>
|
|
1164
|
+
<ul className="guide-list" style={{ marginTop: 8 }}>
|
|
1165
|
+
<li>pressure sensing and motifs</li>
|
|
1166
|
+
<li>governed routing with operator-visible rationale</li>
|
|
1167
|
+
<li>transfer evidence through generalized promotion</li>
|
|
1168
|
+
<li>persisted governance steering</li>
|
|
1169
|
+
<li>topology review queue + decisions</li>
|
|
1170
|
+
<li>prepare / apply / rollback for the safe reviewed subset</li>
|
|
1171
|
+
</ul>
|
|
1172
|
+
</div>
|
|
1173
|
+
<div className="guide-dimension-card" style={{ borderLeftColor: 'var(--yellow)' }}>
|
|
1174
|
+
<div style={{ fontSize: 12, fontWeight: 700, color: 'var(--yellow)' }}>Bounded by design</div>
|
|
1175
|
+
<ul className="guide-list" style={{ marginTop: 8 }}>
|
|
1176
|
+
<li>only accepted review candidates can enter apply planning</li>
|
|
1177
|
+
<li>only safe plans are directly applied</li>
|
|
1178
|
+
<li>snapshots and artifacts preserve execution truth</li>
|
|
1179
|
+
<li>rollback restores before-apply state instead of guessing</li>
|
|
1180
|
+
</ul>
|
|
1181
|
+
</div>
|
|
1182
|
+
<div className="guide-dimension-card" style={{ borderLeftColor: 'var(--purple)' }}>
|
|
1183
|
+
<div style={{ fontSize: 12, fontWeight: 700, color: 'var(--purple)' }}>Not yet claimed</div>
|
|
1184
|
+
<ul className="guide-list" style={{ marginTop: 8 }}>
|
|
1185
|
+
<li>full-spectrum autonomous destructive self-restructuring</li>
|
|
1186
|
+
<li>broad automatic merge / split / prune application</li>
|
|
1187
|
+
<li>broad automatic semantic remapping across historical data</li>
|
|
1188
|
+
<li>full kernel mutation or free-form ontology drift</li>
|
|
1189
|
+
<li>complete autonomous structural governance without operator oversight</li>
|
|
1190
|
+
</ul>
|
|
1191
|
+
</div>
|
|
962
1192
|
</div>
|
|
1193
|
+
<Callout type="warning">
|
|
1194
|
+
The most truthful way to describe the current product is: <strong>governed co-evolving brain with bounded safe structural execution</strong>.
|
|
1195
|
+
That is stronger and more credible than implying unrestricted autonomous self-restructuring.
|
|
1196
|
+
</Callout>
|
|
963
1197
|
</Section>
|
|
964
1198
|
|
|
965
1199
|
{/* ─── Skill Management ─── */}
|
|
@@ -1019,15 +1253,58 @@ generation: 3
|
|
|
1019
1253
|
</Callout>
|
|
1020
1254
|
</Section>
|
|
1021
1255
|
|
|
1256
|
+
{/* ─── Glossary ─── */}
|
|
1257
|
+
<Section id="glossary" title="Glossary" subtitle="Short definitions for the new core terms in the current HelixEvo brain model.">
|
|
1258
|
+
<div className="grid-2" style={{ gap: 12 }}>
|
|
1259
|
+
{[
|
|
1260
|
+
['Ontology', 'The stable semantic kernel that defines what kinds of things HelixEvo can talk about and persist truthfully.'],
|
|
1261
|
+
['Activation trace', 'Observation memory describing which skills, gaps, and contexts were active when analysis happened.'],
|
|
1262
|
+
['Pressure signal', 'An explicit representation of adaptation demand derived from failures or project gaps.'],
|
|
1263
|
+
['Motif', 'A recurring family of pressure above the single-signal level. Motifs matter because network-level transfer should respond to patterns, not isolated anecdotes.'],
|
|
1264
|
+
['Intervention', 'A recorded response action such as research, specialize, evolve, generalize, or manual review.'],
|
|
1265
|
+
['Transfer event', 'Evidence that reusable knowledge was actually promoted or transferred across projects or layers.'],
|
|
1266
|
+
['Governance mode', 'The current routing posture — derived automatically or pinned manually by the operator.'],
|
|
1267
|
+
['Topology review', 'Persisted structural candidate memory plus explicit operator decision state.'],
|
|
1268
|
+
['Apply plan', 'A prepared reviewed topology change with a before snapshot, planned graph changes, and execution mode.'],
|
|
1269
|
+
['Snapshot', 'Saved structural state used to prove what changed and to support rollback.'],
|
|
1270
|
+
['Topology artifact', 'Evidence created around reviewed structural execution, similar to how evolution artifacts preserve proposal-level change evidence.'],
|
|
1271
|
+
['Rollback', 'Restoring the before-apply structural state for a previously applied safe topology plan.'],
|
|
1272
|
+
].map(([term, desc]) => (
|
|
1273
|
+
<div key={String(term)} className="guide-dimension-card" style={{ borderLeftColor: 'var(--blue)' }}>
|
|
1274
|
+
<div style={{ fontSize: 12, fontWeight: 700, color: 'var(--blue)' }}>{term}</div>
|
|
1275
|
+
<div style={{ fontSize: 12, color: 'var(--text-dim)', marginTop: 6, lineHeight: 1.6 }}>{desc}</div>
|
|
1276
|
+
</div>
|
|
1277
|
+
))}
|
|
1278
|
+
</div>
|
|
1279
|
+
</Section>
|
|
1280
|
+
|
|
1022
1281
|
{/* ─── FAQ ─── */}
|
|
1023
|
-
<Section id="faq" title="FAQ" subtitle="Frequently asked questions.">
|
|
1024
|
-
<FAQItem q="
|
|
1025
|
-
|
|
1026
|
-
|
|
1282
|
+
<Section id="faq" title="FAQ" subtitle="Frequently asked questions for the current theory and operator model.">
|
|
1283
|
+
<FAQItem q="What is governance steering?">
|
|
1284
|
+
Governance steering lets the operator pin the current response posture instead of relying only on derived routing.
|
|
1285
|
+
In practice, that means HelixEvo can stay <code>balanced</code>, become <code>transfer-focused</code>, shift toward <code>project-critical</code>, or stay more <code>conservative</code> depending on what the operator wants and what the system is seeing.
|
|
1286
|
+
</FAQItem>
|
|
1287
|
+
<FAQItem q="What is the difference between topology review and topology execution?">
|
|
1288
|
+
<strong>Topology review</strong> is the memory and decision layer: candidates, reasons, risk, and accept/defer/reject state.
|
|
1289
|
+
<strong>Topology execution</strong> starts only after acceptance and adds prepare/apply/rollback, snapshots, artifacts, and execution records.
|
|
1027
1290
|
</FAQItem>
|
|
1028
|
-
<FAQItem q="What
|
|
1029
|
-
|
|
1030
|
-
|
|
1291
|
+
<FAQItem q="What does prepare vs apply vs rollback mean?">
|
|
1292
|
+
<code>prepare</code> creates an explicit apply plan with a before snapshot and planned graph changes.
|
|
1293
|
+
<code>apply</code> executes the safe reviewed subset against the effective graph state.
|
|
1294
|
+
<code>rollback</code> restores the before-apply snapshot if the applied structural change should be reversed.
|
|
1295
|
+
</FAQItem>
|
|
1296
|
+
<FAQItem q="What is a motif and why does it matter?">
|
|
1297
|
+
A motif is a recurring pattern of pressure across multiple signals or projects. It matters because network-level actions like <code>generalize</code> should respond to real recurring pressure families, not pretend that one local signal justifies system-wide promotion.
|
|
1298
|
+
</FAQItem>
|
|
1299
|
+
<FAQItem q="What is a transfer event?">
|
|
1300
|
+
A transfer event is evidence that reusable knowledge was actually promoted or reused across layers or projects. This is how HelixEvo distinguishes a recommendation from a realized knowledge transfer.
|
|
1301
|
+
</FAQItem>
|
|
1302
|
+
<FAQItem q="How do I prove HelixEvo's brain is working?">
|
|
1303
|
+
Use multiple proof surfaces together: <code>metrics</code> for correction reduction, Co-Evolution for routed interventions and transfer evidence, Topology for reviewed structural execution state, and the verification reports under <code>reports/verification/</code> for milestone-level backtesting.
|
|
1304
|
+
</FAQItem>
|
|
1305
|
+
<FAQItem q="How many failures do I need before evolution works?">
|
|
1306
|
+
By default, 5 unresolved failures are required (<code>minFailuresForEvolution</code>) for the standard evolution trigger.
|
|
1307
|
+
Always-on mode can also trigger earlier through burst or cross-project conditions.
|
|
1031
1308
|
</FAQItem>
|
|
1032
1309
|
<FAQItem q="What if Claude says my OAuth token expired?">
|
|
1033
1310
|
First run <code>claude auth login</code> to refresh local Claude credentials. Avoid exporting a hardcoded
|
|
@@ -1035,42 +1312,18 @@ generation: 3
|
|
|
1035
1312
|
token override when local Claude auth is healthy.
|
|
1036
1313
|
</FAQItem>
|
|
1037
1314
|
<FAQItem q="Can I use HelixEvo with other AI agents?">
|
|
1038
|
-
Yes. HelixEvo manages standard SKILL.md files with YAML frontmatter. Any agent that reads SKILL.md
|
|
1039
|
-
files can benefit from HelixEvo's evolution pipeline.
|
|
1040
|
-
</FAQItem>
|
|
1041
|
-
<FAQItem q="What happens during canary rollback?">
|
|
1042
|
-
If the failure rate for a canary skill exceeds <code>autoRollbackThreshold</code> (default: 1.5x),
|
|
1043
|
-
the skill is automatically reverted from the backup. The failed evolution is recorded in history.
|
|
1044
|
-
</FAQItem>
|
|
1045
|
-
<FAQItem q="How does cross-skill regression work?">
|
|
1046
|
-
When Skill A evolves, HelixEvo checks the skill graph for co-evolved, dependent, and enhancing
|
|
1047
|
-
partners. It tests their skill tests against Skill A's changes. If partner pass rate drops below 95%,
|
|
1048
|
-
the proposal is rejected.
|
|
1049
|
-
</FAQItem>
|
|
1050
|
-
<FAQItem q="How does the knowledge buffer work?">
|
|
1051
|
-
All research discoveries are saved, even if the resulting hypothesis fails. Failed experiments above
|
|
1052
|
-
a minimum score are saved as drafts. When the same hypothesis appears again, HelixEvo iterates on
|
|
1053
|
-
the draft rather than starting from scratch.
|
|
1054
|
-
</FAQItem>
|
|
1055
|
-
<FAQItem q="How does helixevo watch detect corrections?">
|
|
1056
|
-
Two-stage detection: (1) Fast regex pre-filter checks for correction signals in English and Chinese
|
|
1057
|
-
(e.g., "wrong", "not like that", "不对", "改成"). (2) If a signal is detected, an LLM analyzes
|
|
1058
|
-
the recent conversation window to extract structured failure records with confidence scores (>0.7 required).
|
|
1315
|
+
Yes. HelixEvo manages standard SKILL.md files with YAML frontmatter. Any agent that reads SKILL.md files can benefit from HelixEvo's evolution, pressure, transfer, and topology workflows.
|
|
1059
1316
|
</FAQItem>
|
|
1060
|
-
<FAQItem q="
|
|
1061
|
-
|
|
1062
|
-
|
|
1063
|
-
reduced corrections. This is closed-loop measurement — not LLM scores judging LLM output.
|
|
1317
|
+
<FAQItem q="What happens during canary rollback versus topology rollback?">
|
|
1318
|
+
Canary rollback restores a skill change that degraded live performance during monitored deployment.
|
|
1319
|
+
Topology rollback restores the before-apply structural state for a reviewed topology plan. They protect different layers: one protects skill behavior, the other protects graph structure.
|
|
1064
1320
|
</FAQItem>
|
|
1065
1321
|
<FAQItem q="What is network health?">
|
|
1066
|
-
Network health scores the entire skill network as a unit across
|
|
1067
|
-
|
|
1068
|
-
It runs after every evolution and is shown in the summary. Run <code>helixevo health</code> to see the full report.
|
|
1322
|
+
Network health scores the entire skill network as a unit across cohesion, coverage, balance, and transfer rate.
|
|
1323
|
+
It remains one of the best structural diagnostics because it tells you whether the network is learning in a connected and reusable way rather than just accumulating local fixes.
|
|
1069
1324
|
</FAQItem>
|
|
1070
1325
|
<FAQItem q="When does auto-generalization trigger?">
|
|
1071
|
-
|
|
1072
|
-
patterns — the same failure type appearing in 2+ projects. It creates a domain-level abstract skill,
|
|
1073
|
-
validates with regression tests, and sets up parent/child inheritance with the source project skills.
|
|
1326
|
+
It triggers when recurring multi-project patterns become strong enough to justify promotion. The newer theory frame is that <code>generalize</code> responds to recurring motifs and should create transfer evidence rather than merely appearing active.
|
|
1074
1327
|
</FAQItem>
|
|
1075
1328
|
</Section>
|
|
1076
1329
|
|
|
@@ -1079,7 +1332,7 @@ generation: 3
|
|
|
1079
1332
|
<div className="guide-footer-content">
|
|
1080
1333
|
<div style={{ fontSize: 13, fontWeight: 600 }}>HelixEvo v{VERSION}</div>
|
|
1081
1334
|
<div style={{ fontSize: 12, color: 'var(--text-dim)', marginTop: 4 }}>
|
|
1082
|
-
|
|
1335
|
+
Co-evolving brain for AI agents · MIT License
|
|
1083
1336
|
</div>
|
|
1084
1337
|
</div>
|
|
1085
1338
|
</div>
|