# Senior C#/.NET Developer Needed, Production-Grade Multi-LDPlayer Automation Control Center

## Project Description

I'm seeking an experienced C#/.NET Windows desktop developer to build a professional, production-grade automation control center for authorized account-recovery/testing workflows.

This is not a simple script project. I need a maintainable, scalable, secure Windows application with proper architecture, testing, diagnostics, persistent task management, and a professional dashboard.

The application must be capable of coordinating 1–10 LDPlayer instances, with the exact number selected dynamically from the dashboard.

## 1. Dynamic LDPlayer Selection & Startup

The dashboard must allow the operator to select the exact number of LDPlayer instances to run.

Example:
LDPlayer Instances: [ 5 ▼ ]

Supported range:
1–10

After clicking START, the application must:

1. Detect the configured LDPlayer installation.
2. Discover available emulator instances.
3. Launch only the number selected by the operator.
4. Wait until each emulator is fully ready.
5. Verify emulator health.
6. Create one dedicated worker for each active emulator.
7. Begin processing the task queue.

The application must never launch more instances than the selected limit.

The selected worker count should be configurable without changing source code.

## 2. LDPlayer Management

Use appropriate LDPlayer management mechanisms such as ldconsole.exe and ADB, where applicable.

Features:

- Auto-detect LDPlayer installation
- Manual executable-path configuration
- Discover emulator instances
- Display instance ID/name
- Start
- Stop
- Restart
- Health monitoring
- Crash detection
- Unresponsive-instance detection
- Automatic recovery
- Per-instance locking
- Prevent two workers from controlling the same instance

The software must not rely on hard-coded machine-specific paths.

## 3. TXT Task Queue

The operator will import a .txt file containing one authorized task/number per line.

Example:
Task/Number 001
Task/Number 002
Task/Number 003
Task/Number 004
Task/Number 005

Processing pipeline:

Import → Validate → Normalize → Deduplicate → Persistent Queue → Worker Assignment

The queue must maintain task order while allowing multiple workers to process different queue items concurrently.

Each task must have a unique internal ID.

The same task must never be assigned to two workers simultaneously.

Dashboard statistics:

- Total
- Valid
- Invalid
- Duplicate
- Pending
- Running
- Completed
- Failed
- Retry
- Manual Action Required

Persist all task states using SQLite.

If the application crashes or closes unexpectedly, unfinished tasks must be recoverable after restart without duplicate execution.

## 4. Multi-Worker Engine

Implement a proper bounded worker-pool architecture.

Example:

Worker 01 → LDPlayer 01
Worker 02 → LDPlayer 02
Worker 03 → LDPlayer 03
...
Worker 10 → LDPlayer 10

Requirements:

- Thread-safe queue
- Configurable concurrency
- Per-instance locking
- No duplicate task assignment
- Pause/resume
- Cancellation
- Graceful shutdown
- Worker health monitoring
- Automatic worker recovery
- Persistent worker/task state

One failed emulator or worker must never crash the entire application.

## 5. Browser-Based Workflow

Inside each assigned LDPlayer instance:

1. Wait for Android readiness.
2. Verify the configured browser exists.
3. Launch the browser.
4. Navigate to the configured authorized account-recovery workflow.
5. Retrieve the next task from the queue.
6. Enter the task data into the appropriate workflow field.
7. Continue through the normal authorized recovery process.
8. Detect the current workflow state.
9. Determine the result/state.
10. Record the result.
11. Release the worker.
12. Automatically obtain the next queued task.

The workflow must use reliable UI/state detection rather than depending primarily on fixed coordinates or arbitrary delays.

Browser path and configuration must be configurable.

## 6. Workflow Engine

Build a reusable state-machine workflow engine.

Each workflow step must support:

- UI/state detection
- Timeout
- Retry
- Cancellation
- Error handling
- Screenshot-on-failure
- Structured logging
- Recovery actions

Example:

Initialize
→ Emulator Ready
→ Browser Ready
→ Workflow Started
→ Task Entered
→ State Detected
→ Result Detected
→ Completed

Unexpected states must be handled gracefully rather than causing the entire worker to fail.

## 7. CAPTCHA

Will let you KNOW on chatbox

## 8. Professional Dashboard

Create a polished commercial-style Windows dashboard.

Main statistics:

TOTAL | RUNNING | PENDING | SUCCESS | FAILED | CAPTCHA | RETRY

Each LDPlayer card must display:

