mcloh/Enterprise-MCP-Service-Bus
1
0
Fork 0
mirror of https://github.com/mcloh/Enterprise-MCP-Service-Bus.git synced 2026-11-06 06:24:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

revisão e complementação da documentação do projeto

Browse Source
This commit is contained in:
Marcos Lohmann
2026-09-14 14:01:27 -03:00
parent 2fe6d6d508
commit 9a99ec6cc8
65 changed files with 6630 additions and 1854 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
RI/src/emcp_bus/common/config.py
View File

@@ -2,7 +2,7 @@
Every declarative config type in the RI (client profiles, capability manifests,
policies, ...) is loaded through :func:`load_yaml_model`, so secrets never live
as literal values in a committed YAML file (see docs/RI-PLANNING.md, EP-00-T05):
as literal values in a committed YAML file (EP-00-T05):
a value written as ``${VAR_NAME}`` or ``${VAR_NAME:-default}`` is resolved from
the environment at load time, and a value that still looks like an unresolved
placeholder after interpolation is treated as a configuration error.

4
RI/src/emcp_bus/common/otel.py
View File

@@ -10,8 +10,8 @@ the `mcp` SDK's built-in `OpenTelemetryMiddleware` (on by default on every
`Server`/`MCPServer`): it injects/extracts standard W3C `traceparent` into the
JSON-RPC `_meta` field around every request, so a single trace_id spans both
processes without any extra instrumentation here -- this is the concrete,
checkable form of the M0 acceptance criterion in docs/RI-PLANNING.md ("um
único trace_id conecta Gateway -> Fabric -> backend mock"), verified in
checkable form of the M0 acceptance criterion ("um único trace_id conecta
Gateway -> Fabric -> backend mock"), verified in
tests/e2e/test_walking_skeleton.py.
`setup_tracing` registers one *process-global* TracerProvider via

2
RI/src/emcp_bus/identity/models.py
View File

@@ -2,7 +2,7 @@
Maps an authenticated OAuth2 client identity (the `client_id`/`azp` claim a
validated access token carries -- see EP-01-T03) to exactly one client
profile (EP-04). This indirection is what lets `docs/RI-PLANNING.md`'s §18
profile (EP-04). This indirection is what lets README.md's §18
rule ("share a client only if all sharing agents can legitimately carry the
same ceiling") be expressed as data instead of code: two client_ids pointing
at the same profile are an explicit, auditable sharing decision.

4
RI/src/emcp_bus/orchestrator/decisioning.py
View File

@@ -1,8 +1,8 @@
"""Reference `NBADecisionModel` (EP-11-T03): deterministic rules/priority
over `DecisionContext.filtered_offerings` -- not an AI model, not
clustering. See `nba_model.py`'s module docstring for the pluggable
interface a real ranking model would implement instead, and P7
(docs/RI-PLANNING.md) for why this RI doesn't attempt "real" ranking without
interface a real ranking model would implement instead, and
`RI/docs/Assumptions.md` for why this RI doesn't attempt "real" ranking without
a real dataset.
"""

4
RI/src/emcp_bus/profile_intelligence/rule_based_provider.py
View File

@@ -2,8 +2,8 @@
A deterministic, rules-over-synthetic-attributes stub -- not clustering, not
a trained model, not a proprietary taxonomy (P7: this RI does not attempt
"real" clustering without a real dataset, see docs/RI-PLANNING.md's gap
resolution). `ProfileIntelligenceProvider` is a `Protocol` so a production
"real" clustering without a real dataset, see `RI/docs/Assumptions.md`).
`ProfileIntelligenceProvider` is a `Protocol` so a production
fork can swap in a real ML-backed implementation without touching any
consumer (the Offering Filter, EP-10) -- the contract is `ProfileView` in,
`ProfileView` out.