IBM/mcp-context-forge

Repo: contextforge-org/contextforge-web-ui — all file paths below are relative to that repo, not this one. Problem The Field component (src/components/ui/field.tsx) is the standard way to render a label + control + hint/error in this codebase — it handles the required asterisk, aria-invalid/aria-describedby wiring, and an optional info-popover for you. It's already used in ResourceForm, PromptForm, ToolForm, MCPServerForm, etc. A few other places still build that same label + control + error layout by hand with a plain Label (or, in one file, a local copy of Field called FieldLabel). This issue is about swapping those over to Field so the pattern is consistent everywhere it applies. What to do For each location below, replace the Label (or FieldLabel) + manual error/required markup with Field, following the pattern already used in e.g. src/components/prompts/PromptForm.tsx or src/components/gateways/CreateServerForm.tsx. src/components/servers/TestConnectionPanel.tsx — delete t

🔧 Chore Summary Add build version details below the ContextForge ASCII art printed by run-gunicorn.sh. Use these display forms: Tagged build: Version: v1.0.6 Non-tagged build: Version: v1.0.6+e38a9ce85 For a non-tagged build, the value combines the nearest reachable release tag and the short SHA of the commit being built. On a post-merge main build, that SHA identifies the merged revision. The full build SHA should remain available in build metadata even if the banner uses a short SHA. 🧱 Area Affected Choose the general area(s) that this chore affects: GitHub Actions / CI Pipelines Pre-commit hooks / linters Formatting (black, isort, ruff, etc.) Type-checking (mypy, pyright, pytype, etc.) Dependency cleanup or updates Build system or Makefile Containerization (Docker/Podman) Docs or spellcheck SBOM, CVE scans, licenses, or security checks Other: startup banner and build provenance ⚙️ Context / Rationale The current banner is emitted by run-gunicorn.sh, after P

Summary Audit of all 230 boolean settings in mcpgateway/config.py found 8 flags that no code reads — verified against settings.<name> references, direct os.getenv("UPPER_CASE") reads, dynamic getattr(settings, ...) access (all such calls use literal strings; none match), and the test suite. They are dead configuration: settable via environment, documented, but completely inert. Three observability flags are excluded from this issue and tracked separately in #5849 because active observability work is about to begin. The dead flags Flag config.py line Claimed behavior elasticsearch_enabled 2158 Send logs to Elasticsearch syslog_enabled 2161 Send logs to syslog webhook_logging_enabled 2164 Send logs to webhook endpoints oauth_discovery_enabled 966 Enable OAuth AS metadata discovery (RFC 8414) performance_tracking_enabled 1993 Enable performance tracking and metrics mcpgateway_grpc_reflection_enabled 1126 Enable gRPC server reflection by default mcpgateway_grpc_tls_ena

Description Configuration imports can fail or behave inconsistently when importing exported gateway and server configuration data back into an existing ContextForge instance. The failures are concentrated in the import flow and Admin UI import state handling. They can affect gateway UPDATE imports, exported tag shapes, masked or undecodable gateway auth values, server conflict checks, and import preview/submit actions. Reproduction Steps Export a configuration containing gateways, servers, and tagged entities. Import that configuration into an instance that already has a gateway/server with the same name. Use the UPDATE conflict strategy, or import data containing exported tag objects and masked gateway credentials. Preview or submit the import from the Admin UI. Expected Behavior UPDATE imports should update the existing gateway/server without failing create-time uniqueness checks. Exported tag data should import cleanly into create/update schemas. Masked, missing, or undecodable a

Description The project has replaced black with ruff for code formatting, but documentation still references black in several places. Files to Update Makefile Line 210: Comment mentions black in list of tools Line 227: Comment about black being invoked via uvx Line 239: Comment about black vs pylint behavior Line 3604: Help text mentions make lint-quick uses black Line 3608: Help text for black target (target removed but help remains) Line 3677: FILE_AWARE_LINTERS variable includes black Line 3680: .PHONY declaration includes black targets Line 3745-3757: lint-quick target comments and calls to black Line 3777: lint-fix target calls black Line 4081-4085: Deprecated black-check target and alias Line 4637: pre-commit target calls black pyproject.toml Line 366: Comment mentions black in tool configurations Documentation Files AGENTS.md: Mentions black in coding standards llms/testing.md, llms/mcp-server-python.md, llms/mkdocs.md, llms/plugins-llms.md, llms/mcpgateway.md: Various blac