💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

Cross-linking from our source forensic thread: Ileices/personal_IDE#20
Master promise contract (help-as-source-of-truth): Ileices/personal_IDE#17

Below is a direct problem -> fix map with deep links to specific findings in #20.

Source findings (direct anchors)

• Status contract drift: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Non-durable loop control: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Help/runtime daemon mismatch: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Community ranking/notification integrity: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Poison-record JSON crash path: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Stale/cumulative loop telemetry: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Non-transactional claim race: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Governance gate bypass defaults: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Input validation/scope drift: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Wrong text-priority ordering: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Queue not project-scoped: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Stale run metadata + swallowed error signals: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment) and Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Stop/idle status stranding: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)

Exact resolution plan

1. Unify lifecycle status contract

• Replace runtime writes (in_progress, complete, failed) with canonical enum states used by job_records.
• Add one migration-backed compatibility map for legacy rows.
• Add API contract tests for /loop/start, /loop/status, /loop/stop transitions.

2. Make claiming atomic and project-scoped

• Add project_id (or equivalent scope key) to job records and index (project_id, implementation_status, priority, created_at).
• Claim via compare-and-set update in one transaction:
  • update where implementation_status='suggested' and matching project_id
  • verify affected row count == 1
• Reject start when project resolution fails (fail closed, no cwd fallback).

3. Fix scheduler correctness and observability

• Replace lexical priority ordering with numeric severity mapping.
• Reset per-run counters on run start; maintain separate cumulative counters.
• Update last_active_at heartbeat each tick.
• Always clear or rotate current_run_id on idle/stop terminal transitions.

4. Harden loop execution against poison data

• Parse/validate atomic_steps and affected_files inside protected execution block.
• On malformed payload: mark job failed with explicit reason and continue queue.
• Persist structured failure metadata for diagnostics (no swallowed catches).

5. Restore governance guarantees promised in help

• Make approvals/checkpoint policy explicit and configurable per run.
• Default to safe mode (approval gate + checkpoint cadence) for production runs.
• Surface inner-loop caps and model provenance in UI so operator intent == runtime behavior.

6. Align docs/help with executable truth

