Skip to content
BranchesTags

Repository files navigation

svvy

svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.

The Flow

  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.

That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.

Agent Context Model

svvy uses separate agent surfaces with deliberately different context and tools:

  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.

Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.

Docs

Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.

Commands

bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts

E2E

Use the OrbStack machine lane for end-to-end tests:

bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete

inspect:app launches an isolated real dev app, prints compact browser-tools connection and semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded validated downloads, and owns the complete dev process group for deterministic cleanup. Add --stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C cleanup contract. setup:e2e pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and repairs that lane when its declared image, architecture, Bun version, or system packages drift. Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime provenance, fail on native cores even when journey assertions passed, and retain failure diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is docs/specs/testing-and-live-inspection.spec.md.

About

A strategic coding workbench for directing bounded, workflow-backed agent work.

Resources

Readme
MIT license
Activity

Stars

3 stars

Watchers

0 watching

Forks

1 fork
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
GitHub - 0xpolarzero/svvy: A strategic coding workbench for directing bounded, workflow-backed agent work. · GitHub
Skip to content
BranchesTags
Repository files navigation
svvy
svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.
The Flow
  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.
That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.
Agent Context Model
svvy uses separate agent surfaces with deliberately different context and tools:
  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.
Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.
Docs
Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.
Commands
bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts
E2E
Use the OrbStack machine lane for end-to-end tests:
bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete
inspect:app launches an isolated real dev app, prints compact browser-tools connection and
semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded
validated downloads, and owns the complete dev process group for deterministic cleanup. Add
--stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title
generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C
cleanup contract. setup:e2e
pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and
repairs that lane when its declared image, architecture, Bun version, or system packages drift.
Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback
to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official
canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI
fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime
provenance, fail on native cores even when journey assertions passed, and retain failure
diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is
docs/specs/testing-and-live-inspection.spec.md.
About
A strategic coding workbench for directing bounded, workflow-backed agent work.
Resources
Readme
MIT license
Activity
Stars
3 stars
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - 0xpolarzero/svvy: A strategic coding workbench for directing bounded, workflow-backed agent work. · GitHub
Skip to content
BranchesTags
Repository files navigation
svvy
svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.
The Flow
  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.
That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.
Agent Context Model
svvy uses separate agent surfaces with deliberately different context and tools:
  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.
Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.
Docs
Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.
Commands
bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts
E2E
Use the OrbStack machine lane for end-to-end tests:
bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete
inspect:app launches an isolated real dev app, prints compact browser-tools connection and
semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded
validated downloads, and owns the complete dev process group for deterministic cleanup. Add
--stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title
generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C
cleanup contract. setup:e2e
pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and
repairs that lane when its declared image, architecture, Bun version, or system packages drift.
Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback
to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official
canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI
fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime
provenance, fail on native cores even when journey assertions passed, and retain failure
diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is
docs/specs/testing-and-live-inspection.spec.md.
About
A strategic coding workbench for directing bounded, workflow-backed agent work.
Resources
Readme
MIT license
Activity
Stars
3 stars
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - 0xpolarzero/svvy: A strategic coding workbench for directing bounded, workflow-backed agent work. · GitHub
Skip to content
BranchesTags
Repository files navigation
svvy
svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.
The Flow
  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.
That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.
Agent Context Model
svvy uses separate agent surfaces with deliberately different context and tools:
  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.
Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.
Docs
Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.
Commands
bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts
E2E
Use the OrbStack machine lane for end-to-end tests:
bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete
inspect:app launches an isolated real dev app, prints compact browser-tools connection and
semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded
validated downloads, and owns the complete dev process group for deterministic cleanup. Add
--stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title
generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C
cleanup contract. setup:e2e
pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and
repairs that lane when its declared image, architecture, Bun version, or system packages drift.
Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback
to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official
canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI
fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime
provenance, fail on native cores even when journey assertions passed, and retain failure
diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is
docs/specs/testing-and-live-inspection.spec.md.
About
A strategic coding workbench for directing bounded, workflow-backed agent work.
Resources
Readme
MIT license
Activity
Stars
3 stars
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
GitHub - 0xpolarzero/svvy: A strategic coding workbench for directing bounded, workflow-backed agent work. · GitHub
Skip to content
BranchesTags
Repository files navigation
svvy
svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.
The Flow
  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.