- Instance ID/name
- Worker status
- Current task
- Current workflow step
- Runtime
- CPU usage
- RAM usage
- Retry count
- Browser status
- Error state
- CAPTCHA/manual-action state

Dashboard controls:

- START
- PAUSE ALL
- RESUME ALL
- STOP ALL
- RESTART INSTANCE
- RETRY FAILED
- IMPORT TXT
- EXPORT RESULTS

Additional UI:

- Dark/light theme
- Search
- Filtering
- Sorting
- Live activity feed
- Live logs
- Charts
- Notifications
- Responsive layout
- Professional error dialogs

## 9. Error Recovery

Handle:

- LDPlayer crash
- Android boot failure
- Browser crash
- Application crash
- Unexpected UI state
- UI timeout
- Network error
- Workflow failure
- Worker exception

Recovery flow:

Detect → Diagnose → Screenshot → Log → Retry → Recover → Continue

Configurable:

- Maximum retries
- Timeout
- Retry delay
- Backoff strategy
- Screenshot-on-error

A recoverable failure must not unnecessarily terminate the entire queue.

## 10. Diagnostics

For unexpected failures optionally capture:

- Screenshot
- Task ID
- Emulator ID
- Worker ID
- Workflow step
- Error code
- Error message
- Timestamp
- Attempt number

Diagnostics must be accessible directly from the dashboard.

## 11. Database

Use:

SQLite + Entity Framework Core

Recommended entities:

- Tasks
- TaskAttempts
- EmulatorInstances
- Workers
- WorkflowRuns
- WorkflowSteps
- Errors
- Statistics
- Settings

Database requirements:

- Persistent task state
- Crash recovery
- Transaction-safe task assignment
- Duplicate protection
- Database migrations
- Backup/restore capability

Do not store passwords, OTPs, session cookies, authentication secrets, or unnecessary sensitive information in logs or database.

## 12. Performance

The application must remain responsive while managing multiple LDPlayer instances.

Requirements:

- Async architecture
- No blocking UI thread
- Bounded concurrency
- Efficient database operations
- Memory-conscious monitoring
- Proper process disposal
- CancellationToken support
- Graceful shutdown
- Resource cleanup

Target stable operation with up to 10 configured workers, subject to available PC hardware.

## 13. Mock Mode

Implement a complete offline Mock Mode.

Mock Mode must simulate:

- 10 virtual LDPlayer instances
- Task queue
- Worker allocation
- Browser states
- Workflow states
- Success
- Failure
- Timeout
- CAPTCHA/manual intervention
- Emulator crash
- Retry
- Recovery

This allows the entire system to be tested without real LDPlayer instances or real accounts.

## 14. Testing

Developer must provide:

- Unit tests
- Queue tests
- State-machine tests
- Worker-allocation tests
- Retry tests
- Database tests
- Mock integration tests
- Crash-recovery tests

Required acceptance:

Application compiles without errors and all automated tests pass.

## 15. Statistics & Export

Provide real-time statistics:

- Tasks/minute
- Average task duration
- Success rate
- Failure rate
- Retry rate
- CAPTCHA/manual-action count
- Worker utilization
- Emulator crash count
- Queue depth
- CPU/RAM usage

Export non-sensitive results to:

- CSV
- JSON

Suggested fields:

Task ID | Instance | Start Time | Finish Time | Duration | Status | Attempts | Error

## 16. Technology Stack

Must-have expertise:

- C# / .NET 8+
- WPF or WinUI 3
- MVVM
- Clean Architecture
- SQLite
- Entity Framework Core
- Dependency Injection
- Async/await
- CancellationToken
- Serilog
- Git
- Windows process management
- ADB
- LDPlayer/ldconsole.exe
- UI automation
- Automated testing

The application must be modular.

No monolithic source files.

Use SOLID principles and clear service boundaries.

## 17. Source Code Ownership

All custom source code created specifically for this project must be delivered.

Final handover must include:

- Complete Git repository
- Full source code
- Solution/project files
- Database migrations
- Unit/integration tests
- Configuration templates
- Build scripts
- Installer source
- Documentation

Do not leave critical functionality dependent on the developer's private computer or private server.

All third-party/open-source dependencies must be disclosed with their licenses.

## 18. Documentation

Developer must provide:

- Installation guide
- Build guide
- Configuration guide
- LDPlayer configuration guide
- Browser configuration guide
- Workflow configuration guide
- Troubleshooting guide
- Architecture documentation
- Dependency list
- Release instructions
- Maintenance instructions