Summary

Build a Publish Settings feature for MergeOS test mode. Admins should be able to enable a public test status and set a shared public password. When test status is enabled, contributors who know that password can open a Publish Settings page and configure test integration keys for the task they are working on, such as LLM provider keys, PayPal Sandbox credentials, and USDT test receiver settings.

These keys must be stored in the database and made available to the application runtime for test-mode flows only. This must not expose, rename, replace, or shadow existing production environment variables.

Bounty

• Reward: 5000 MRG
• Bounty type: feature bounty
• Area: publish settings, test mode, database-backed integration settings, LLM, PayPal Sandbox, USDT test receiver, security

Product Goal

MergeOS needs a safe public test-mode settings surface so bounty contributors can configure temporary integration credentials without asking maintainers to edit .env files or GitHub secrets for every test task.

The page should be public only in the sense that it does not require a normal user/admin login. It must still be protected by the shared public test password and must be completely disabled when test status is off.

Scope

Implement the full stack for database-backed test publish settings:

• Admin-controlled test status toggle.
• Admin-controlled public test password.
• Public Publish Settings page that prompts for the public test password.
• Database persistence for test integration settings.
• Array-style key storage so each integration can store multiple entries.
• Server-side validation and safe runtime resolution for test-mode settings.
• UI for listing, adding, editing, disabling, and deleting test keys.
• Clear masking of sensitive values after save.
• Audit-friendly metadata such as created time, updated time, integration type, display name, status, and last-used time if available.

Required Setting Types

At minimum, support these database-backed test setting groups:

• LLM test keys: multiple providers and models, stored as an array of key objects.
• PayPal Sandbox test credentials: multiple sandbox client/account entries, stored as an array.
• USDT test receiver settings: multiple receiver addresses or verifier settings for sandbox/test payment flows, stored as an array.

The implementation may add a generic typed settings table or typed JSON columns, but it must be validated and maintainable.

Key Naming Rules

Do not allow contributors to create database setting names that collide with existing environment variable names.

The backend must reject exact or normalized collisions with runtime ENV names and config keys already used by the app. Examples include, but are not limited to:

• GITHUB_TOKEN
• MERGEOS_GITHUB_TOKEN
• TOKEN_SYMBOL
• ADMIN_EMAIL
• ADMIN_PASSWORD
• PAYPAL_CLIENT_ID
• PAYPAL_CLIENT_SECRET
• PAYPAL_ENVIRONMENT
• CRYPTO_WEBHOOK_SECRET
• CRYPTO_TOKEN_CONTRACT
• USDT_RECEIVER_ADDRESS
• GEMINI_API_KEYS
• any existing MERGEOS_* config variable

Use scoped database setting names instead, for example:

• llm_test_keys
• paypal_sandbox_test_accounts
• usdt_test_receivers

Database-backed test settings must never overwrite production ENV values. Production ENV remains the source of truth outside test mode.

Security Requirements

• Store the public test password hashed, not plaintext.
• Do not expose saved secret values after creation; show masked previews only.
• Do not log raw secret values.
• Require the public test password for all public Publish Settings read/write actions.
• Disable all public Publish Settings access when test status is off.
• Add server-side validation for integration type, key name, required fields, and array item shape.
• Avoid leaking production ENV values through APIs, UI, logs, or error messages.
• Make test-mode usage explicit in the UI so nobody mistakes test credentials for production settings.

Expected Behavior

• Admin can enable test status and set/reset the public test password.
• When test status is disabled, the public Publish Settings page is blocked.
• When test status is enabled, a contributor with the password can access the page.
• The contributor can add multiple LLM, PayPal Sandbox, and USDT test entries.
• Saved entries persist in the database across server restarts.
• Test-mode runtime code can read the saved database entries for the relevant integration flow.
• Existing .env and production secret flows continue to work unchanged.
• Attempts to create database setting names that match ENV/config keys are rejected with a clear validation error.

Acceptance Criteria

• Add backend data model, persistence, migrations/state handling, and APIs for test publish settings.
• Add admin controls for enabling/disabling test status and setting the public password.
• Add a public password-protected Publish Settings UI.
• Support array-based settings for LLM keys, PayPal Sandbox credentials, and USDT test receiver settings.
• Store settings in the database and load them for test-mode use.
• Prevent ENV/config key-name collisions with tests covering allowed and rejected names.
• Mask secret values after save and never return raw secrets in list responses.
• Include tests for password validation, disabled test mode, CRUD behavior, array persistence, ENV-name collision rejection, and runtime resolution.
• Include responsive UI verification for desktop and mobile.
• Do not remove or weaken existing admin settings, production ENV, payment, crypto, OAuth, or CI workflow behavior.

Evidence Required

PRs must include:

• A short video or GIF showing admin enabling test mode, setting the public password, and accessing the public Publish Settings page with that password.
• Evidence of adding at least two LLM test keys, one PayPal Sandbox entry, and one USDT test receiver entry.
• Evidence that saved secrets are masked after creation.
• Evidence that disabling test status blocks public access.
• Evidence that an ENV-colliding name is rejected.
• Test/build output:
  • go test ./... from backend
  • frontend/admin test commands if frontend or admin code changes
  • frontend/admin build commands if frontend or admin code changes

Non-Goals

• Do not expose production ENV values in the UI or API.
• Do not replace production secrets with database settings.
• Do not make this page available without the public test password.
• Do not store the public test password in plaintext.
• Do not redesign unrelated admin, dashboard, payment, crypto, or LLM screens.

Claim Requirement

Before opening a PR, star this repository and claim the bounty in the Claim Token issue. Link the claim comment in the PR.