That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.
Agent Context Model
svvy uses separate agent surfaces with deliberately different context and tools:
  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.
Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.
Docs
Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.
Commands
bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts
E2E
Use the OrbStack machine lane for end-to-end tests:
bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete
inspect:app launches an isolated real dev app, prints compact browser-tools connection and
semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded
validated downloads, and owns the complete dev process group for deterministic cleanup. Add
--stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title
generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C
cleanup contract. setup:e2e
pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and
repairs that lane when its declared image, architecture, Bun version, or system packages drift.
Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback
to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official
canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI
fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime
provenance, fail on native cores even when journey assertions passed, and retain failure
diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is
docs/specs/testing-and-live-inspection.spec.md.
About
A strategic coding workbench for directing bounded, workflow-backed agent work.
Resources
Readme
MIT license
Activity
Stars
3 stars
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - 0xpolarzero/svvy: A strategic coding workbench for directing bounded, workflow-backed agent work. · GitHub
Skip to content
BranchesTags
Repository files navigation
svvy
svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.
The Flow
  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.
That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.
Agent Context Model
svvy uses separate agent surfaces with deliberately different context and tools:
  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.
Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.
Docs
Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.
Commands
bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts
E2E
Use the OrbStack machine lane for end-to-end tests:
bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete
inspect:app launches an isolated real dev app, prints compact browser-tools connection and
semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded
validated downloads, and owns the complete dev process group for deterministic cleanup. Add
--stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title
generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C
cleanup contract. setup:e2e
pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and
repairs that lane when its declared image, architecture, Bun version, or system packages drift.
Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback
to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official
canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI
fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime
provenance, fail on native cores even when journey assertions passed, and retain failure
diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is
docs/specs/testing-and-live-inspection.spec.md.
About
A strategic coding workbench for directing bounded, workflow-backed agent work.
Resources
Readme
MIT license
Activity
Stars
3 stars
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - 0xpolarzero/svvy: A strategic coding workbench for directing bounded, workflow-backed agent work. · GitHub
Skip to content
BranchesTags
Repository files navigation
svvy
svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.
The Flow
  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.
That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.
Agent Context Model
svvy uses separate agent surfaces with deliberately different context and tools:
  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.
Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.
Docs
Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.
Commands
bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts
E2E
Use the OrbStack machine lane for end-to-end tests:
bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete
inspect:app launches an isolated real dev app, prints compact browser-tools connection and
semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded
validated downloads, and owns the complete dev process group for deterministic cleanup. Add
--stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title
generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C
cleanup contract. setup:e2e
pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and
repairs that lane when its declared image, architecture, Bun version, or system packages drift.
Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback
to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official
canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI
fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime
provenance, fail on native cores even when journey assertions passed, and retain failure
diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is
docs/specs/testing-and-live-inspection.spec.md.
About
A strategic coding workbench for directing bounded, workflow-backed agent work.
Resources
Readme
MIT license
Activity
Stars
3 stars
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
GitHub - 0xpolarzero/svvy: A strategic coding workbench for directing bounded, workflow-backed agent work. · GitHub
Skip to content
BranchesTags
Repository files navigation
svvy
svvy organizes coding work around orchestrator sessions that hold product intent, route implementation into bounded threads, and reconcile durable results from structured, inspectable workflows those threads supervise without bloating orchestrator context, while letting you steer at any layer.
The Flow
  1. You ask the main orchestrator to do something.
  2. The orchestrator keeps its context focused on strategy and product state, not the full implementation transcript.
  3. If the work is small, it answers directly. If it needs bounded execution, it opens a handler thread for that one objective.
  4. The handler thread picks the lightest path that fits: finish the work directly, run official Smithers CLI commands against workspace .smithers/ workflow source that imports saved Workflows assets, or author short-lived workspace .smithers/ workflow source.
  5. Verification and validation live in that path instead of being bolted on afterward, so build, test, lint, manual checks, and failed validations come back as structured outcomes.
  6. The thread can inspect results, repair inputs, rerun, pause, resume, or ask for clarification without bloating orchestrator context.
  7. When the work is ready, the thread hands the result back to the orchestrator explicitly as a bounded episode.
