feat: OMEGA Dual-Layer Autonomous Swarm System v2 – CI stability + auto conflict resolution + docs refresh + atomic hardening

[Copilot]

Implements a two-layer CI hardening system: Layer 1 stabilizes workflows (deterministic caching, consistent Node versions, concurrency control); Layer 2 adds automated conflict resolution on PRs and documentation regeneration after successful compilation. A follow-up atomic stabilization pass addresses security and race conditions found during a full repository scan.

Layer 1 – Workflow Hardening

• gxq-master-ci.yml: security-scan was pinned to Node 20 while every other job used Node 24 — cache keys diverged, causing redundant full reinstalls. Normalized to Node 24 throughout.
• gxq-master-ci.yml: Added Next.js .next/cache keyed on lockfile + TS source hashes to build-webapp, avoiding full Next.js rebuilds on cache hits.

Layer 2 – Auto Conflict Resolver (omega-conflict-resolver.yml)

Triggers on every PR open/sync against main, master, develop, dev:

1. detect-conflicts — dry-run git merge --no-commit --no-ff; emits has_conflicts output
2. auto-resolve — on conflict: attempts clean three-way merge; falls back to keeping PR-branch lock-files (--ours) and base-branch resolution (--theirs) for all other files, with per-file logging; pushes resolved branch; posts PR comment summarizing resolution strategy

Layer 2 – Docs Refresh (omega-docs-refresh.yml)

Triggers on pushes to main/master touching src/, webapp/, package.json, tsconfig.json:

1. build-verify — full type-check + build (gate; docs job skipped if compilation fails)
2. docs-refresh — runs markdownlint-cli on README.md and docs/**/*.md (non-blocking); upserts an <!-- omega-refresh-stamp --> timestamp into the README CI/CD section using 0,/pattern/ sed to prevent duplicate insertions; auto-commits changes with [skip ci]

Atomic Stabilization (Phase 5 Hardening)

• omega-conflict-resolver.yml – shell injection fix: All ${{ github.head_ref }} and ${{ github.base_ref }} references in run: shell blocks now pass through env: variables ($BASE_REF, $HEAD_REF, $HEAD_SHA), eliminating the script injection attack vector present when branch names are attacker-controlled in fork PRs.
• deploy-preview.yml: Added concurrency group per github.ref (cancel-in-progress: true) to prevent duplicate preview deployments racing on rapid PR pushes; added timeout-minutes: 5 to the previously unbounded skip-preview job.
• deploy-railway.yml: Added production-safe concurrency group (cancel-in-progress: false) to queue deployments without cancelling in-flight production runs.
• deploy-vercel.yml: Added production-safe concurrency group (cancel-in-progress: false).
• docker-build.yml: Added concurrency group (cancel-in-progress: true) and timeout-minutes: 30 on build-and-push to prevent duplicate image builds and guard against hung Docker builds.

Documentation

• docs/CI_CD_GUIDE.md: updated pipeline diagram; added OMEGA workflow reference sections
• README.md: added OMEGA Docs Refresh badge; CI/CD section rewritten with OMEGA system overview table

Original prompt

OMEGA Dual-Layer Autonomous Swarm System v2 implementation for the repository SMSDAO/TradeOS to achieve enhanced CI stability with automatic conflict resolution and documentation refresh.

Objectives for Implementation

• Implement the OMEGA DUAL-LAYER SYSTEM described earlier. Includes both layers:
  1. Layer 1 – Workflow Optimization, achieving deterministic, stable, and parallel-safe CI pipelines.
  2. Layer 2 – Prompt Fix Execution, resolving compilation-based errors and refreshing README.md and docs after code changes.

Key Features of the PR:

Layer 1: Workflow Enhancements

• Pin dependencies in GitHub workflows to SHAs or strict versions.
• Implement concurrency control to manage racing workflows.
• Introduce timeout enforcement and independent job isolation.
• Caching strategies for pnpm/npm and build tools (supported caches, e.g., Next.js).
• Use Node.js LTS versions across workflows.
• Standardize environment with lockfile verification.
• Noise removal: eliminate redundant tasks and duplicate steps.

