Build 6 — Extensible Plugin Architecture (Capstone)

Scenario

You are the lead software architect building an extensible core engine. Third-party developers need to write custom plugins that transform, validate, and export data without modifying your core repository.

Requirements

1. Interface Contracts: Define plugin interfaces using typing.Protocol with runtime checkability (@runtime_checkable).
2. Dynamic Discovery: Discover and load external plugins dynamically at runtime using importlib.metadata entry-points and dynamic directory scanning.
3. Hook Execution & Lifecycle: Implement hook execution with priority weighting and fault isolation (a crashing plugin must not take down the host application).
4. Reference Implementation: Implement two contrasting plugins:
   • JsonTransformPlugin: Normalizes and sanitizes payloads.
   • WebhookExportPlugin: Sends processed events to an HTTP webhook with retries.
5. Architectural Memo: Include a 1-page ARCHITECTURE.md explaining your design decisions and lifecycle contracts.

Starter Code Layout

build-6-plugin-capstone/
├── ARCHITECTURE.md
├── pyproject.toml
├── src/
│   ├── plugin_engine/
│   │   ├── __init__.py
│   │   ├── manager.py    # Plugin registry & dynamic loader
│   │   ├── protocols.py  # typing.Protocol interfaces
│   │   └── hooks.py      # Hook dispatch & error isolation
│   └── plugins/
│       ├── json_transform.py
│       └── webhook_export.py
└── tests/
    └── test_plugin_engine.py

Verification Command

pytest tests/test_plugin_engine.py -v --cov=plugin_engine

100-Point Evaluation Rubric

• Protocol & Interface Design (30 pts): Idiomatic Python Protocol specifications; strict typing.
• Dynamic Loading & Discovery (30 pts): Clean entry-point and directory scanning via importlib.
• Fault Tolerance & Isolation (20 pts): Plugin exceptions isolated with clear logging; host remains stable.
• Documentation & Reference Plugins (20 pts): High quality ARCHITECTURE.md and complete reference plugins.

<!-- grading-rubric-v1 -->

Grading rubric

Your submission passes when all four hold:

1. Works: Two working plugins discovered via entry-points; a crashing plugin is isolated; host never requires edits for a new plugin.
2. Tested: a pytest suite covers the happy path plus one failure mode, and all tests pass.
3. Readable: a README explains setup, the two most important commands, and one design decision you made.
4. Production habits: structured logging on failures and no hardcoded secrets/paths (env or config file).

Submission contract

Submit a public repo URL containing source, tests, README, and requirements.txt (or pyproject.toml). A reviewer runs your tests and two commands from your README; if either fails on a clean machine, the submission is returned with notes.