Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/koncept-mcp-server/issues.md or /mcp/koncept-mcp-server/issues.json, or Pod over MCP.

Reported issues for koncept-mcp-server

Pod holds 8 of 8 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to koncept-mcp-server.

Most discussed

bug: internal dep range too loose (cli/mcp-server pin core ^0.2.0-alpha.0 but require alpha.2 APIs)

Severity

MEDIUM-HIGH — runtime crash for consumers who resolve an old core alongside a newer cli.

Repro (real, hit while updating a consumer)

A project depends only on `@yourtechtribe-labs/koncept-cli`. Updating just the cli (e.g. alpha.1 → alpha.3) leaves `koncept-core` resolved to an older version, because the cli declares its internal dep as:

```json "@yourtechtribe-labs/koncept-core": "workspace:^0.2.0-alpha.0" ```

published as `^0.2.0-alpha.0`. That range admits c

Read the thread · 2026-06-21 · closed · 1 comment

feat(cli): implement koncepto check — execute invariant.check payloads and report violations

Context

koncepto check is already on the ROADMAP (v0.2.x):

koncepto check — execute the kind: grep | command payloads of invariant.check and report violations. Prerequisite (structured payload) is already in place.

This issue formalizes the feature request with a real-world use case from production that demonstrates why it matters.

Real-world use case: staging-prod parity enforcement

The incide

Read the thread · 2026-05-25 · closed · 1 comment

affected --from returns a clean result when .koncept/ is not at the git root

Summary

koncepto affected --from <base> silently matches nothing whenever .koncept/ is not at the git root, and it fails in the worst direction: it returns a clean result, indistinguishable from a genuine all-clear.

Concepts name participants relative to the .koncept/ root (harness/core/catalog.py). affected --from feeds it git diff --name-only, which returns paths relative to the git root (personal/games/foundation-llm-twin/harness/core/catalog.py). In a neste

Read the thread · 2026-08-08 · closed · 0 comments

lint-naming MCP tool: bound working-tree reads to project root

Origin

Follow-up from v0.2.0-alpha.6 review (D-007, glossary-terms-and-lint-naming). The new MCP tool koncept_lint_naming reads caller-supplied file paths with readFileSync(join(rootDir, file)). Unlike prior tools that only read .koncept/ or matched participant paths, this reads arbitrary working-tree content, and a ../.. segment escapes rootDir.

Severity

LOW — trusted-input today (callers supply repo-relative paths, cf. #38), but a wider door than #38 (file reads, not just rege

Read the thread · 2026-06-28 · closed · 0 comments

security: bound RegExp evaluation in checks (ReDoS) before untrusted concept sources

Severity

LOW (today) — would escalate if concept sources stop being trusted.

Context

The static check engine (checker.ts, added in #37) compiles invariant patterns with new RegExp(pattern) and runs .test() over participant file contents (implication, symbol_present, forbidden; also the existing grep).

Today the input is the repo's own .koncept/concepts/ — authored by maintainers, version-controlled, reviewed. A catastrophic-backtracking pattern is therefore a self-i

Read the thread · 2026-06-20 · open · 0 comments

feat(verify): executable invariant checks — turn completion-contract checklists into enforced gates

Summary

Make koncepto verify evaluate invariants, not just surface them. Today verify does structural validation only (parse errors, duplicate ids, unresolved related, missing participant files) + link suggestions; it never checks an invariant. automated_check is metadata ("true if a test/CI rule already enforces this" elsewhere). So a concept's invariants are advisory — they rely on a human/agent reading them via koncept_for_file.

This proposes a new capability: an inva

Read the thread · 2026-06-20 · closed · 0 comments

feat: anchor-level concept binding + content-fingerprint drift detection

Problem

Concepts currently bind at file granularity (participants: [file, ...], source_of_truth.file). Two consequences:

  1. affected false positives: any edit to a participant file flags the concept, even when the change never touched the code the invariant actually governs. Noise erodes trust in the gate.
  2. No staleness / rot detection: when the governed code does change, nothing signals that the concept invariant (or its prose) may now be out of date. A stale concept is

Read the thread · 2026-06-07 · open · 0 comments

review: include concept description in the LLM prompt (semantic reviewer judges invariant in isolation)

Origen

Detectado en code-review post-release de la stack affected-review (v0.2.0-alpha.3, PR #27 — koncepto review, Phase 2).

Severidad

MEDIUM — afecta la calidad del juicio del reviewer semántico, que es el valor central de Phase 2.

Descripción

buildPrompt alimenta al LLM con: concept name + type, la description del invariante, y el diff de los ficheros. Pero NO incluye la description del concepto (la prosa que explica por qué existe el invariante). El revi

Read the thread · 2026-05-31 · open · outside contributor · 0 comments

Most recent

The remaining reports are on the project's issue tracker.