That keeps product-level reasoning in one place and implementation detail in the delegated surface that owns it.
Agent Context Model
svvy uses separate agent surfaces with deliberately different context and tools:
  • Orchestrator owns strategy, routing, and final user-facing decisions. It can inspect and edit the repo with Shell and Apply Patch, use execute_typescript for typed loaded-extension composition, start handler threads with thread_start({ threads: [...] }), and wait. It knows handlers can use Smithers through Shell, but it does not receive Smithers wrapper tools.
  • Handler threads own one delegated objective. They get the same repo tools plus Shell guidance for official Smithers CLI workflow work and report durable results back to the orchestrator.
  • Workflow task agents run inside a single Smithers task attempt. They receive task-local repo and artifact guidance plus execute_typescript, and they do not get orchestrator or handler controls.
  • Namer is a tiny no-tool agent that turns the first session prompt or handler objective into a short title.
Prompt context is loaded through pi's system-prompt channel from actor-specific generated instructions and generated tool/API contracts. Durable surface state is exposed through targeted tools, read models, queue items, and product-authored start context where the specs require it; it is not flattened into hidden transcript prose.
Docs
Product intent lives in docs/prd.md. The exhaustive feature inventory lives in docs/features.ts. Progress is tracked in docs/progress.md. Owning specs in docs/specs define accepted behavior; scratch notes and UI notes are inputs only until promoted into those authoritative docs.
Commands
bun install
bun run dev
bun run inspect:app -- --workspace /absolute/path/to/repository
bun run inspect:app -- --workspace /absolute/path/to/repository --stub-provider
bun run build
bun run run
bun run typecheck
bun run test# Source-checkout maintenance helper; not a shipped product workflow runtime.
bun run workflow:implement-feature -- --spec docs/specs/foo.spec.md --poc docs/pocs/foo.poc.ts
E2E
Use the OrbStack machine lane for end-to-end tests:
bun run setup:e2e
bun run test:e2e
bun run test:e2e -- e2e/svvy-smoke.test.ts
bun run test:e2e:startup-soak
bun run check:e2e-coverage
bun run check:e2e-coverage:complete
inspect:app launches an isolated real dev app, prints compact browser-tools connection and
semantic-driving commands, self-provisions missing pinned Electrobun release assets with bounded
validated downloads, and owns the complete dev process group for deterministic cleanup. Add
--stub-provider for a credential-free real prompt/stream/usage plus concurrent first-turn title
generation lifecycle; the launcher prints the exact semantic smoke commands and its Ctrl+C
cleanup contract. setup:e2e
pre-provisions the dedicated native ARM64 OrbStack machine; every test:e2e invocation verifies and
repairs that lane when its declared image, architecture, Bun version, or system packages drift.
Linux dev and stable builds use the packaged CEF renderer, and the live harness rejects a fallback
to WebKitGTK or an invalid persistent CEF profile. The app runtime currently uses Bun's official
canary channel (minimum 1.4.0) because the latest stable runtime lacks a required native-thread FFI
fix; every run records the actual revision. E2E runs retain host-visible runner logs, exact runtime
provenance, fail on native cores even when journey assertions passed, and retain failure
diagnostics under e2e-results/<runId>/. The authoritative operator, evidence, and exhaustive coverage contract is
docs/specs/testing-and-live-inspection.spec.md.
About
A strategic coding workbench for directing bounded, workflow-backed agent work.
Resources
Readme
MIT license
Activity
Stars
3 stars
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages