Telegram Channel Server Day 5 Part 2: Packaging the Installed Telegram Code for Release

Thesis

Repo-local code is only production code when the distribution actually ships it and the installed artifact can still import and run the Telegram listener. Day 5 Part 2 closes that gap by proving the current src/pkgs layout survives packaging, installation, CLI startup, and documentation updates.

Angle

Frame the post around one concrete idea:

• the source layout under src/pkgs/core/channels/telegram/ must be present in the installed artifact.
• the install smoke should prove cli and pkgs.core.channels.telegram import correctly from the built tree.
• the release story is incomplete until the installed artifact passes CLI smoke.
• docs and release notes should describe the new listener without hiding the build/install reality.

Outline

1. Why the repository layout creates a packaging obligation.
2. How the build includes the Telegram implementation package under src/pkgs.
3. What the clean-install smoke proves about installed imports and entry points.
4. How the docs and release note close the support loop.
5. What remains before the Day 5 gate can be treated as complete.

Guardrails

• Do not rely on source-tree imports as the final proof.
• Do not describe packaging as a future improvement.
• Keep the release notes and docs grounded in the exact listener commands and install steps.

Draft

Part 2 is the release gate for the Telegram listener. It answers a question that every filesystem-first implementation has to answer sooner or later: can the code be installed, imported, and exercised outside the repository tree without losing the Telegram implementation package?

The answer has to be yes, and the proof has to come from the installed artifact itself.

That is why this part of the sprint is about packaging, not just code layout. The active Telegram implementation now lives under src/pkgs/core/channels/telegram/, which matches the source-package direction set by ADR 0022. That layout is cleaner than the old exception-based approach, but it still needs proof. A build can look correct in the source tree and still omit a package from the distribution. Day 5 Part 2 exists to catch that failure before anyone calls the listener shippable.

The article should explain the install smoke in practical terms. A clean install needs to show that the resulting artifact can:

• import the CLI surface,
• import pkgs.core.channels.telegram,
• run the Telegram listener commands from the installed tree,
• and preserve the listener behavior proven in Part 1.

The important detail here is what the test does not need to claim. It should not assert repo-root compatibility or any fallback around the old channels/telegram location. The packaging proof should match the current architecture: the source package under src/pkgs/core/channels/telegram/ must be present and usable in the installed distribution.

That distinction matters because release confidence is not just about whether the code exists in the repository. It is about whether the artifact that people install is the same artifact the CLI can execute. The article should make that relationship explicit:

• pyproject.toml is the packaging contract.
• the clean-install smoke is the artifact contract.
• the CLI smoke is the operational contract.
• the docs are the operator contract.

The documentation work belongs in this part because release readiness is not a build-only concern. Once the packaging proof passes, the next failure mode is confusion. Operators need to know how to start, stop, inspect, and install the listener without reading the implementation plan.

The draft should mention the concrete docs surface that closes that gap:

• README.md for the first-pass project entry point,
• docs/quickstart.md for the operator-facing runbook,
• and the Telegram release note for the release-specific summary.

Those docs should tell the same story as the smoke tests. If the docs describe a listener that can be started with the installed artifact, the tests need to prove that statement. If the tests prove the installed artifact can run the listener, the docs need to tell operators how to do it without depending on the source tree. That alignment is what makes the release supportable.

The close of the article should stay forward-looking but concrete. Day 5 is not done when the code compiles. It is done when the listener works end to end in a real run and the installed artifact still contains the Telegram implementation package. Only then does the repository move from “implemented locally” to “ready to ship.”

That is the right release message for this slice: the system is no longer just a source-tree prototype, and it is not yet a published release. It is a packaged, installable Telegram listener whose next step is operator-facing release validation.