Layer 2: Code Correction and Documentation Refresh

• Automatic conflict resolution workflows on pull requests.
• Steps for detecting, isolating, and fixing compilation failures.
• Post-compilation step to regenerate and refresh documentation (README.md and docs).
• Introduce linting checks for verifying Markdown (markdownlint) integrity and auto-commit updated files when tests pass.

Process Highlight:

• Conflict-aware builds to avoid redundant re-trigger cycles.
• Documentation linked with code logic for clarity and consistencies.

Expected Outputs:

• CI Stability: Green workflows with hardened configurations.
• Code Correctness: All compilation issues resolved.
• Updated Documentation: Auto-updated and error-free README.md and docs.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Think of it as two coupled layers:
• ⚙️ Workflow Optimization Layer → makes CI stable, fast, deterministic
• 🧠 Prompt Fix Execution Layer → fixes code-level failures detected by CI

If you only do one, you either get:
• stable pipelines that still fail logically (no fix engine), or
• fixes that keep re-triggering unstable CI (no stability layer)

⸻

🧠 OMEGA DUAL-LAYER SWARM SYSTEM (CI + CODE FIX LOOP)

Here is the combined “production-grade” version you can use for your PR:

🧠 OMEGA DUAL-LAYER AUTONOMOUS SWARM SYSTEM

🎯 ROLE

You are a combined:

• ⚙️ CI/CD Workflow Optimization Engineer
• 🧠 Code Fix Execution Swarm Agent

Your mission is to achieve:

FULL SYSTEM GREEN: CI STABILITY + CODE CORRECTNESS

---

🧩 LAYER 1 — WORKFLOW OPTIMIZATION ENGINE (SYSTEM STABILITY)

OBJECTIVE

Ensure .github/workflows is:

• deterministic
• fast
• cached
• secure
• parallel-safe
• non-flaky

RULES

1. PIN EVERYTHING

• lock all GitHub Actions to SHA or strict versions

2. ENABLE CONCURRENCY CONTROL

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

3. ADD CACHING STRATEGY
	•	pnpm/npm/yarn cache
	•	build cache (Next.js / Vite / etc.)
	•	dependency store caching

4. HARDEN JOB EXECUTION
	•	timeout-minutes required
	•	isolated jobs
	•	no shared mutable artifacts unless explicit

5. STANDARDIZE ENVIRONMENT
	•	Node LTS pinned
	•	consistent OS runners
	•	lockfile enforcement

6. ELIMINATE CI NOISE
	•	remove redundant steps
	•	collapse duplicate jobs
	•	avoid re-install loops

⸻

🧠 LAYER 2 — PROMPT FIX EXECUTION ENGINE (CODE CORRECTION LOOP)

OBJECTIVE

Fix all failing builds/tests reported by CI without breaking architecture.

LOOP EXECUTION

STEP 1 — DETECT
	•	analyze CI logs
	•	identify failing test/build step
	•	classify root cause:
	•	logic bug
	•	type error
	•	missing mock
	•	async race
	•	env misconfig
	•	API mismatch

⸻

STEP 2 — ISOLATE ROOT CAUSE
	•	ignore symptoms
	•	trace dependency chain
	•	find origin file

⸻

STEP 3 — APPLY ATOMIC FIX

Rules:
	•	one fix = one intent
	•	no refactors unless required
	•	no feature additions
	•	minimal diff only

+ fix
- broken logic


⸻

STEP 4 — VALIDATE

Run mental CI simulation:
	•	install
	•	build
	•	lint
	•	test
	•	e2e

If failure persists → loop back to STEP 1

⸻

🔁 SWARM LOOP (BOTH LAYERS)

Repeat:
	1.	Optimize workflows (Layer 1)
	2.	Fix code issues (Layer 2)
	3.	Revalidate full pipeline

STOP ONLY WHEN:

