@xbibzlibrary/telebibz 0.1.2 → 0.1.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +17 -1
- package/CODE_OF_CONDUCT.md +37 -0
- package/CONTRIBUTING.md +54 -0
- package/CONTRIBUTION_RULES.md +41 -0
- package/GOVERNANCE.md +47 -0
- package/NOTICE.md +7 -0
- package/README.id.md +172 -0
- package/README.md +65 -33
- package/README.zh-CN.md +172 -0
- package/RELEASE_AUTOMATION.md +66 -0
- package/RELEASE_POLICY.md +2 -2
- package/SECURITY.md +36 -4
- package/SUPPORT.md +30 -0
- package/assets/readme-preview.html +75 -0
- package/assets/telebibz-readme-preview.png +0 -0
- package/dist/src/api/index.d.ts +1 -0
- package/dist/src/api/index.d.ts.map +1 -1
- package/dist/src/api/index.js +1 -0
- package/dist/src/api/index.js.map +1 -1
- package/dist/src/api/telegram-types/LICENSE +21 -0
- package/dist/src/api/telegram-types/api.d.ts +22 -0
- package/dist/src/api/telegram-types/checklist.d.ts +72 -0
- package/dist/src/api/telegram-types/inline.d.ts +692 -0
- package/dist/src/api/telegram-types/langs.d.ts +193 -0
- package/dist/src/api/telegram-types/manage.d.ts +1144 -0
- package/dist/src/api/telegram-types/markup.d.ts +268 -0
- package/dist/src/api/telegram-types/message.d.ts +1537 -0
- package/dist/src/api/telegram-types/methods.d.ts +2870 -0
- package/dist/src/api/telegram-types/mod.d.ts +14 -0
- package/dist/src/api/telegram-types/passport.d.ts +163 -0
- package/dist/src/api/telegram-types/payment.d.ts +570 -0
- package/dist/src/api/telegram-types/rich.d.ts +1010 -0
- package/dist/src/api/telegram-types/settings.d.ts +120 -0
- package/dist/src/api/telegram-types/story.d.ts +89 -0
- package/dist/src/api/telegram-types/update.d.ts +84 -0
- package/dist/src/api/telegram.d.ts +7 -0
- package/dist/src/api/telegram.d.ts.map +1 -0
- package/dist/src/api/telegram.js +2 -0
- package/dist/src/api/telegram.js.map +1 -0
- package/dist/src/approval/approval.d.ts +8 -0
- package/dist/src/approval/approval.d.ts.map +1 -1
- package/dist/src/approval/approval.js +9 -0
- package/dist/src/approval/approval.js.map +1 -1
- package/dist/src/cache/cache.d.ts +6 -5
- package/dist/src/cache/cache.d.ts.map +1 -1
- package/dist/src/cache/cache.js +7 -3
- package/dist/src/cache/cache.js.map +1 -1
- package/dist/src/context/context.d.ts.map +1 -1
- package/dist/src/context/context.js +26 -3
- package/dist/src/context/context.js.map +1 -1
- package/dist/src/core/bot.d.ts +6 -4
- package/dist/src/core/bot.d.ts.map +1 -1
- package/dist/src/core/bot.js +48 -7
- package/dist/src/core/bot.js.map +1 -1
- package/dist/src/core/events.d.ts +4 -0
- package/dist/src/core/events.d.ts.map +1 -1
- package/dist/src/core/events.js.map +1 -1
- package/dist/src/index.d.ts +1 -0
- package/dist/src/index.d.ts.map +1 -1
- package/dist/src/index.js +1 -0
- package/dist/src/index.js.map +1 -1
- package/dist/src/queue/queue.d.ts +25 -0
- package/dist/src/queue/queue.d.ts.map +1 -1
- package/dist/src/queue/queue.js +175 -51
- package/dist/src/queue/queue.js.map +1 -1
- package/dist/src/router/router.d.ts +8 -1
- package/dist/src/router/router.d.ts.map +1 -1
- package/dist/src/router/router.js +75 -17
- package/dist/src/router/router.js.map +1 -1
- package/dist/src/state/conversation.d.ts +6 -0
- package/dist/src/state/conversation.d.ts.map +1 -1
- package/dist/src/state/conversation.js +79 -11
- package/dist/src/state/conversation.js.map +1 -1
- package/dist/src/state/menu.d.ts +53 -5
- package/dist/src/state/menu.d.ts.map +1 -1
- package/dist/src/state/menu.js +116 -17
- package/dist/src/state/menu.js.map +1 -1
- package/dist/src/storage/storage.d.ts +115 -12
- package/dist/src/storage/storage.d.ts.map +1 -1
- package/dist/src/storage/storage.js +130 -4
- package/dist/src/storage/storage.js.map +1 -1
- package/dist/src/telegram-features.d.ts +33 -0
- package/dist/src/telegram-features.d.ts.map +1 -0
- package/dist/src/telegram-features.js +69 -0
- package/dist/src/telegram-features.js.map +1 -0
- package/dist/src/testing.d.ts +1 -0
- package/dist/src/testing.d.ts.map +1 -1
- package/dist/src/testing.js +16 -0
- package/dist/src/testing.js.map +1 -1
- package/dist-cjs/src/api/index.js +1 -0
- package/dist-cjs/src/api/telegram-types/LICENSE +21 -0
- package/dist-cjs/src/api/telegram-types/api.d.ts +22 -0
- package/dist-cjs/src/api/telegram-types/checklist.d.ts +72 -0
- package/dist-cjs/src/api/telegram-types/inline.d.ts +692 -0
- package/dist-cjs/src/api/telegram-types/langs.d.ts +193 -0
- package/dist-cjs/src/api/telegram-types/manage.d.ts +1144 -0
- package/dist-cjs/src/api/telegram-types/markup.d.ts +268 -0
- package/dist-cjs/src/api/telegram-types/message.d.ts +1537 -0
- package/dist-cjs/src/api/telegram-types/methods.d.ts +2870 -0
- package/dist-cjs/src/api/telegram-types/mod.d.ts +14 -0
- package/dist-cjs/src/api/telegram-types/passport.d.ts +163 -0
- package/dist-cjs/src/api/telegram-types/payment.d.ts +570 -0
- package/dist-cjs/src/api/telegram-types/rich.d.ts +1010 -0
- package/dist-cjs/src/api/telegram-types/settings.d.ts +120 -0
- package/dist-cjs/src/api/telegram-types/story.d.ts +89 -0
- package/dist-cjs/src/api/telegram-types/update.d.ts +84 -0
- package/dist-cjs/src/api/telegram.js +2 -0
- package/dist-cjs/src/approval/approval.js +11 -1
- package/dist-cjs/src/cache/cache.js +7 -3
- package/dist-cjs/src/context/context.js +26 -3
- package/dist-cjs/src/core/bot.js +48 -7
- package/dist-cjs/src/index.js +1 -0
- package/dist-cjs/src/queue/queue.js +177 -51
- package/dist-cjs/src/router/router.js +75 -17
- package/dist-cjs/src/state/conversation.js +79 -11
- package/dist-cjs/src/state/menu.js +118 -18
- package/dist-cjs/src/storage/storage.js +135 -5
- package/dist-cjs/src/telegram-features.js +74 -0
- package/dist-cjs/src/testing.js +17 -0
- package/docs/API.id.md +1800 -0
- package/docs/API.md +1799 -0
- package/docs/API.zh-CN.md +1794 -0
- package/docs/README.md +36 -17
- package/package.json +20 -3
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,21 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## Unreleased
|
|
4
|
+
|
|
5
|
+
### Fixed
|
|
6
|
+
|
|
7
|
+
- Callback-query contexts now resolve `message` and `chat` from `callback_query.message`, so `ctx.reply()`, `ctx.edit()`, and `ctx.delete()` work for button callbacks.
|
|
8
|
+
- Router matching is first-match by default; explicit `matchMode: "all"` preserves deliberate fan-out without accidental double replies.
|
|
9
|
+
- Polling isolates handler failures per update, continues the remainder of a batch, emits `update:error`, and uses abortable reconnect backoff.
|
|
10
|
+
- Regex matchers reset `lastIndex` before reuse.
|
|
11
|
+
|
|
12
|
+
### Added
|
|
13
|
+
|
|
14
|
+
- JSON-file, Redis, SQL-driver, Mongo-driver, and persistent approval storage adapters.
|
|
15
|
+
- Storage-backed conversations, full five-field cron parsing, scheduler error hooks, permission-aware menus, `MenuController`, Web App init-data validation, PaymentsClient, and vendored Telegram declarations.
|
|
16
|
+
- Callback-update test fixtures and expanded failure-path/regression coverage.
|
|
17
|
+
- Code of Conduct, Contributing Guide, Contribution Rules, Governance, Support Policy, expanded Security Policy, third-party Notice, CODEOWNERS, Dependabot configuration, and complete GitHub issue/PR templates.
|
|
18
|
+
|
|
3
19
|
## 0.1.2 — 2026-08-19
|
|
4
20
|
|
|
5
21
|
### Changed
|
|
@@ -32,4 +48,4 @@
|
|
|
32
48
|
|
|
33
49
|
### Known limitations
|
|
34
50
|
|
|
35
|
-
The
|
|
51
|
+
The generated method list has runtime coverage for official method names, while specialized request/result inference remains concentrated on the core method map; full Telegram declarations are available through `TelegramTypes`. Scene orchestration and a full Mini App UI layer remain application-owned. Redis, SQL, and Mongo adapters require the application to provide the corresponding vendor driver interface. See `FEATURE_MATRIX.md`.
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Code of Conduct
|
|
2
|
+
|
|
3
|
+
## Our pledge
|
|
4
|
+
|
|
5
|
+
We are committed to making participation in the telebibz community welcoming, respectful, technically rigorous, and safe for everyone. Contributors, maintainers, reviewers, users, and other participants are expected to act in good faith and to prioritize constructive collaboration.
|
|
6
|
+
|
|
7
|
+
## Expected behavior
|
|
8
|
+
|
|
9
|
+
Participants should communicate clearly and respectfully, assume good intent while discussing technical disagreements, provide actionable feedback, document relevant context, respect privacy and confidentiality, and accept that maintainers may make decisions based on project scope, security, compatibility, and release risk.
|
|
10
|
+
|
|
11
|
+
When reporting a defect or security issue, include reproducible technical information without publishing secrets, personal data, or exploit details that could put users at risk. When reviewing code, focus on the implementation and its consequences rather than the person who wrote it.
|
|
12
|
+
|
|
13
|
+
## Unacceptable behavior
|
|
14
|
+
|
|
15
|
+
Harassment, discrimination, threats, intimidation, personal attacks, doxxing, deliberate disruption, sexualized conduct in project spaces, impersonation, publishing private information without consent, spam, and knowingly submitting malicious or deceptive changes are not acceptable. Attempts to bypass project security controls, expose credentials, poison dependencies, or manipulate release automation are treated as serious violations.
|
|
16
|
+
|
|
17
|
+
## Scope
|
|
18
|
+
|
|
19
|
+
This Code of Conduct applies to repository issues, pull requests, discussions, reviews, commits, releases, documentation, official project channels, and any interaction where a participant is representing telebibz or its maintainers.
|
|
20
|
+
|
|
21
|
+
## Enforcement
|
|
22
|
+
|
|
23
|
+
Maintainers may remove or edit content, close discussions, restrict participation, reject contributions, revoke project permissions, or take other proportionate action. Serious or repeated violations may result in a permanent ban from project spaces. Enforcement decisions consider the severity, intent, impact, recurrence, and available evidence.
|
|
24
|
+
|
|
25
|
+
## Reporting
|
|
26
|
+
|
|
27
|
+
Report conduct concerns privately to the maintainers through the repository's private security/contact channel. Do not open a public issue for sensitive reports. Include links, dates, relevant usernames, and a concise description of what occurred. Do not include credentials or unnecessary personal information.
|
|
28
|
+
|
|
29
|
+
Security vulnerabilities must be reported according to [SECURITY.md](SECURITY.md), not through a public issue.
|
|
30
|
+
|
|
31
|
+
## Appeals
|
|
32
|
+
|
|
33
|
+
A participant may request a review of an enforcement decision by providing relevant context privately. Appeals are reviewed by a maintainer who was not the sole decision-maker for the original action where practical. Retaliation against a good-faith report or appeal is prohibited.
|
|
34
|
+
|
|
35
|
+
## Attribution
|
|
36
|
+
|
|
37
|
+
This policy is informed by the [Contributor Covenant](https://www.contributor-covenant.org/version/2/1/code_of_conduct/), adapted for the technical and security needs of this project.
|
package/CONTRIBUTING.md
ADDED
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# Contributing to telebibz
|
|
2
|
+
|
|
3
|
+
Thank you for helping improve telebibz. Contributions are welcome when they are focused, reproducible, tested, documented, and compatible with the project's security and release policies.
|
|
4
|
+
|
|
5
|
+
## Before you start
|
|
6
|
+
|
|
7
|
+
Read [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md), [CONTRIBUTION_RULES.md](CONTRIBUTION_RULES.md), [SECURITY.md](SECURITY.md), and [RELEASE_POLICY.md](RELEASE_POLICY.md). Do not open a public issue for a security vulnerability or include tokens, private chat identifiers, production payloads, or other sensitive data in an issue, pull request, test, log, screenshot, or commit.
|
|
8
|
+
|
|
9
|
+
Check existing issues and pull requests before opening a new one. For a defect, use the bug template and include a minimal reproduction. For a new capability, use the feature template and explain the public API, behavior, compatibility, and testing implications.
|
|
10
|
+
|
|
11
|
+
## Local setup
|
|
12
|
+
|
|
13
|
+
The project requires Node.js `>=20` and uses npm for release-compatible commands. Install dependencies and run the baseline checks:
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
npm ci
|
|
17
|
+
npm run typecheck
|
|
18
|
+
npm run test:types
|
|
19
|
+
npm run lint
|
|
20
|
+
npm test
|
|
21
|
+
npm run build
|
|
22
|
+
npm run security
|
|
23
|
+
npm run release:check
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
The credential-gated Telegram E2E suite is skipped unless the required test environment variables are provided. Never use production credentials in tests. Use `MockTransport`, `createTestBot()`, `createMockUpdate()`, and the integration fixtures for deterministic tests.
|
|
27
|
+
|
|
28
|
+
## Branches and commits
|
|
29
|
+
|
|
30
|
+
Create a focused branch from `main`. Keep unrelated refactors out of a feature or bug-fix pull request. Use an imperative Conventional Commit-style message, for example `fix: isolate polling handler failures` or `docs: expand storage adapter reference`. Include `[skip release]` only when a change must not trigger the GitHub-to-npm release workflow; maintainers may remove that marker when a release is appropriate.
|
|
31
|
+
|
|
32
|
+
## Implementation expectations
|
|
33
|
+
|
|
34
|
+
Public behavior must be implemented in TypeScript with strict typing. Do not add fake responses, silent stubs, undocumented breaking behavior, or untested branches. Preserve ESM and CommonJS builds, zero runtime vendor dependencies in the core package, Node.js `>=20` compatibility, and the existing package export map.
|
|
35
|
+
|
|
36
|
+
Changes to routing, context, lifecycle, transport, storage, queue, scheduler, approval, generated API declarations, or release automation require regression tests. Changes to a public function, class, method, option, error, event, or generated method require a corresponding API documentation update. Changes that affect package contents must pass `release:check` and `npm pack --dry-run`.
|
|
37
|
+
|
|
38
|
+
## Pull request process
|
|
39
|
+
|
|
40
|
+
Open a pull request against `main` and complete the pull request template. Explain the problem, solution, compatibility impact, test evidence, documentation changes, and security implications. Keep the diff reviewable. Maintainers may request changes, split a pull request, or ask for a follow-up issue when scope is too broad.
|
|
41
|
+
|
|
42
|
+
Every pull request must pass the CI workflow. A maintainer reviews API compatibility, error handling, tests, documentation, package contents, and release impact before approval. Do not merge while required checks are failing or unresolved security concerns remain.
|
|
43
|
+
|
|
44
|
+
## Documentation and translations
|
|
45
|
+
|
|
46
|
+
English is the default README language. Keep `README.id.md`, `README.zh-CN.md`, `docs/API.id.md`, and `docs/API.zh-CN.md` synchronized when public behavior changes. Code signatures, method names, package names, environment variables, and command names must remain exact in every translation.
|
|
47
|
+
|
|
48
|
+
## Release process
|
|
49
|
+
|
|
50
|
+
Normal pushes to `main` can trigger the protected auto-publish workflow. The workflow runs quality gates, computes an unused patch version, publishes the package, commits the version, creates a tag, and creates a GitHub Release. See [RELEASE_AUTOMATION.md](RELEASE_AUTOMATION.md) for the required `NPM_TOKEN` secret and private-source provenance constraint. Contributors must not publish directly to npm unless explicitly authorized by the maintainers.
|
|
51
|
+
|
|
52
|
+
## Questions
|
|
53
|
+
|
|
54
|
+
Use the question/support template for usage questions and consult the [English API reference](docs/API.md) first. Keep support requests free of credentials and private user data.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Contribution Rules
|
|
2
|
+
|
|
3
|
+
These rules are the operational requirements for contributions to telebibz. They complement [CONTRIBUTING.md](CONTRIBUTING.md) and [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
|
|
4
|
+
|
|
5
|
+
## Scope and ownership
|
|
6
|
+
|
|
7
|
+
A contribution must have a clear owner, a stated problem, and a bounded outcome. Large changes should be split into reviewable pull requests. Maintainers may reject work that is technically correct but outside the package scope, duplicates an existing design, introduces unnecessary dependencies, or creates disproportionate maintenance cost.
|
|
8
|
+
|
|
9
|
+
## API and compatibility rules
|
|
10
|
+
|
|
11
|
+
Public exports, constructor options, method signatures, event names, error classes, generated method names, package entrypoints, and persisted data formats are compatibility-sensitive. A breaking change requires an explicit migration note, a versioning decision, updated type-level tests, and maintainer approval.
|
|
12
|
+
|
|
13
|
+
New public APIs must have strict TypeScript types, runtime validation where input can be unsafe, deterministic error behavior, examples, and API reference documentation. Avoid `any` in public signatures. When a Telegram type is not specialized in the core method map, use the vendored `TelegramTypes` declarations or an honest generic boundary rather than inventing an inaccurate shape.
|
|
14
|
+
|
|
15
|
+
## Runtime and error-handling rules
|
|
16
|
+
|
|
17
|
+
Network operations must honor timeout and cancellation behavior. Retry logic must be bounded and must not retry authentication or validation failures blindly. Update handlers must not terminate polling because one update failed. Background tasks must surface errors through documented hooks or events and must not create unhandled promise rejections.
|
|
18
|
+
|
|
19
|
+
Callback-query handling must work for both message-backed and inline callbacks. Router behavior must state whether first-match or all-match is used. Nested middleware must not execute terminal handlers twice. Persistent state must use the `Storage` abstraction and must document consistency, TTL, and driver assumptions.
|
|
20
|
+
|
|
21
|
+
## Testing rules
|
|
22
|
+
|
|
23
|
+
A pull request must add or update tests for every changed behavior. Use unit tests for pure logic, integration tests for module boundaries, type-level tests for public signatures, and credential-gated E2E tests only for real Telegram behavior that cannot be represented safely by mocks. Tests must be deterministic and must clean up timers, temporary files, listeners, and network resources.
|
|
24
|
+
|
|
25
|
+
A bug fix is incomplete without a regression test that fails against the old behavior. A feature is incomplete without tests for success, invalid input, cancellation, retry/failure, and boundary behavior where applicable.
|
|
26
|
+
|
|
27
|
+
## Documentation rules
|
|
28
|
+
|
|
29
|
+
Documentation must describe the implementation that exists in source, not a planned feature. Every documented limitation must remain accurate. English is canonical; Indonesian and Simplified Chinese translations must preserve signatures, code blocks, URLs, environment variables, and command names exactly.
|
|
30
|
+
|
|
31
|
+
## Dependency and security rules
|
|
32
|
+
|
|
33
|
+
Do not add a runtime dependency without a written justification, license review, bundle/package impact analysis, and maintainer approval. Never commit credentials, private keys, Telegram tokens, npm tokens, test secrets, or real user data. Security-sensitive changes require review of [SECURITY.md](SECURITY.md) and must not be disclosed publicly before a fix or coordinated disclosure decision.
|
|
34
|
+
|
|
35
|
+
## Release and repository rules
|
|
36
|
+
|
|
37
|
+
Do not edit or overwrite an already published npm version. Do not manually create a release tag that conflicts with the protected workflow. Do not bypass required checks, disable security audit, weaken release checks, or modify workflow permissions without maintainer approval. Use `[skip release]` only for changes that must not publish a package.
|
|
38
|
+
|
|
39
|
+
## Review standards
|
|
40
|
+
|
|
41
|
+
Reviewers should verify correctness, compatibility, tests, documentation, security, package contents, and operational behavior. Approval is not a guarantee that no defect exists; it confirms that the change meets the current project acceptance criteria and is safe to merge based on the available evidence.
|
package/GOVERNANCE.md
ADDED
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Governance
|
|
2
|
+
|
|
3
|
+
## Project purpose
|
|
4
|
+
|
|
5
|
+
telebibz is a TypeScript Telegram Bot Framework. Governance exists to preserve a stable public API, honest feature scope, secure release automation, and a respectful contributor community.
|
|
6
|
+
|
|
7
|
+
## Roles
|
|
8
|
+
|
|
9
|
+
| Role | Responsibility |
|
|
10
|
+
|---|---|
|
|
11
|
+
| Users | Report reproducible defects, explain use cases, and provide feedback without publishing secrets. |
|
|
12
|
+
| Contributors | Submit focused code, tests, documentation, and issue reports that follow the project rules. |
|
|
13
|
+
| Reviewers | Examine correctness, compatibility, security, tests, documentation, and operational risk. |
|
|
14
|
+
| Maintainers | Set project direction, review and merge changes, manage releases, triage issues, and protect the repository. |
|
|
15
|
+
| Release maintainers | Control npm credentials, GitHub Actions environments, version tags, npm publication, and release verification. |
|
|
16
|
+
|
|
17
|
+
One person may hold multiple roles, but security-sensitive actions should use separation of duties whenever practical.
|
|
18
|
+
|
|
19
|
+
## Decision-making
|
|
20
|
+
|
|
21
|
+
Routine decisions are made by maintainers through pull request review and documented issue discussion. Decisions should be based on user benefit, implementation quality, compatibility, security, maintenance cost, and evidence from tests or production reports.
|
|
22
|
+
|
|
23
|
+
For controversial or breaking changes, maintainers should document alternatives, migration impact, and the reason for the selected approach. A maintainer may request a design note before implementation. Silence is not approval for a breaking change.
|
|
24
|
+
|
|
25
|
+
## Triage
|
|
26
|
+
|
|
27
|
+
New issues are initially classified as bug, feature, documentation, security, support, or duplicate. Maintainers may request a reproduction, reduce sensitive details, split scope, mark a report as blocked, or close it when the requested behavior conflicts with the documented project contract.
|
|
28
|
+
|
|
29
|
+
Security reports are handled privately according to [SECURITY.md](SECURITY.md). Public issues must not contain exploit instructions, credentials, or personal data.
|
|
30
|
+
|
|
31
|
+
## Pull requests
|
|
32
|
+
|
|
33
|
+
A pull request requires a passing CI workflow and at least one maintainer review. Changes affecting authentication, transport, update dispatch, persistence, release automation, package exports, or security policy may require additional review. Maintainers can require a regression test, API documentation, migration note, or threat-model explanation before merge.
|
|
34
|
+
|
|
35
|
+
## Releases
|
|
36
|
+
|
|
37
|
+
The protected GitHub Actions workflow is the canonical release path. It runs quality gates, computes a new immutable npm version, publishes the package, creates a version commit and tag, and creates a GitHub Release. Direct npm publication is restricted to authorized release maintainers. Release credentials must remain in GitHub or npm secret storage and must be rotated after exposure.
|
|
38
|
+
|
|
39
|
+
Because the source repository is private, the workflow uses npm publish without provenance. If the repository becomes public and provenance is enabled, the policy and workflow must be reviewed together before the next release.
|
|
40
|
+
|
|
41
|
+
## Repository protection
|
|
42
|
+
|
|
43
|
+
Required CI checks, branch protection, environment approvals, workflow permissions, package scope, and immutable release rules must not be weakened casually. Any change to these controls requires a pull request, a written rationale, and maintainer approval.
|
|
44
|
+
|
|
45
|
+
## Amendments
|
|
46
|
+
|
|
47
|
+
Governance changes are proposed through a pull request that explains the current problem, proposed rule, affected roles, and migration plan. The updated governance document becomes effective when the pull request merges.
|
package/NOTICE.md
ADDED
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Third-party notices
|
|
2
|
+
|
|
3
|
+
## Vendored Telegram declarations
|
|
4
|
+
|
|
5
|
+
The declaration files under `src/api/telegram-types/` and the corresponding published `dist` paths are derived from [`@grammyjs/types`](https://www.npmjs.com/package/@grammyjs/types), version `4.0.0`, released under the MIT License.
|
|
6
|
+
|
|
7
|
+
The original license text is preserved at `src/api/telegram-types/LICENSE`. These files are type-only declarations used to expose Telegram Bot API object, union, enum, and method types. They do not add a runtime dependency to telebibz.
|
package/README.id.md
ADDED
|
@@ -0,0 +1,172 @@
|
|
|
1
|
+
# telebibz
|
|
2
|
+
|
|
3
|
+

|
|
4
|
+
|
|
5
|
+
**`@xbibzlibrary/telebibz`** adalah SDK dan framework Telegram Bot untuk Node.js dan TypeScript. Paket ini menyediakan API client, polling, router, middleware, context, keyboard builder, state/session, webhook handler, queue, scheduler, cache, plugin lifecycle, CLI, dan utilitas pengujian.
|
|
6
|
+
|
|
7
|
+
[English](README.md) · **Bahasa Indonesia** · [简体中文](README.zh-CN.md)
|
|
8
|
+
|
|
9
|
+
Referensi API lengkap: [English](docs/API.md) · **Indonesia** · [中文](docs/API.zh-CN.md)
|
|
10
|
+
|
|
11
|
+

|
|
12
|
+
|
|
13
|
+
## Instalasi
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
npm install @xbibzlibrary/telebibz
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
Node.js **20 atau lebih baru** diperlukan.
|
|
20
|
+
|
|
21
|
+
## Bot sederhana
|
|
22
|
+
|
|
23
|
+
```ts
|
|
24
|
+
import { Bot } from "@xbibzlibrary/telebibz";
|
|
25
|
+
|
|
26
|
+
const bot = new Bot(process.env.TELEGRAM_BOT_TOKEN!);
|
|
27
|
+
|
|
28
|
+
bot.command("start", (ctx) => ctx.reply("Bot aktif."));
|
|
29
|
+
bot.onText("ping", (ctx) => ctx.reply("pong"));
|
|
30
|
+
|
|
31
|
+
await bot.start();
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
`Bot.start()` menjalankan long polling. Untuk siklus hidup manual, gunakan `init()`, `launch({ mode: "polling" })`, `health()`, `stop()`, atau `restart()`.
|
|
35
|
+
|
|
36
|
+
## Router dan middleware
|
|
37
|
+
|
|
38
|
+
```ts
|
|
39
|
+
bot.use(async (ctx, next) => {
|
|
40
|
+
const started = Date.now();
|
|
41
|
+
await next();
|
|
42
|
+
console.log(`processed in ${Date.now() - started}ms`);
|
|
43
|
+
});
|
|
44
|
+
|
|
45
|
+
bot.command("help", (ctx) => ctx.reply("Bantuan tersedia."));
|
|
46
|
+
bot.onRegex(/^order:(\\d+)$/, (ctx) => ctx.reply("Order diterima."));
|
|
47
|
+
bot.callback("profile:", (ctx) => ctx.answerCallbackQuery("Dibuka."));
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
Router mendukung command, text, regex, pola callback, predikat kustom, router bersarang, middleware per rute, dan prioritas rute.
|
|
51
|
+
|
|
52
|
+
## Telegram API
|
|
53
|
+
|
|
54
|
+
Generated method access dan raw access tersedia melalui API client:
|
|
55
|
+
|
|
56
|
+
```ts
|
|
57
|
+
await bot.api.methods.getMe();
|
|
58
|
+
await bot.api.methods.sendMessage({ chat_id: 123456789, text: "Halo." });
|
|
59
|
+
await bot.api.call("sendMessage", { chat_id: 123456789, text: "Halo." });
|
|
60
|
+
await bot.api.raw("futureTelegramMethod", { value: true });
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Transport bawaan menggunakan `fetch`, timeout, retry, exponential backoff, JSON payload, dan multipart upload.
|
|
64
|
+
|
|
65
|
+
Referensi API lengkap untuk setiap class, function, method, type, error, lifecycle, CLI command, dan generated Telegram method tersedia di [`docs/API.id.md`](docs/API.id.md).
|
|
66
|
+
|
|
67
|
+
## Keyboard
|
|
68
|
+
|
|
69
|
+
```ts
|
|
70
|
+
import { InlineKeyboard } from "@xbibzlibrary/telebibz";
|
|
71
|
+
|
|
72
|
+
const keyboard = new InlineKeyboard()
|
|
73
|
+
.text("Profil", "profile")
|
|
74
|
+
.url("Dokumentasi", "https://core.telegram.org/bots/api")
|
|
75
|
+
.build();
|
|
76
|
+
|
|
77
|
+
await ctx.reply("Pilih menu:", { reply_markup: keyboard });
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Builder hanya menghasilkan payload keyboard native Telegram. UI HTML/CSS memerlukan Mini App atau Web App terpisah.
|
|
81
|
+
|
|
82
|
+
## Persetujuan pemilik
|
|
83
|
+
|
|
84
|
+
Gerbang persetujuan menahan pembaruan biasa sampai pemilik menyetujui bot melalui tombol **Izinkan** atau **Tidak Diizinkan**.
|
|
85
|
+
|
|
86
|
+
```ts
|
|
87
|
+
const bot = new Bot({
|
|
88
|
+
token: process.env.TELEGRAM_BOT_TOKEN!,
|
|
89
|
+
approval: {
|
|
90
|
+
ownerChatId: Number(process.env.TELEBIBZ_OWNER_CHAT_ID),
|
|
91
|
+
ownerUserId: Number(process.env.TELEBIBZ_OWNER_USER_ID),
|
|
92
|
+
ownerLabel: "Dev Gantenggg",
|
|
93
|
+
requireApproval: true,
|
|
94
|
+
},
|
|
95
|
+
});
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
Library mengirim notifikasi ke `ownerChatId`, sedangkan hanya `ownerUserId` yang dapat mengambil keputusan. Callback menggunakan nonce acak. Untuk deployment multi-instance, gunakan `ApprovalStore` persisten melalui database atau Redis; default-nya adalah memory store.
|
|
99
|
+
|
|
100
|
+
## Webhook
|
|
101
|
+
|
|
102
|
+
```ts
|
|
103
|
+
import { Bot, createWebhookHandler } from "@xbibzlibrary/telebibz";
|
|
104
|
+
|
|
105
|
+
const bot = new Bot(process.env.TELEGRAM_BOT_TOKEN!);
|
|
106
|
+
const handler = createWebhookHandler(bot, {
|
|
107
|
+
secretToken: process.env.TELEGRAM_WEBHOOK_SECRET,
|
|
108
|
+
});
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
`createWebhookHandler` menerima Request Web standar dan menghasilkan Response. Secret token, ukuran body, parsing JSON, dan penanganan update duplikat diverifikasi oleh handler.
|
|
112
|
+
|
|
113
|
+
## State, queue, scheduler, dan cache
|
|
114
|
+
|
|
115
|
+
Paket menyediakan `MemoryStorage` dengan TTL dan pembaruan atomik, `JsonFileStorage`, `RedisStorage`, `SqlStorage`, `MongoStorage`, persistent approval storage, session bot, conversation dan form berbasis Storage, menu berbasis permission, pagination `MenuController`, `MemoryCache`, token-bucket limiter, task queue dengan retry/backoff/concurrency/delay/cancel, serta scheduler interval, one-shot, dan cron lima field lengkap. Adapter Redis, SQL, dan Mongo memakai driver kecil sehingga core package tetap tanpa runtime dependency vendor.
|
|
116
|
+
|
|
117
|
+
## CLI
|
|
118
|
+
|
|
119
|
+
```bash
|
|
120
|
+
npx telebibz init my-bot
|
|
121
|
+
npx telebibz doctor
|
|
122
|
+
npx telebibz build
|
|
123
|
+
npx telebibz test
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
## Testing
|
|
127
|
+
|
|
128
|
+
```bash
|
|
129
|
+
npm run typecheck
|
|
130
|
+
npm run test:types
|
|
131
|
+
npm run lint
|
|
132
|
+
npm test
|
|
133
|
+
npm run build
|
|
134
|
+
npm run security
|
|
135
|
+
npm run release:check
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
E2E Telegram nyata memerlukan `TELEGRAM_BOT_TOKEN` dan `TELEGRAM_TEST_CHAT_ID`. Tanpa kredensial, E2E akan dilewati dan tidak dihitung sebagai lulus.
|
|
139
|
+
|
|
140
|
+
## Web App dan pembayaran
|
|
141
|
+
|
|
142
|
+
`validateWebAppInitData()` memverifikasi signature dan expiration Telegram Web App. `PaymentsClient` menyediakan wrapper invoice link, invoice, jawaban pre-checkout, jawaban Web App query, transaksi Stars, dan refund Stars. Gunakan `TelegramTypes` serta alias seperti `TelegramUser`, `TelegramMessage`, dan `TelegramUpdate` untuk full Telegram declaration surface yang divendor.
|
|
143
|
+
|
|
144
|
+
## API target dan batasan
|
|
145
|
+
|
|
146
|
+
Daftar method dihasilkan dari dokumentasi Telegram Bot API saat skema diperbarui. Akses runtime tersedia untuk method resmi yang terdeteksi, sedangkan inferensi parameter/result khusus dipusatkan pada core method map. Full declaration Telegram untuk object, union, enum, dan method tersedia melalui `TelegramTypes`. Lihat [FEATURE_MATRIX.md](FEATURE_MATRIX.md) untuk status implementasi dan [APPROVAL_FEATURE.md](APPROVAL_FEATURE.md) untuk detail persetujuan.
|
|
147
|
+
|
|
148
|
+
## Otomatisasi release
|
|
149
|
+
|
|
150
|
+
Repository GitHub menyediakan CI dan workflow auto-publish. Setiap push ke `main` menjalankan quality gates, memilih patch version yang belum dipakai, membuat commit dan tag, menerbitkan package ke npm, lalu membuat GitHub Release. Karena source repository bersifat private, workflow menggunakan `--provenance=false`, sesuai batasan npm untuk source private. Konfigurasikan secret `NPM_TOKEN` pada GitHub Actions sebelum mengandalkan publish otomatis. Lihat [RELEASE_AUTOMATION.md](RELEASE_AUTOMATION.md).
|
|
151
|
+
|
|
152
|
+
## Policy project dan kontribusi
|
|
153
|
+
|
|
154
|
+
| Dokumen | Tujuan |
|
|
155
|
+
|---|---|
|
|
156
|
+
| [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) | Perilaku komunitas, penegakan, pelaporan, dan banding. |
|
|
157
|
+
| [CONTRIBUTING.md](CONTRIBUTING.md) | Setup lokal, branch/commit, test, review, dan release workflow. |
|
|
158
|
+
| [CONTRIBUTION_RULES.md](CONTRIBUTION_RULES.md) | Aturan API, compatibility, testing, dependency, security, dan release. |
|
|
159
|
+
| [GOVERNANCE.md](GOVERNANCE.md) | Peran, pengambilan keputusan, triage, perlindungan repository, dan perubahan aturan. |
|
|
160
|
+
| [SECURITY.md](SECURITY.md) | Pelaporan vulnerability privat, batas security, dan rotasi credential. |
|
|
161
|
+
| [SUPPORT.md](SUPPORT.md) | Channel support, aturan laporan aman, dan ekspektasi response. |
|
|
162
|
+
| [RELEASE_AUTOMATION.md](RELEASE_AUTOMATION.md) | Automation GitHub-to-npm dan setup `NPM_TOKEN`. |
|
|
163
|
+
| [RELEASE_POLICY.md](RELEASE_POLICY.md) | Kontrol immutable release dan hardening. |
|
|
164
|
+
| [NOTICE.md](NOTICE.md) | Atribusi declaration pihak ketiga. |
|
|
165
|
+
|
|
166
|
+
## Keamanan
|
|
167
|
+
|
|
168
|
+
Jangan commit token Telegram atau npm. Gunakan variabel lingkungan atau secret manager. Untuk kebijakan keamanan dan peningkatan keamanan rilis, lihat [SECURITY.md](SECURITY.md) dan [RELEASE_POLICY.md](RELEASE_POLICY.md).
|
|
169
|
+
|
|
170
|
+
## Lisensi
|
|
171
|
+
|
|
172
|
+
MIT. Lihat [LICENSE](LICENSE).
|
package/README.md
CHANGED
|
@@ -2,32 +2,42 @@
|
|
|
2
2
|
|
|
3
3
|

|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
[](https://github.com/XbibzOfficial777/telebibz/actions/workflows/ci.yml)
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
**`@xbibzlibrary/telebibz`** is a full-scale Telegram Bot SDK and framework for Node.js and TypeScript. It provides a typed API client, polling, routing, middleware, context helpers, keyboard builders, state/session primitives, webhooks, queues, scheduling, caching, plugin lifecycle, approval gates, CLI tooling, and testing utilities.
|
|
8
|
+
|
|
9
|
+
## Documentation languages
|
|
10
|
+
|
|
11
|
+
**English (default)** · [Bahasa Indonesia](README.id.md) · [简体中文](README.zh-CN.md)
|
|
12
|
+
|
|
13
|
+
Complete API references: [English](docs/API.md) · [Indonesia](docs/API.id.md) · [中文](docs/API.zh-CN.md)
|
|
14
|
+
|
|
15
|
+

|
|
16
|
+
|
|
17
|
+
## Installation
|
|
8
18
|
|
|
9
19
|
```bash
|
|
10
20
|
npm install @xbibzlibrary/telebibz
|
|
11
21
|
```
|
|
12
22
|
|
|
13
|
-
Node.js **20
|
|
23
|
+
Node.js **20 or newer** is required.
|
|
14
24
|
|
|
15
|
-
##
|
|
25
|
+
## Minimal bot
|
|
16
26
|
|
|
17
27
|
```ts
|
|
18
28
|
import { Bot } from "@xbibzlibrary/telebibz";
|
|
19
29
|
|
|
20
30
|
const bot = new Bot(process.env.TELEGRAM_BOT_TOKEN!);
|
|
21
31
|
|
|
22
|
-
bot.command("start", (ctx) => ctx.reply("Bot
|
|
32
|
+
bot.command("start", (ctx) => ctx.reply("Bot is active."));
|
|
23
33
|
bot.onText("ping", (ctx) => ctx.reply("pong"));
|
|
24
34
|
|
|
25
35
|
await bot.start();
|
|
26
36
|
```
|
|
27
37
|
|
|
28
|
-
`Bot.start()`
|
|
38
|
+
`Bot.start()` runs long polling. For manual lifecycle control, use `init()`, `launch({ mode: "polling" })`, `health()`, `stop()`, or `restart()`.
|
|
29
39
|
|
|
30
|
-
## Router
|
|
40
|
+
## Router and middleware
|
|
31
41
|
|
|
32
42
|
```ts
|
|
33
43
|
bot.use(async (ctx, next) => {
|
|
@@ -36,44 +46,44 @@ bot.use(async (ctx, next) => {
|
|
|
36
46
|
console.log(`processed in ${Date.now() - started}ms`);
|
|
37
47
|
});
|
|
38
48
|
|
|
39
|
-
bot.command("help", (ctx) => ctx.reply("
|
|
40
|
-
bot.onRegex(/^order:(\\d+)$/, (ctx) => ctx.reply("Order
|
|
41
|
-
bot.callback("profile:", (ctx) => ctx.answerCallbackQuery("
|
|
49
|
+
bot.command("help", (ctx) => ctx.reply("Help is available."));
|
|
50
|
+
bot.onRegex(/^order:(\\d+)$/, (ctx) => ctx.reply("Order received."));
|
|
51
|
+
bot.callback("profile:", (ctx) => ctx.answerCallbackQuery("Opened."));
|
|
42
52
|
```
|
|
43
53
|
|
|
44
|
-
|
|
54
|
+
The router supports commands, exact text, regular expressions, callback patterns, custom predicates, nested routers, per-route middleware, and route priority.
|
|
45
55
|
|
|
46
56
|
## Telegram API
|
|
47
57
|
|
|
48
|
-
Generated method access
|
|
58
|
+
Generated method access and raw access are available through the API client:
|
|
49
59
|
|
|
50
60
|
```ts
|
|
51
61
|
await bot.api.methods.getMe();
|
|
52
|
-
await bot.api.methods.sendMessage({ chat_id: 123456789, text: "
|
|
53
|
-
await bot.api.call("sendMessage", { chat_id: 123456789, text: "
|
|
62
|
+
await bot.api.methods.sendMessage({ chat_id: 123456789, text: "Hello." });
|
|
63
|
+
await bot.api.call("sendMessage", { chat_id: 123456789, text: "Hello." });
|
|
54
64
|
await bot.api.raw("futureTelegramMethod", { value: true });
|
|
55
65
|
```
|
|
56
66
|
|
|
57
|
-
|
|
67
|
+
The built-in transport uses `fetch`, timeouts, retries, exponential backoff, JSON payloads, and multipart upload.
|
|
58
68
|
|
|
59
|
-
## Keyboard
|
|
69
|
+
## Keyboard builders
|
|
60
70
|
|
|
61
71
|
```ts
|
|
62
72
|
import { InlineKeyboard } from "@xbibzlibrary/telebibz";
|
|
63
73
|
|
|
64
74
|
const keyboard = new InlineKeyboard()
|
|
65
|
-
.text("
|
|
66
|
-
.url("
|
|
75
|
+
.text("Profile", "profile")
|
|
76
|
+
.url("Documentation", "https://core.telegram.org/bots/api")
|
|
67
77
|
.build();
|
|
68
78
|
|
|
69
|
-
await ctx.reply("
|
|
79
|
+
await ctx.reply("Choose an option:", { reply_markup: keyboard });
|
|
70
80
|
```
|
|
71
81
|
|
|
72
|
-
|
|
82
|
+
Builders produce native Telegram keyboard payloads. HTML/CSS interfaces require a separate Mini App or Web App.
|
|
73
83
|
|
|
74
|
-
## Owner approval
|
|
84
|
+
## Owner approval gate
|
|
75
85
|
|
|
76
|
-
|
|
86
|
+
The approval gate pauses regular updates until the owner approves or denies a new bot through inline buttons.
|
|
77
87
|
|
|
78
88
|
```ts
|
|
79
89
|
const bot = new Bot({
|
|
@@ -87,7 +97,7 @@ const bot = new Bot({
|
|
|
87
97
|
});
|
|
88
98
|
```
|
|
89
99
|
|
|
90
|
-
|
|
100
|
+
The library sends the notification to `ownerChatId`, while only `ownerUserId` can decide. Callback data uses a random nonce. For multi-instance deployments, provide a persistent `ApprovalStore`; the default store is in memory.
|
|
91
101
|
|
|
92
102
|
## Webhook
|
|
93
103
|
|
|
@@ -100,11 +110,11 @@ const handler = createWebhookHandler(bot, {
|
|
|
100
110
|
});
|
|
101
111
|
```
|
|
102
112
|
|
|
103
|
-
`createWebhookHandler`
|
|
113
|
+
`createWebhookHandler` accepts a standard Web `Request` and returns a `Response`. It verifies the optional secret token, body size, JSON payload, and update shape before calling `bot.handleUpdate()`.
|
|
104
114
|
|
|
105
|
-
## State, queue, scheduler,
|
|
115
|
+
## State, queue, scheduler, and cache
|
|
106
116
|
|
|
107
|
-
|
|
117
|
+
The package provides `MemoryStorage` with TTL and serialized per-key updates, `JsonFileStorage`, `RedisStorage`, `SqlStorage`, `MongoStorage`, persistent approval storage, bot sessions, storage-backed conversations and forms, permission-aware menus, `MenuController` pagination, `MemoryCache`, a token-bucket limiter, a task queue with retry/backoff/concurrency/delay/cancel, and schedulers for intervals, one-shot tasks, and full five-field cron expressions. Redis, SQL, and Mongo adapters use small driver interfaces so the core package remains free of vendor runtime dependencies.
|
|
108
118
|
|
|
109
119
|
## CLI
|
|
110
120
|
|
|
@@ -127,16 +137,38 @@ npm run security
|
|
|
127
137
|
npm run release:check
|
|
128
138
|
```
|
|
129
139
|
|
|
130
|
-
Real Telegram E2E
|
|
140
|
+
Real Telegram E2E tests require `TELEGRAM_BOT_TOKEN` and `TELEGRAM_TEST_CHAT_ID`. Without credentials, E2E tests are skipped and are not counted as passing.
|
|
141
|
+
|
|
142
|
+
## Web Apps and payments
|
|
143
|
+
|
|
144
|
+
`validateWebAppInitData()` verifies Telegram Web App signatures and expiration. `PaymentsClient` provides wrappers for invoice links, invoices, pre-checkout answers, Web App query answers, Stars transactions, and Stars refunds. Use `TelegramTypes` and aliases such as `TelegramUser`, `TelegramMessage`, and `TelegramUpdate` for the vendored full Telegram declaration surface.
|
|
145
|
+
|
|
146
|
+
## API targets and limitations
|
|
147
|
+
|
|
148
|
+
The generated method list is derived from the Telegram Bot API schema when it is updated. Runtime access is available for detected official methods, while specialized request/result inference remains concentrated on the core method map. The complete vendored Telegram object, union, enum, and method declarations are available through `TelegramTypes`. See [FEATURE_MATRIX.md](FEATURE_MATRIX.md) for implementation status and [APPROVAL_FEATURE.md](APPROVAL_FEATURE.md) for approval details.
|
|
149
|
+
|
|
150
|
+
For every exported class, function, method, type, error, lifecycle hook, CLI command, and generated Telegram method, see the [complete English API reference](docs/API.md).
|
|
151
|
+
|
|
152
|
+
## Release automation
|
|
131
153
|
|
|
132
|
-
|
|
154
|
+
The GitHub repository includes CI and an auto-publish workflow. A push to `main` runs the quality gates, chooses the next unused patch version, commits the version, creates a tag, publishes to npm, and creates a GitHub Release. Because the source repository is private, the workflow uses `--provenance=false`, which npm requires for private source repositories. Configure the `NPM_TOKEN` GitHub Actions secret before relying on automatic publication. See [RELEASE_AUTOMATION.md](RELEASE_AUTOMATION.md).
|
|
133
155
|
|
|
134
|
-
|
|
156
|
+
## Project policies and contribution
|
|
135
157
|
|
|
136
|
-
|
|
158
|
+
| Document | Purpose |
|
|
159
|
+
|---|---|
|
|
160
|
+
| [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) | Community behavior, enforcement, reporting, and appeals. |
|
|
161
|
+
| [CONTRIBUTING.md](CONTRIBUTING.md) | Local setup, branch/commit rules, tests, review, and release workflow. |
|
|
162
|
+
| [CONTRIBUTION_RULES.md](CONTRIBUTION_RULES.md) | API, compatibility, testing, dependency, security, and release requirements. |
|
|
163
|
+
| [GOVERNANCE.md](GOVERNANCE.md) | Roles, decision-making, triage, repository protection, and amendments. |
|
|
164
|
+
| [SECURITY.md](SECURITY.md) | Private vulnerability reporting, threat boundaries, and credential rotation. |
|
|
165
|
+
| [SUPPORT.md](SUPPORT.md) | Support channels, safe-reporting rules, and request expectations. |
|
|
166
|
+
| [RELEASE_AUTOMATION.md](RELEASE_AUTOMATION.md) | GitHub-to-npm automation and required `NPM_TOKEN` setup. |
|
|
167
|
+
| [RELEASE_POLICY.md](RELEASE_POLICY.md) | Immutable release and hardening controls. |
|
|
168
|
+
| [NOTICE.md](NOTICE.md) | Third-party declaration attribution. |
|
|
137
169
|
|
|
138
|
-
|
|
170
|
+
Never commit Telegram tokens or npm credentials. Use environment variables or a secret manager. See [SECURITY.md](SECURITY.md) and [RELEASE_POLICY.md](RELEASE_POLICY.md) for security and release hardening policies.
|
|
139
171
|
|
|
140
|
-
##
|
|
172
|
+
## License
|
|
141
173
|
|
|
142
|
-
MIT.
|
|
174
|
+
MIT. See [LICENSE](LICENSE).
|