• Keep help section as master promise but tag each promise as implemented, partial, or roadmap with evidence links.
• Continue maintaining Truth Ledger (Feature Request: Checklist button in toolbar #17) as canonical diff between claims and runtime reality.

Acceptance criteria (ship gate)

• Deterministic queue ordering by severity.
• No cross-project job execution leakage.
• No illegal status values written by loop runtime.
• Recoverable, traceable failures with persisted reasons.
• Run-state UI no longer flickers or reports contradictory states.
• Help/ledger links updated with proof for each closed gap.

[CLUSTER 1] Status Contract Drift & Non-Durable Loop Control

Source forensic thread: Ileices/personal_IDE#20
Master promise contract (Help Section): Ileices/personal_IDE#17
Help Section flag used: [USE CAUTION ??] - touches core job lifecycle. Read all files before changing.

What the problems are (direct evidence links)

Exact resolution plan

Step 1 - Align the status vocabulary [USE CAUTION ??]

Current illegal writes ? Canonical replacements
"in_progress"          ? "implementing"
"complete"             ? "implemented"
"failed"               ? "rejected"

Apply this map in apps/server/src/routes/godFactory.ts wherever status is written. Add a migration to reclassify any existing rows with illegal values.

Step 2 - Make loop state durable [NEEDS CONTEXT]

• Store { runId, startedAt, maxIterations, iterationCount, projectId, status } in a god_factory_runs table (or an existing config/session table).
• On server start: query for any run with status = 'running'. If the process died mid-run, mark it crashed and requeue implementing jobs back to suggested.
• Replace _gfLoopInstance module variable with a DB-backed run record.

Step 3 - Enforce metadata lifecycle [SAFE TO BUILD]

• On /loop/start: insert new run record, write current_run_id and last_active_at.
• Each tick: update last_active_at as a heartbeat.
• On /loop/stop or idle transition: set current_run_id = null, clear last_active_at, update run record status.

Step 4 - Add API contract tests [SAFE TO BUILD]

• Test each transition: idle ? running, running ? stopped, running ? crashed.
• Assert that no job remains in implementing state after a clean stop.
• Assert that current_run_id is null after stop.

Step 5 - Surface iteration config in UI [SAFE TO BUILD]

• Remove hardcoded maxIterations: 100 from GodFactoryRightPanel.tsx.
• Let the UI read server defaults and show model + iteration config before starting.
• Operator intent must be visible and confirmable before loop begins.

Help Section promise being tracked here

Per the Help Section as master promise rule (Discussion #17):

The God Factory is described as a continuous autonomous self-programming daemon.

A daemon that crashes silently and leaves orphaned jobs violates this promise at the most fundamental level. Status contract alignment is the prerequisite for every higher-level feature.

This comment references the full forensic teardown in discussion #20. Each finding above has an anchor link to the original analysis with exact code line citations.

[CLUSTER 1] Status Contract Drift and Non-Durable Loop Control

Source forensic thread: Ileices/personal_IDE#20
Master promise / Truth Ledger: Ileices/personal_IDE#17
Checklist flag: [USE CAUTION] - touches core job lifecycle. Read all files before changing.

Evidence (direct #20 anchors)

• O - Status enum drift: discussion #20, comment O - Loop writes in_progress, complete, failed. Schema CHECK constraint allows only suggested, sandbox_ready, implementing, implemented, rejected, archived. Every write triggers a SQLite constraint violation.
• P - Memory-only loop: discussion #20, comment P - _gfLoopInstance is a module-level variable, lost on restart. Orphaned jobs freeze in implementing with no recovery path.
• AB - Stale run metadata: discussion #20, comment AB - current_run_id and last_active_at are not cleared on stop. UI reports active run when none exists.
• AC - Iteration count mismatch: discussion #20, comment AC - UI sends maxIterations: 100 hardcoded. Server defaults to 50. Operator intent is invisible and inconsistent.
• AE - Stop strands in-flight jobs: discussion #20, comment AE - /loop/stop forces loop idle but does NOT revert implementing jobs back to suggested. Queue drains permanently.

Resolution steps

1. Align the status vocabulary - In apps/server/src/routes/godFactory.ts, replace all runtime writes: in_progress ? implementing, complete ? implemented, failed ? rejected. Add a DB migration to reclassify existing illegal-value rows.

2. Make loop state durable - Store run state in a god_factory_runs table: { runId, startedAt, projectId, status, iterationCount }. On server start: detect any run with status='running' and mark it crashed, then requeue all implementing jobs back to suggested.

3. Enforce metadata lifecycle - On start: write current_run_id + last_active_at. Each tick: update heartbeat. On stop/idle: null both fields and update the run record status.

4. Remove hardcoded UI constants - Remove maxIterations: 100 from GodFactoryRightPanel.tsx. Read and surface server defaults. Show operator intent (model, max iterations) before loop begins.

5. Add lifecycle contract tests - Assert each transition: idle ? running ? stopped/crashed. Verify no job remains in implementing after a clean stop. Verify current_run_id is null after stop.

Help Section promise being tracked

The Help Section (master promise per #17) describes The God Factory as a continuous autonomous self-programming daemon. A daemon that crashes silently, leaves orphaned jobs, and writes illegal DB values violates that promise at the foundation. Status contract alignment is the prerequisite for every feature built on top.

[CLUSTER 1] Status Contract Drift and Non-Durable Loop Control

Full forensic teardown thread: Ileices/personal_IDE#20
Master promise / Truth Ledger: Ileices/personal_IDE#17
Checklist instruction flag: USE CAUTION -- touches core job lifecycle. Read all files before changing anything.

The problem (evidence links to #20)

Resolution steps

1. Align the status vocabulary (apps/server/src/routes/godFactory.ts)
Map all runtime writes to canonical schema values:

• "in_progress" -> "implementing"
• "complete" -> "implemented"
• "failed" -> "rejected"

Add a DB migration to reclassify any existing rows with illegal values.

2. Make loop state durable (new: god_factory_runs table or equivalent)
Store { runId, startedAt, projectId, status, iterationCount, maxIterations }.
On server start: detect any run with status='running', mark it crashed, requeue all implementing jobs back to suggested.
Replace _gfLoopInstance module variable with a DB-backed run record.

3. Enforce metadata lifecycle

• On /loop/start: insert new run record, write current_run_id + last_active_at.
• Each tick: update last_active_at heartbeat.
• On /loop/stop or idle: null current_run_id, update run record to stopped.

4. Remove hardcoded UI constants (GodFactoryRightPanel.tsx)
Remove maxIterations: 100. Read and surface server defaults. Show operator config (model, max iterations, governance mode) before loop begins.

5. Add lifecycle contract tests
Test each transition: idle -> running -> stopped/crashed. Assert no job remains implementing after clean stop. Assert current_run_id is null after stop.

Help Section promise cross-reference

The Help Section (master promise per Discussion #17) describes The God Factory as a continuous autonomous self-programming daemon. A daemon that crashes silently, leaves orphaned jobs, and writes illegal DB values violates this promise at the foundation. Status contract alignment is the prerequisite for every capability built on top.

Full forensic analysis with exact line citations: Discussion #20

[CLUSTER 2] Non-Transactional Job Claiming and Cross-Project Queue Contamination

Full forensic teardown thread: Ileices/personal_IDE#20
Master promise / Truth Ledger: Ileices/personal_IDE#17
Checklist instruction flag: USE CAUTION -- modifying the claim path affects every job that flows through the loop.

The problem (evidence links to #20)

Resolution steps

1. Move JSON.parse inside the protected block (apps/server/src/routes/godFactory.ts)

Before (broken -- crashes loop on malformed record):

const steps = JSON.parse(job.atomic_steps)  // outside try/catch
try { ... execute ... } catch { ... }

After (correct):

try {
  const steps = JSON.parse(job.atomic_steps)
  // ... execute ...
} catch (err) {
  await markJobFailed(job.id, 'parse_error', err.message)
  continue  // next job -- do NOT rethrow
}

2. Implement compare-and-set claiming
Replace the two-statement SELECT + UPDATE with a single atomic UPDATE:

UPDATE job_records
  SET implementation_status = 'implementing', claimed_at = NOW()
  WHERE id = (
    SELECT id FROM job_records
    WHERE implementation_status = 'suggested'
      AND project_id = $projectId
    ORDER BY priority_rank ASC, created_at ASC
    LIMIT 1
  )
  AND implementation_status = 'suggested'
RETURNING id

If RETURNING id returns no row: another worker claimed it first -- skip and retry.

3. Add project_id to all job queries
Add project_id column to job_records. Index on (project_id, implementation_status, priority_rank, created_at).
Pass projectId through: loop start -> pickNextJob() -> claim UPDATE.
Fail-closed: if project resolution fails, refuse to start the loop. Never fall back to unscoped global queue.

4. Persist failure metadata
When any job fails (including parse errors): write structured record { job_id, error_type, error_message, iteration, timestamp }. No silent catch swallowing ever.

Help Section promise cross-reference

The Help Section (per Discussion #17) promises The God Factory can be directed at a specific project. A queue with no scope filter makes that promise impossible to keep -- the loop always risks executing someone else's work. Atomic claiming is the safety valve that makes autonomous operation trustworthy enough to leave running.

Full forensic analysis with exact line citations: Discussion #20

[CLUSTER 3] Governance Bypass, Swallowed Telemetry, and Wrong Priority Ordering

Full forensic teardown thread: Ileices/personal_IDE#20
Master promise / Truth Ledger: Ileices/personal_IDE#17
Checklist instruction flag: USE CAUTION -- governance and observability are safety properties. Defaults matter enormously.

The problem (evidence links to #20)

Resolution steps

1. Fix priority ordering (godFactory.ts pickNextJob)
Add a priority_rank INTEGER column populated via migration + trigger:

CASE priority
  WHEN 'critical' THEN 1
  WHEN 'high'     THEN 2
  WHEN 'medium'   THEN 3
  WHEN 'low'      THEN 4
  ELSE 99
END AS priority_rank

Change ORDER BY priority DESC to ORDER BY priority_rank ASC.

2. Reset per-run counters
Add run_completed and run_failed to the durable run record (Cluster 1 fix).
Keep global cumulative counters separate as historical totals.
UI shows run-scoped counters during active run. Cumulative totals are a separate summary view.

3. Make governance defaults safe
Change defaults: autoApproveChanges: false, checkpointEvery: 5 (or configurable safe default).
Only allow override via explicit operator config passed at start time.
Surface active governance mode in UI before starting -- operator intent must be visible.

4. Validate all loop start inputs
At /loop/start:

• Clamp maxIterations to [1, 500]. Reject out-of-bounds with a 400 error.
• Require modelId in request body. Validate it is in the known provider list. No silent fallback to a hardcoded model.
• Require projectId. (See Cluster 2.)

5. Persist error telemetry
Replace tick().catch(() => {}) with a structured error handler:

tick().catch(async (err) => {
  await persistLoopError({ runId, iteration, errorType: err.constructor.name, message: err.message, timestamp: Date.now() })
  // decide: retry current job? halt loop? notify operator
})

Every caught error must produce a persisted record. No silent swallowing.

Help Section promise cross-reference

Per Discussion #17: the Help Section documents that the operator controls governance and approval gates. autoApproveChanges: true as the default directly contradicts that promise. And silent error swallowing means the operator has no visibility into why jobs are failing -- defeating the entire purpose of an autonomous agent that users are supposed to be able to trust and leave running.

Full forensic analysis with exact line citations: Discussion #20

[CLUSTER 4] GitHub Integration Setup Contract vs the Documented Checklist

Full forensic teardown thread: Ileices/personal_IDE#20
Master promise / Truth Ledger: Ileices/personal_IDE#17
Checklist source: build_runs/chats/github_integration_checklist.txt -- Phases 0-9 define the full engineering roadmap

The problem (evidence links to #20)

Resolution steps (follow checklist build order: Phase 0 -> 1 -> 2 -> 3)

Phase 0 first -- Document in Help before building
Per the checklist's core rule: "The Help Section is the App's Brain. It leads. The app follows. Every feature below must be documented in Help BEFORE code is written."
Add top-level Help section "GitHub Integration and Community" with all Phase 0 subsections:

• Setting Up GitHub on Your Machine
• Reporting Problems and Sharing Wins
• The Community Feed
• Connecting Your Developer Accounts
• How the App Learns From Your Reports

Phase 1 -- Dependency detection (NEEDS CONTEXT)
On Settings > GitHub area open: run git --version, gh --version, gh auth status. Cache each result in app state so all GitHub features can read it without re-running. Show green "GitHub: Ready" badge if all pass. Show amber "Setup Required" + wizard button if any fail.

Phase 2 -- Centralized auth service (USE CAUTION)
Build a single GitHubAuthService. Token priority: (1) existing PAT with required scopes check, (2) gh auth token from system credential manager, (3) prompt for new PAT.
Required scopes: repo, discussions read+write, metadata read.
NEVER store tokens in plaintext. NEVER log tokens. Auto-redact credentials from all log output.

Phase 3 -- Full report composer contract
Implement the full checklist spec:

• Rich Markdown editor (not plain textarea)
• Auto-attach context panel (opt-in, user can uncheck any item)
• Category selector fetched dynamically from GraphQL repository.discussionCategories (not hardcoded)
• Preview tab rendering Markdown as GitHub would show it
• Confirmation dialog before any post -- this is a hard requirement from the checklist's user control rules
• Draft auto-save every 30 seconds. Users must never lose a report they were composing.

Fix draft routing immediately
Route /api/github/dev/draft to write into job_records with proper project_id and canonical status. Add migration to move any existing suggested_jobs-originated records into job_records with source='github_discussion' field.

Fix category mapping
On GitHub connection: fetch discussion categories via GraphQL repository.discussionCategories. Cache with TTL. Use cached IDs at post time. Remove all hardcoded category ID strings.

Help Section promise cross-reference

The checklist IS the specification for what the Help Section promises users about GitHub integration. Each Phase in the checklist corresponds to one or more Help subsection promises. Every gap between checklist spec and runtime implementation must be tracked in Discussion #17 as the canonical evidence diff -- this is what defines "done" for each feature.

Note from the checklist: "Nothing posts to any external service without the user explicitly clicking a Post or Submit button. No automatic posting. No background sends. Always confirm." This user control rule must be enforced everywhere in the GitHub integration surface.

Full forensic analysis with exact line citations: Discussion #20

[CLUSTER 5] Observability Gaps, Community Feed Integrity, and Control-Plane Silos

Full forensic teardown thread: Ileices/personal_IDE#20
Master promise / Truth Ledger: Ileices/personal_IDE#17
Checklist instruction flag: NEEDS CONTEXT -- feed and notification systems touch existing background task infrastructure.

The problem (evidence links to #20)

Resolution steps

1. Fix community feed ranking (NEEDS CONTEXT -- use existing background scheduler)
Implement proper paginated fetching: for TOP, accumulate reactions + comments across all pages. For TRENDING, sum activity across last 7 days across all pages. Do not rank on a partial page fetch. Cache the full ranking result with a 10-minute TTL.
Per checklist rule: do NOT create a new polling loop. Use the app's existing background task/scheduler.

2. Wire discussion resolution UI (SAFE TO BUILD)
Expose mark-answer, close, and reopen actions in the full thread view -- but only for posts created by the authenticated user. Guard every action with isOwner() check (after fixing auth fallback in Cluster 4).

3. Complete notification contract (NEEDS CONTEXT)
Poll every 15 minutes using existing background scheduler. Detect: new comments on user's threads, replies to threads user participated in, reactions on user's posts, status changes (answered/closed). Update unread badge count. Implement Mark All Read.

4. Sync My Reports status from GitHub (SAFE TO BUILD)
Background sync job (15-minute cadence alongside notification polling): for each locally stored report, fetch current status and comments.totalCount from GitHub GraphQL. Update local DB. Show unread dot if comment count increased since last view.

5. Fix reaction toggle behavior (SAFE TO BUILD)
Before calling addReaction: check if user already has that reaction. If yes: call removeReaction instead.
GraphQL mutation: removeReaction(input: { subjectId, content }).
All 8 emoji reactions (thumbsup, thumbsdown, heart, rocket, eyes, laugh, hooray, confused) must be toggleable.

6. Enforce analysis output contract (HELP SECTION ONLY for now -- per checklist Phase 8)
Every analyzer run must either: (a) produce { problem_summary, solution_description, code_patch, verified: false } or (b) write { status: 'failed_no_output', reason }. Token budget exhaustion without output is a trackable failure, not a silent completion.

7. Converge control-plane status vocabularies (USE CAUTION)
Define one canonical status enum used by ALL pipelines: God Factory, Suggested Jobs crawler, Community Hub, subsystem scheduler. Implement adapters for each pipeline that translate into/out of canonical status at the boundary. This is the architectural prerequisite for unified observability across the whole system.

Help Section promise cross-reference

Per Discussion #17: Help promises users can "browse, react, and reply to all discussions inside the app, no browser needed." Broken reaction toggles, stale My Reports status, and incomplete notification contracts directly contradict that promise. The checklist (Phases 4-5) is the engineering contract that bridges what Help documents and what the runtime actually delivers.

The checklist's global engineering rules also apply here: "Every API call has a try/catch. Every error state has a human-readable message. NEVER show a raw stack trace or raw API JSON error to the user. Network offline is a graceful state." The Community Hub must honor all of these at every touchpoint.

Full forensic analysis with exact line citations: Discussion #20

Test comment from personal_IDE agent - please ignore

[CLUSTER 6] Daemon Promise vs Request-Driven Reality, Control-Plane Fragmentation, and Compute Without Gates

Covers findings: Q | Follow-up 1 | Follow-up 2 | Follow-up 3
Checklist flags invoked: [HELP SECTION ONLY] (Phase 0 rule), [USE CAUTION 🚧] (Phase 2 centralization pattern), [ASSUMPTION ⚠️] (Phase 8 — autonomous pipeline)

This cluster addresses the deepest architectural gap in the current build: the app's Help section promises OS-daemon-level durability, but the actual runtime is request-driven panel orchestration. That single mismatch cascades into every finding below it — control-plane fragmentation, duplicate status vocabularies, and compute that generates signals but never closes the loop.

Evidence Table

Why This Matters

Help Section is the App's Brain. It leads. The app follows.

The github_integration_checklist.txt is unambiguous: "Every feature below must be documented in Help BEFORE code is written." That makes Help promises a contract — not aspirational text. When Help claims OS daemon behavior and the runtime is an in-process HTTP handler, every operator reading Help will configure their expectations around durability and autonomy that does not exist:

• Operators assume the process survives crashes → it does not (loop state is in-process memory)
• Operators assume the agent is always running → it only runs while an HTTP request is active
• Operators assume Silicon Factory is a substrate all subsystems plug into → it is a panel, not a service bus

This is not a documentation bug. It is a contract failure in the highest-priority component.

Resolution Plan

Step 1 — Correct the Help Contract First [HELP SECTION ONLY per Phase 0]

apps/web/src/help/helpRegistry.ts

Remove or retract any language claiming:

• "OS daemon" or "background service" or "always running"
• "universal substrate" implying all subsystems share a common execution bus

Replace with accurate present-tense description:

The God Factory runs as a managed session inside the app server. It is active while you are using the app. For persistent background operation, see [Deployment Guide] for process manager setup (Phase 8+).

Document the aspirational daemon behavior as a Phase 8+ Roadmap item inside Help — not as a current capability. This fulfills Phase 0 without lying.

Flag: [HELP SECTION ONLY] — do not generate daemon code yet. Document it first. Code follows.

Step 2 — Shared LifecycleStateMachine Module [USE CAUTION 🚧]

Create apps/server/src/services/lifecycle/stateMachine.ts:

export const CANONICAL_STATUS = {
  PENDING:        'pending',
  CLAIMED:        'claimed',
  IMPLEMENTING:   'implementing',
  IMPLEMENTED:    'implemented',
  REJECTED:       'rejected',
  IDLE:           'idle',
  RUNNING:        'running',
  STOPPED:        'stopped',
} as const;

export type CanonicalStatus = typeof CANONICAL_STATUS[keyof typeof CANONICAL_STATUS];

// Valid transitions — all state changes must go through this map
export const TRANSITIONS: Record<CanonicalStatus, CanonicalStatus[]> = {
  pending:        ['claimed'],
  claimed:        ['implementing', 'pending'],   // back to pending on release
  implementing:   ['implemented', 'rejected'],
  implemented:    [],
  rejected:       ['pending'],
  idle:           ['running'],
  running:        ['idle', 'stopped'],
  stopped:        ['idle'],
};

export function assertValidTransition(from: CanonicalStatus, to: CanonicalStatus): void {
  if (!TRANSITIONS[from]?.includes(to)) {
    throw new Error(`Invalid lifecycle transition: ${from} → ${to}`);
  }
}

All control planes (God Factory loop, community hub, subsystem scheduler, suggested jobs) import from this module. No local status strings anywhere.

Flag: [USE CAUTION 🚧] — read every status write site in all route files before merging. This changes constraint behavior across the entire server.

Step 3 — Convergence Pass: Eliminate Duplicate Status Vocabularies

Follow-up 2 identified multiple parallel status vocabularies:

Migration:

1. Add SQL migration: UPDATE job_records SET implementation_status = 'implementing' WHERE implementation_status = 'in_progress' etc.
2. Add CHECK constraint after migration: CHECK (implementation_status IN ('pending','claimed','implementing','implemented','rejected'))
3. Replace all string literals in routes with imports from stateMachine.ts

Run this as a single atomic migration — do not leave mixed vocabularies in the table.

Step 4 — Wire Compute Outputs as Lifecycle Gates [USE CAUTION 🚧]

Follow-up 3: subsystem runs and idle scanner produce signals but those signals are not enforced as gates.

Pattern to implement:

// Before transitioning a job to 'implemented', enforce a gate check
async function enforceImplementationGate(jobId: string): Promise<void> {
  const subsystemResult = await getLatestSubsystemRunResult(jobId);
  if (!subsystemResult || subsystemResult.status !== 'passed') {
    throw new Error(`Gate failure: subsystem run not passed for job ${jobId}. Cannot transition to implemented.`);
  }
}

Idle scanner output: if scan finds errors in files touched by a job, block the job from transitioning to implemented. Store scan result as a gate record in the DB.

This converts compute spend from noise generation into reliability enforcement — exactly what Follow-up 3 identified as the missing maturity step.

Step 5 — Daemon Execution Path (Future / Phase 8+) [HELP SECTION ONLY]

Do not build this yet. Document in Help as the roadmap:

Phase 8+: Persistent Background Operation
The God Factory can be run as a system service using a process manager (PM2 on Node.js, systemd on Linux, NSSM on Windows). When deployed this way, the agent loop survives app restarts and crashes. Loop state is persisted in the database (not in-process memory). This mode requires completing Phases 1-7 first because all status writes must be transactional and all lifecycle transitions must go through the shared FSM before daemon durability is meaningful.

Flag: [HELP SECTION ONLY] — this is roadmap documentation. Do not generate daemon scaffolding code until all status contract work (Clusters 1-5 + this cluster) is complete.

Help Section Cross-Reference

The checklist's Phase 0 rule is the master constraint for this entire cluster:

"The Help Section is the App's Brain. It leads. The app follows. Every feature below must be documented in Help BEFORE code is written."

Steps 1 and 5 above are [HELP SECTION ONLY] by this rule. Steps 2-4 are [USE CAUTION 🚧] because they touch all status write sites across all control planes. The correct build order is:

Phase 0: Correct Help daemon claims (Step 1) 
  → Step 2: stateMachine.ts module
    → Step 3: vocabulary migration
      → Step 4: gate wiring  
        → Phase 8+: actual daemon deployment (Step 5)

Do not skip phases. The checklist exists to prevent this exact class of promise/reality gap.

Original discussion: Ileices/personal_IDE#20

• Comment Q: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Follow-up 1: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Follow-up 2: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Follow-up 3: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)

[PASS 4 RECONCILIATION] Canonical Solution Index, Corrections, and Superseded Comments

Source thread: Ileices/personal_IDE#20
Truth ledger: Ileices/personal_IDE#17
Master promise contract: Help Section (apps/web/src/help/helpRegistry.ts) + Phase 0 rule in github_integration_checklist.txt: Help leads, app follows.

What This Pass Corrects

1. Confirms canonical solution set is C1-C6.
2. Marks earlier duplicate/noise comments as superseded for clarity.
3. Fixes missed backlink mapping for original Addendum K/L/M anchors in Allow PRs to "close" a discussion #20.
4. Confirms every Allow PRs to "close" a discussion #20 finding now maps to a specific solution cluster.

Canonical Solution Comments (Use These)

• C1: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
• C2: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
• C3: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
• C4: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
• C5: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
• C6: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)

Superseded / Non-Canonical Comments

• Older CLUSTER 1 drafts:

  • Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
  • Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
    These are superseded by canonical C1 (#16869601).

• Test/noise comment:

  • Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 (comment)
    Non-solution comment; ignore for implementation mapping.

Coverage Confirmation

All findings and follow-ups in Discussion #20 now have a direct backlink reply to one of C1-C6. If any future change modifies a solution contract, update #17 first, then update the affected cluster comment, then reply on the originating #20 anchor.

Checklist Enforcement

This reconciliation pass explicitly reaffirms the checklist instruction flags in build_runs/chats/github_integration_checklist.txt:

• [HELP SECTION ONLY]: Daemon/substrate claims must be corrected in Help before code claims durability.
• [USE CAUTION]: Status vocabulary migration and auth centralization are cross-cutting changes and must be contract-tested.
• [NEEDS CONTEXT]: Any route-level refactor must read existing integration points first.

This comment is the canonical index for solution-thread navigation.

Implementation proof update from this pass (real code landed, built, and validated).

What was implemented now:

• Canonical status contract enforcement in autonomous loop execution:
  • suggested -> implementing -> implemented/rejected
• Semantic priority ordering in queue selection:
  • critical > high > medium > low via explicit SQL CASE mapping
• Manual stop resilience:
  • /loop/stop restores stranded implementing jobs to suggested and reports restored_jobs count
• Help truth sync:
  • Added a new implementation note in apps/web/src/help/helpRegistry.ts linking back to source findings and cluster rationale.

Changed files:

• apps/server/src/routes/godFactory.ts
• apps/web/src/help/helpRegistry.ts

Related migration context already active from prior pass:

• apps/server/src/db/index.ts (v109 interactive session chunking, v110 loop telemetry fields)

Validation proof:

• pnpm --filter @personal-ide/server build -> pass
• pnpm --filter @personal-ide/web build -> pass
• Type diagnostics clean on touched files

Why this closes real risk:

• Prevents silent runtime status write failures against job_records CHECK constraints.
• Prevents critical jobs from being deprioritized by accidental lexicographic sorting.
• Prevents queue starvation from stranded implementing jobs after manual stop.

Cautions for anyone touching these paths:

• Do not reintroduce non-canonical status labels in route-level writes.
• Do not use ORDER BY priority DESC for severity text columns.
• If adding new priority labels, update both SQL CASE ranking and automated coverage checks in the same change.

Source anchors:

• Allow PRs to "close" a discussion #20 O: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Allow PRs to "close" a discussion #20 Y: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)
• Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 C1: https://github.com/orgs/community/discussions/195397#discussioncomment-16869601
• Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement #195397 C3: https://github.com/orgs/community/discussions/195397#discussioncomment-16869606
• Feature Request: Checklist button in toolbar #17 truth ledger: Help Section Truth Ledger — 1:1 Codebase vs Help Promises Ileices/personal_IDE#17

Additional implementation proof from this pass (runtime correction included):

After shipping the status/priority hardening, live stop-route verification surfaced a real runtime regression:

• SQLITE_ERROR: no such column: updated_at

Cause:

• job_records does not have updated_at; route writes must use timestamp.

Fix applied:

• Updated all affected job_records writes in apps/server/src/routes/godFactory.ts from updated_at to timestamp.

Post-fix verification:

• pnpm --filter @personal-ide/server build -> pass
• /api/god-factory/loop/stop live call -> {"ok":true,"message":"God Factory loop stopped","restored_jobs":1}

Why this matters:

• Confirms this pass closed not only design-contract gaps (status + priority), but also an immediate runtime SQL integrity issue discovered during true E2E execution.

Caution for similar changes:

• Schema-first SQL mutation discipline is mandatory for loop control paths.
• Keep compile + live route checks paired when touching control-plane write queries.

Implementation proof update (cluster follow-through)

Scope completed in this pass

• Closed remaining loop-start contract mismatch called out by X and AC families:
  • server validates projectId/model/maxIterations before loop start
  • model must be explicit provider/model (no silent fallback)
  • maxIterations bounded to integer 1..500
  • loop status now surfaces last run config provenance
  • UI loop panel sends selected model + bounded iterations

Code touched

• apps/server/src/routes/godFactory.ts
• apps/web/src/components/godFactory/GodFactoryRightPanel.tsx
• apps/web/src/help/helpRegistry.ts

Validation proof

• pnpm --filter @personal-ide/server build: pass
• pnpm --filter @personal-ide/web build: pass
• GET /api/god-factory/loop/status: pass, includes config fields
• POST /api/god-factory/loop/start: owner-gated in this runtime context (403 expected when not in owner session)

Caution for maintainers

• Keep control-plane starts explicit and reproducible: require model + bounded iterations at the API boundary.
• Preserve server-side guardrails even when UI enforces ranges.
• Avoid introducing hidden default model behavior in mutation paths.

Re: Cluster 1 & 2 Findings - Implemented, Tested, and Verified ?

This is a follow-up to the forensic teardown at https://github.com/orgs/community/discussions/195397#discussioncomment-16869448.

What got fixed this pass

Cluster 1 P - Memory-only loop / no crash recovery:
Every loop run now writes a durable god_factory_runs record to SQLite (migration v111). At plugin load, _recoverCrashedGfRuns() scans for any running records, marks them crashed, requeues orphaned implementing jobs to suggested, and clears stale singleton metadata - all atomically. The frozen-queue problem after a process restart is now closed.

Cluster 1 AB - Stale current_run_id / last_active_at:
All stop, idle, and completion paths now explicitly null these fields. /loop/status exposes activeRun from the persistent run record so callers see real run metadata rather than stale state.

Cluster 2 N/T - Unguarded JSON.parse crash:
pickNextJob() returns raw strings. Both atomic_steps and affected_files parses are inside try/catch inside tick(). A malformed job is marked rejected, telemetry is emitted, and the loop continues. One bad DB row can no longer halt the full queue.

Evidence

• pnpm --filter @personal-ide/server build ? zero errors
• pnpm --filter @personal-ide/web build ? zero errors, 3020 modules
• GET /api/god-factory/loop/status ? "activeRun": null, "current_run_id": null, "inProgressJobs": 0
• Help ledger (helpRegistry.ts) updated with two new entries before this code shipped
• Prior passes: status enum alignment (O), priority ordering (Y), loop-start validation (X/AC), stop job restore (AE), read-pure GET (AF), poll governance (AJ), account scoping (AK), async probe cache (AL), discussion allowlist (AM), session chunking (AH), structured telemetry (AI), owner gating (AG) - all still active

Tracking discussion: Ileices/personal_IDE#20
Help truth ledger: Ileices/personal_IDE#17

Pass 6 follow-up on Cluster 2 - real fix shipped with proof

Following up on the Cluster 2 teardown at https://github.com/orgs/community/discussions/195397#discussioncomment-16869448.

I implemented the missing V/Z reliability work instead of leaving the loop half-scoped.

What was actually wrong

The system required projectId to start a God Factory loop, but the queue still:

• stored jobs without first-class project scope
• picked the next suggested job globally
• updated it to implementing in a second statement

That meant two distinct failure modes remained:

1. TOCTOU claim race: two workers or ticks could observe the same suggested row before one wrote implementing.
2. Cross-project scope leak: a loop started for one project could claim work from another project.

What shipped

• Added DB migration v112: job_records.project_id plus project indexes.
• Added single-project legacy backfill in migration for databases with exactly one project.
• Replaced autonomous claim path with a single atomic compare-and-set SQL statement using RETURNING.
• Restricted autonomous claiming to project_id = normalizedProjectId.
• Scoped stop and recovery requeue logic to the crashed or stopped run project instead of resetting all implementing jobs globally.
• Added project_id handling to suggested-jobs reads and writes plus brainstorm-created jobs.
• Updated the God Factory panel to fetch queue slices with the active project_id.
• Updated the help ledger first, including cautions not to reintroduce the old claim pattern.

Concrete files changed

• apps/server/src/db/index.ts
• apps/server/src/routes/godFactory.ts
• apps/server/src/routes/suggestedJobs.ts
• apps/server/src/services/suggestedJobsCrawler/index.ts
• apps/web/src/components/godFactory/GodFactoryRightPanel.tsx
• apps/web/src/help/helpRegistry.ts

Proof

Build validation:

• pnpm --filter @personal-ide/server build -> pass
• pnpm --filter @personal-ide/web build -> pass

Runtime verification against the live API:

• Created scoped job id: 50f1edb1-1461-4b14-b2c8-63452e938672
• Scoped project id: 2268a693-9999-4bb0-bda6-9b21861f4712
• GET /api/suggested-jobs/jobs?status=suggested&project_id=2268a693-9999-4bb0-bda6-9b21861f4712 returned that same job as first result
• GET /api/suggested-jobs/jobs/stats?project_id=2268a693-9999-4bb0-bda6-9b21861f4712 returned active = 1

Caution for anyone changing this later

If you reintroduce global queue reads or the old SELECT LIMIT 1 then UPDATE claim flow, you will reopen both the cross-project leak and the duplicate-claim race. The queue scope, loop scope, and UI scope now need to move together.

This closes another real gap between God Factory can start a project-scoped loop and God Factory actually operates as a project-scoped autonomous programmer.

Pass 7 follow-up on Cluster 3 - governance defaults are now safe and explicit

This pass closes the remaining W-class governance gap from the teardown at https://github.com/orgs/community/discussions/195397#discussioncomment-16869448.

What was still wrong

Even after the earlier loop fixes, the actual God Factory execution config in apps/server/src/routes/godFactory.ts still hardcoded:

• autoApproveChanges: true
• autoAnswerQuestions: true
• checkpointEvery: 0

That meant the operator-control promise was still false in the real runtime path.

What shipped now

• Added migration v113 to persist governance config on god_factory_runs:
  • auto_approve_changes
  • auto_answer_questions
  • checkpoint_every
• /api/god-factory/loop/start now validates and accepts explicit governance inputs
• Safe defaults are now:
  • autoApproveChanges = false
  • autoAnswerQuestions = false
  • checkpointEvery = 5
• /api/god-factory/loop/status now exposes a config.governance block including:
  • approval mode
  • auto-answer mode
  • checkpoint cadence
  • inner-loop cap
  • derived governance mode label
• apps/web/src/components/godFactory/GodFactoryRightPanel.tsx now shows those controls and the active governance mode before execution starts
• apps/web/src/help/helpRegistry.ts was updated first and now documents both the implementation and the caution not to re-hide governance in server-only defaults

Files changed

• apps/server/src/db/index.ts
• apps/server/src/routes/godFactory.ts
• apps/web/src/components/godFactory/GodFactoryRightPanel.tsx
• apps/web/src/help/helpRegistry.ts

Proof

• pnpm --filter @personal-ide/server build -> pass
• pnpm --filter @personal-ide/web build -> pass
• live runtime smoke:
  • GET /api/god-factory/loop/status -> 200
  • returned config.governance.autoApproveChanges = false
  • returned config.governance.autoAnswerQuestions = false
  • returned config.governance.checkpointEvery = 5
  • returned config.governance.jobMaxIterations = 10
  • returned config.governance.mode = safe

Caution going forward

If anyone reintroduces hidden autoApproveChanges=true or checkpointEvery=0 defaults in an autonomous path, they will reopen the exact trust failure this cluster is about. Governance policy has to stay explicit at the API boundary, persisted with the run, and visible in the UI.

Pass 8 follow-up on the forensic teardown: active authority is now real, and help no longer overclaims daemon ownership

This pass continued from the same forensic source thread:

• cluster source: https://github.com/orgs/community/discussions/195397#discussioncomment-16869448

Implemented in the real codebase

1. Fixed a real God Factory control-plane authority flaw

File changed:

• apps/server/src/routes/godFactory.ts

What was wrong:

• the control-owner gate checked the active account first
• but then fell back to the most recent non-guest saved account
• that meant a stale saved owner row could keep privileged mutation routes open even after switching to guest or another account

What shipped:

• privileged God Factory mutation routes now authorize against the active authenticated account only
• inactive saved owner rows no longer count as current execution authority

Why that matters:

• saved credential history is not the same thing as active authority
• otherwise a guest session can inherit control-plane rights from stale stored auth state

2. Corrected the help/runtime truth contract

File changed:

• apps/web/src/help/helpRegistry.ts

What shipped:

• help now distinguishes shipped runtime vs architecture target
• shipped today:
  • backend-process loops
  • persisted run metadata
  • explicit start/stop/status routes
  • crash recovery for tracked loop state
• not yet something help should overclaim:
  • OS-level daemon/service registration
  • browser-independent service ownership
  • daemon-grade thermal governor and full queue orchestration

I updated the highest-risk misleading help surfaces, including:

• Silicon Factory daemon description
• Project Lifecycle autonomy wording
• Project Factory runtime wording
• Fleet wording
• God Factory background-state wording
• 24/7 Loops wording

3. Added executable coverage so this does not regress silently

Files changed:

• testing/e2e/godFactory.test.ts
• testing/e2e/helpers.ts

Tested behaviors:

• non-owner active account is rejected by /api/god-factory/loop/start
• governance settings persist into /api/god-factory/loop/status
• malformed job payloads do not leave the loop stranded forever; stop/recovery returns loop state to idle

Helper hardening:

• empty-body POST/PUT/DELETE test requests no longer send Content-Type: application/json without a body
• that removes false 400s from the harness itself

Proof

• pnpm --filter @personal-ide/server build -> pass
• pnpm --filter @personal-ide/web build -> pass
• started updated server separately on http://127.0.0.1:3102
• ran focused test:
  • pnpm vitest run e2e/godFactory.test.ts
  • result: 3/3 passing against the updated server

File paths touched this pass

• apps/server/src/routes/godFactory.ts
• apps/web/src/help/helpRegistry.ts
• testing/e2e/godFactory.test.ts
• testing/e2e/helpers.ts

Cautions for future changes

• never derive God Factory mutation authority from saved auth history
• only the active authenticated account should unlock owner-only routes
• persisted SQLite state and websocket status are evidence of recoverability/observability, not evidence of true daemon ownership
• do not let help or setup flows promise systemd/launchd/Windows-Service behavior until the runtime and lifecycle tests actually ship that guarantee
• if isControlOwner() changes, the e2e contract test must be updated in the same patch

Additional issue discovered while validating this pass

Fresh isolated DB startup still exposed a separate bootstrap problem:

• migration 107 fails on missing checkpoints
• startup can then reach code that expects later God Factory tables
• result: fresh DB bootstrap can die before god_factory_runs is usable

I am not claiming that bootstrap/migration-chain issue is fixed in this pass. I am flagging it because it was discovered by executable validation during this implementation pass, so it is now a verified next defect rather than a guess.

Pass 9 follow-up: fixed fresh-db migration-chain failure that could break God Factory startup

Continuing from:

• https://github.com/orgs/community/discussions/195397#discussioncomment-16869448

Implemented real fix

A clean bootstrap path could fail at migration v107 because it altered checkpoints before guaranteeing the table existed.

Shipped in code:

• apps/server/src/db/index.ts

  • v107 now checks table existence
  • creates checkpoints with type if missing
  • only runs ALTER when needed

• apps/server/src/services/checkpoint/index.ts

  • runtime table bootstrap now includes type
  • legacy table without type is normalized automatically

• apps/web/src/help/helpRegistry.ts

  • updated help truth ledger with this implemented fix and migration caution

Why this matters for "Copilot replacement" reliability

If fresh install bootstrap is non-deterministic, autonomous control-plane promises collapse before runtime starts. This fix hardens a foundational reliability layer: schema progression now stays deterministic on a blank DB so later God Factory tables/routes are reachable.

Proof from this pass

• pnpm --filter @personal-ide/server build -> pass
• pnpm --filter @personal-ide/web build -> pass
• started server against new DB build_runs/tmp/pass9-fresh.db
• migrations completed through v113
• GET /api/health -> 200
• GET /api/god-factory/loop/status -> 200 on fresh DB

Cautions

• migration code must not assume service-managed tables already exist
• one unguarded mid-chain ALTER can strand all later migrations and appear as unrelated route failures
• keep migration schema and runtime ensureTable schema converged for shared tables like checkpoints

Pass 10 follow-up: hardened GitHub discussion comment posting reliability in app control plane

Continuing from:

• https://github.com/orgs/community/discussions/195397#discussioncomment-16869448

Implemented fix

A practical reliability blocker remained: app-route comment posting could fail on transient network errors and return weak diagnostics.

Shipped:

• apps/server/src/services/github/githubService.ts

  • centralized retry+timeout network handling (fetchWithRetry) for GraphQL + REST
  • retries network exceptions and upstream 5xx
  • improves error detail surfaced to routes

• apps/server/src/routes/github.ts

  • /api/github/discussions/:id/comment now normalizes body safely to string
  • avoids payload-type trim crashes
  • returns route/discussion context in failure response

• apps/web/src/help/helpRegistry.ts

  • updated help truth ledger for this reliability hardening pass

Why this is relevant to Copilot-replacement reliability

If the system cannot reliably self-report implementation status to its own discussion control plane, governance and audit loops break. This pass strengthens that operational spine.

Proof

• pnpm --filter @personal-ide/server build -> pass
• pnpm --filter @personal-ide/web build -> pass
• live route smoke posting done on updated server

Cautions

• avoid per-route ad-hoc GitHub fetch behavior; keep retry/timeouts in one service path
• treat diagnostics as part of reliability, not optional metadata
• keep body normalization checks on mutation routes to prevent runtime type errors from malformed payloads

Pass 11 follow-up: implemented Addendum I (My Reports status fidelity) with live GitHub reconciliation

Continuation context:

• https://github.com/orgs/community/discussions/195397#discussioncomment-16869448
• C5 reference (Addendum I): https://github.com/orgs/community/discussions/195397#discussioncomment-16869608
• Source finding I: Forensic teardown: why The God Factory is failing as a full GitHub Copilot replacement Ileices/personal_IDE#20 (comment)

Shipped fix

The app no longer treats local report status as final truth.

Implemented:

• apps/server/src/routes/github.ts

  • /api/github/my-reports?sync=1 now fetches live discussion snapshots by node IDs and reconciles:
    • status (open|answered|closed)
    • comment_count
    • last_comment_at
    • discussion_url
  • /api/github/poll now also updates github_reports status metadata while processing tracked discussions

• apps/server/src/services/github/githubService.ts

  • expanded tracked discussion snapshot payload with stateReason, updatedAt, url
  • supports deterministic status derivation for report reconciliation

• apps/web/src/api/github.ts

  • sync-enabled getMyReports(syncLive)

• apps/web/src/components/CommunityHubPanel.tsx

  • My Reports tab performs live sync on open and exposes a manual "Sync Live" action
  • status badges now show open, answered, closed distinctly

Verification

• pnpm --filter @personal-ide/server build passed
• pnpm --filter @personal-ide/web build passed
• live route smoke:
  • GET /api/github/my-reports?sync=1 -> 200
  • status domain check constrained to open|answered|closed

Cautions

• Keep status derivation centralized in server reconciliation; do not duplicate drift-prone status inference in multiple UI call sites.
• Treat github_reports.status as a cached projection requiring periodic reconciliation, not as a write-once source of truth.
• Maintain account scope filters on reports/notifications/tracked state in every future query path.

pass12 - Reaction Toggle + HelpProvider Crash Fix

Build proof: web 3020 modules transformed ? | server tsc ?

Reaction toggle (Cluster 5, finding J): DiscussionThread reactions were additive-only. Centralized userHasReacted(nodes, content, authLogin) helper detects existing user reactions from reactions.nodes[*].user.login; handleReaction passes remove=true when toggling off. Server and GraphQL already correct - UI-layer-only fix. All 3 call sites updated (discussion body, comment, reply). Active reactions show bold accent + aria-pressed=true.

HelpProvider crash: HelpContext exported, HelpTip uses useContext(HelpContext) + null guard.

Files: CommunityHubPanel.tsx, HelpTip.tsx, helpContext.tsx, helpRegistry.ts

Caution: route all reaction changes through handleReaction.

Pass 13 (C5-D C5-H C6): Discussion resolution UI (mark-answer+close for discussion authors), Notifications enhancements (poll button, last-polled timestamp, click-to-navigate inline thread), LifecycleStateMachine canonical service. Both builds pass. helpRegistry gaps closed with proof. Source clusters C5+C6 https://github.com/orgs/community/discussions/195397

personal_IDE Pass 14 - C6+S+K+C4-G - Both builds green\n\nFour open gaps from the community cluster analysis closed this pass:\n\nC6 - Status constant convergence: godFactory.ts previously had inline string literals for job/run/stop_reason status values that could silently drift from the canonical stateMachine.ts definitions. Now all literals are replaced with typed imports - TypeScript catches drift at compile time.\n\nS - Community ranking integrity: The listDiscussions() call was fetching only one page (50 items) before ranking. For TOP/TRENDING modes that meant discussions beyond page 1 could never surface regardless of engagement score. Fixed with full paginated accumulation (max 1000) plus a 10-min TTL cache.\n\nK - Analysis output contract: When the God Factory autonomous loop completes a job without changing any files, a structured failed_no_output record is now written to the DB with { status, reason, iterations, totalTokensUsed }. Meets Phase 8.2 artifact tracking requirement.\n\nC4-G - Dynamic discussion categories: Category IDs were hardcoded strings that would silently misfile reports if the repo categories changed. Added getDiscussionCategories() GraphQL method (30-min cache), GET /api/github/discussion-categories endpoint with fallback, and dynamic category resolution in POST /report.\n\nBoth server and web builds pass.

Pass 14 Complete + Project State Discussion Created

Pass 14 Summary (final pass of the systematic cluster analysis):

All 14 passes completed. Verified builds pass clean on both server and web. DB schema is now at v113 with 31 migrations.

What was addressed across Passes 1-14:

• Typed status FSM (stateMachine.ts) - no more inline string literals
• Durable god_factory_runs table + crash recovery
• Atomic compare-and-set job claiming scoped by project_id
• Governance defaults: autoApproveChanges=false, autoAnswerQuestions=false, checkpointEvery=5
• Dynamic GitHub category resolution via GraphQL
• Paginated community rankings (max 1000 for TOP/TRENDING)
• Reaction toggle (additive ? proper remove)
• Live My Reports reconciliation
• Mark-answer + close-discussion (author-gated)
• Poll cooldown + single-flight lock
• Account-scoped github tables (v108)
• Discussion scope allowlist enforcement
• job_no_output telemetry
• Structured error records via recordLoopError()

New Discussion Created:
A comprehensive project state discussion has been posted at:
Ileices/personal_IDE#24

It directly answers the three user questions:

1. What can God Factory actually do NOW? (file read/write, terminal, code intelligence, build, checkpoint - but cannot consume Intel Panel reports or reason about its own source)
2. Does the agent know it's inside Personal IDE? (No - platformContext injection point exists but is never called with Personal IDE identity)
3. Is Intel Panel enterprise-grade? (Crawler YES - 5 sub-agents, allSettled, timeouts, graceful degradation. Pipeline NO - flagged_to_god_factory=1 reports are a dead end, nothing creates God Factory jobs from them)

Still Deferred (confirmed):

• Intel Panel ? God Factory job creation (highest impact remaining item)
• Personal IDE identity injection into agent system prompt
• Session chunking full wiring (AH)
• Lifecycle gates as go/no-go (C6 Step 4)
• Dev Analyze/Draft/Report composer fixes (C4-B/C/E)
• D2 Nano Sea priorities: specialization, confidence routing, nano convergence

This completes the systematic cluster analysis started in these community discussions. The remaining items are well-defined and documented in Discussion 24 comments with exact file paths and implementation guidance.