✔ all workflows stable
✔ all tests passing
✔ no flaky CI behavior
✔ zero regressions

⸻

🟢 COMPLETION CRITERIA

Output only when fully resolved:

✅ OMEGA SYSTEM GREEN — STABLE CI + VERIFIED CODEBASE


⸻

🚀 MODE TAG

OMEGA_DUAL_LAYER_SWARM_v1

---

## ⚡ Why this works better than single-layer systems

Most repos fail CI because:

- CI is unstable → hides real bugs  
- code fixes are applied → but CI still flakes  
- or CI is perfect → but code logic is wrong  

This design fixes both in correct order:

> 🧱 FIRST stabilize the environment  
> 🔧 THEN fix execution errors  
> 🔁 repe...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

[github-actions]

⚠️ Railway Preview Deployment Skipped

Preview deployment was skipped because required secrets are not configured.

Required Secrets

Repository maintainers need to configure these secrets in repository settings:

• RAILWAY_TOKEN - Railway API authentication token
• RAILWAY_PROJECT_ID - Railway project ID (should be 2077acd9-f81f-47ba-b8c7-8bf6905f45fc)
• SOLANA_RPC_URL - Solana RPC endpoint URL
• WALLET_PRIVATE_KEY - Wallet private key (base58 format)
• ADMIN_USERNAME - Admin panel username
• ADMIN_PASSWORD - Admin panel password
• JWT_SECRET - JWT secret for authentication

How to Configure

1. Go to repository Settings → Secrets and variables → Actions
2. Add the required secrets
3. Re-run this workflow or push a new commit

For more information, see the Railway deployment documentation.

[SMSDAO]

@copilot 🚨 TRADEOS — MASTER ATOMIC STABILIZATION + SELF-HEALING WORKFLOW PROMPT

TARGET: #237

MODE: SAFE PRODUCTION CONVERGENCE

EXECUTION PROFILE: NO LOGIC DRIFT / NO CONSENSUS ALTERATION / NO BEHAVIORAL REGRESSION

You are an autonomous senior staff engineer swarm operating on the current repository state.

PRIMARY OBJECTIVE:
Stabilize ALL workflows, CI/CD pipelines, tests, dependency trees, generated artifacts, lint pipelines, type systems, build orchestration, and repository health WITHOUT introducing unintended logic changes.

CRITICAL RULES:
• NEVER modify business logic unless required to fix failing infrastructure/runtime issues
• NEVER alter protocol behavior
• NEVER alter consensus/security/auth flows
• NEVER rewrite architecture unless required for compilation/runtime integrity
• NEVER introduce speculative refactors
• NEVER remove working functionality
• ONLY perform deterministic stabilization
• ALL changes must be atomic, reversible, minimal, and production-safe
• If uncertain → SKIP and document
• If repository area is unstable → isolate instead of mutating
• Preserve repository intent
• Preserve public APIs unless broken
• Preserve environment compatibility

====================================================================

AUTONOMOUS EXECUTION PHASES

====================================================================

PHASE 0 — REPOSITORY INTELLIGENCE SCAN

Dynamically inspect:
• package managers
• monorepo topology
• workspace orchestration
• build graph
• CI workflows
• Docker stacks
• GitHub Actions
• lint/type/test/build pipelines
• deployment manifests
• generated code systems
• cache systems
• artifacts
• release pipelines
• hooks
• language ecosystems
• env requirements
• optional integrations
• flaky jobs
• dependency duplication
• cyclic imports
• missing lockfiles
• broken references
• stale snapshots
• invalid configs
• dead scripts
• orphan packages
• invalid path aliases
• concurrency conflicts
• incompatible node/runtime versions

Detect automatically:
• npm/yarn/pnpm/bun
• turbo/nx/lerna
• ts/js/go/rust/python hybrids
• Docker Compose/K8s
• GitHub matrix strategies
• artifact uploads
• codegen systems
• ORM generation
• protobuf/openapi generation
• firebase/supabase/web3 stacks
• ESM/CJS conflicts
• native module issues

DO NOT assume repository structure.
Infer dynamically.

====================================================================

PHASE 1 — SAFE WORKFLOW STABILIZATION

====================================================================

Analyze ALL GitHub workflows under:
.github/workflows/*

Goals:
• eliminate flaky execution
• stabilize caching
• repair dependency setup
• unify runtime versions
• remove race conditions
• harden retries
• repair artifact flow
• normalize permissions
• ensure deterministic installs
• prevent infinite recursion
• prevent duplicate triggers
• prevent deadlock jobs
• prevent partial matrix corruption

Perform safely:
• add concurrency groups where needed
• cancel stale duplicate runs
• normalize checkout depth
• repair cache keys
• repair node/pnpm/yarn setup
• repair permissions
• repair missing timeout-minutes
• repair upload/download artifacts
• repair invalid working-directory references
• repair malformed YAML
• repair invalid expressions
• repair matrix fanout failures
• repair env propagation
• repair secrets handling
• repair dependency caching
• repair lockfile mismatch handling
• repair conditional execution

DO NOT:
• weaken security
• disable tests to fake green CI
• bypass verification
• remove required jobs
• suppress failing checks dishonestly

====================================================================

PHASE 2 — SELF-HEALING REPOSITORY RECOVERY

====================================================================

Autonomously detect and recover:

IF missing files:
• regenerate safely from repository patterns
• infer nearest valid structure
• restore required configs
• restore missing exports
• restore missing barrel files
• restore missing schemas
• restore missing generated types

IF dependency corruption:
• deduplicate dependencies
• align peer versions
• repair lockfile integrity
• remove invalid transient conflicts
• repair incompatible semver ranges
• repair package manager drift

IF TypeScript instability:
• repair tsconfig inheritance
• repair path aliases
• repair module resolution
• repair build references
• repair declaration generation
• repair isolatedModules conflicts

IF runtime instability:
• repair env loading
• repair process startup
• repair import ordering
• repair ESM/CJS bridges
• repair dynamic imports
• repair missing polyfills

IF test instability:
• isolate flaky tests
• repair async timing
• repair teardown leakage
• repair mock contamination
• repair parallel execution issues
• repair snapshot corruption
• repair stale fixtures

IF generated assets missing:
• regenerate safely
• preserve deterministic output
• avoid committing unstable artifacts

====================================================================

PHASE 3 — SMART FAILURE GOVERNOR

====================================================================

Implement dynamic intelligence:

IF service/module/package is not ready:
• skip safely using conditional execution
• mark clearly as non-blocking only if appropriate
• avoid poisoning entire CI graph

IF optional integrations unavailable:
• gracefully degrade
• isolate optional jobs

IF secrets unavailable in forks:
• auto-switch to safe readonly validation mode

IF external provider flaky:
• retry with bounded exponential backoff

IF platform-specific failures:
• isolate by OS/runtime condition

IF unrecoverable instability detected:
• fail loudly with actionable diagnostics
• NEVER fake success

====================================================================

PHASE 4 — HEALTHY MERGE AUTOMATION

====================================================================

Establish SAFE automerge policy:

Automerge ONLY when:
• ALL required checks pass
• ALL tests green
• lint green
• typecheck green
• build green
• security validation passes
• no merge conflicts
• no unresolved comments
• branch up-to-date
• no flaky reruns pending

Automerge MUST:
• avoid force push corruption
• avoid recursive workflow triggers
• avoid merge queue poisoning
• avoid merging unstable branches
• avoid bypassing protections

If conflicts exist:
• dynamically rebase
• safely resolve deterministic conflicts
• preserve target branch intent
• NEVER overwrite newer logic blindly

====================================================================

PHASE 5 — CLEANUP + HARDENING

====================================================================

Perform safe repository hygiene:
• remove dead cache artifacts
• normalize line endings
• normalize executable permissions
• repair .gitignore drift
• repair Docker ignore rules
• repair editor config drift
• repair invalid npm scripts
• repair duplicate scripts
• repair invalid package exports
• repair malformed JSON/YAML
• repair broken symlinks
• repair invalid imports
• repair stale generated files
• repair CI temp leakage

Security hardening:
• prevent secret leakage
• prevent unsafe logs
• prevent token exposure
• prevent artifact poisoning
• prevent unsafe shell interpolation
• prevent unpinned dangerous actions
• prevent supply chain instability

====================================================================

PHASE 6 — VALIDATION MATRIX

====================================================================

Before completion execute dynamically:
• install
• clean install
• lint
• typecheck
• unit tests
• integration tests
• workflow dry-run validation
• production build
• Docker validation if present
• workspace validation
• dependency graph validation
• circular dependency validation
• lockfile validation

Run ONLY what repository supports.

Skip unsupported systems automatically.

====================================================================

PHASE 7 — OUTPUT REQUIREMENTS

====================================================================

Generate:
• minimal atomic commits
• deterministic diffs
• concise PR summary
• root-cause analysis
• stabilization notes
• remaining risks
• skipped areas with reasons
• rollback-safe changes

Ensure:
• zero unnecessary rewrites
• zero formatting drift
• zero architecture churn
• zero speculative optimization
• zero fake green CI

====================================================================

CRITICAL ANTI-DRIFT DIRECTIVES

====================================================================

DO NOT:
• rename large structures unnecessarily
• mass-reformat repository
• introduce opinionated patterns
• migrate frameworks
• alter app behavior
• replace libraries without necessity
• suppress failing tests dishonestly
• remove validations
• downgrade security
• bypass branch protections
• mutate production logic for CI convenience

PREFERRED STRATEGY:
stabilize > isolate > repair > regenerate > retry > validate

====================================================================

FINAL SUCCESS CONDITION

====================================================================

Repository reaches:
• stable deterministic CI
• healthy dependency graph
• reproducible builds
• resilient workflows
• conflict-safe merge state
• green required checks
• production-safe repository health

WITHOUT altering intended application behavior.

END OF DIRECTIVE.

[Copilot]

@copilot 🚨 TRADEOS — MASTER ATOMIC STABILIZATION + SELF-HEALING WORKFLOW PROMPT

TARGET: #237...

Atomic stabilization complete. Commit 50793ab addresses the highest-priority issues found during the Phase 0–5 scan:

Security (Phase 5 hardening)

• omega-conflict-resolver.yml: eliminated shell injection risk — ${{ github.head_ref }} and ${{ github.base_ref }} were interpolated directly into run: shell scripts (branch names in fork PRs are attacker-controlled). All are now passed through env: variables so they're treated as data, not code.

Concurrency / race conditions (Phase 1)

• deploy-preview.yml: added concurrency group per github.ref with cancel-in-progress: true — prevents duplicate preview deployments racing on rapid PR pushes.
• deploy-railway.yml: added concurrency with cancel-in-progress: false — queues production deployments safely without cancelling in-flight deploys.
• deploy-vercel.yml: same production-safe concurrency strategy.
• docker-build.yml: added concurrency with cancel-in-progress: true + timeout-minutes: 30 on build-and-push — prevents duplicate image builds and guards against hung Docker builds.

Timeouts (Phase 1)

• deploy-preview.yml skip-preview job: added timeout-minutes: 5 (was unbounded).

Skipped areas (stable, no mutation needed):

• Business logic / TypeScript source — no compilation failures detected
• codeql-analysis.yml, gxq-scheduled-health.yml, performance-monitoring.yml — already have concurrency or run on schedule only (adding cancel-in-progress to scheduled jobs would break them)
• powershell-merge-automation.yml — disabled by default (if: false), no risk
• auto-label.yml, sync-railway-secrets.yml — lightweight single-step jobs, low concurrency risk

[github-actions]

⏭️ Railway Preview Deployment Skipped

Preview deployment was skipped because the skip-deployment label is present.

To enable preview deployments:

1. Remove the skip-deployment label
2. Push a new commit or re-run this workflow