feat(line): migrate LINE trust config to first-class [line] section (Phase 1)

[chaodu-agent]

Summary

Migrate the LINE adapter trust configuration from gateway env vars (GATEWAY_ALLOW_ALL_USERS, GATEWAY_ALLOWED_USERS) to a first-class [line] section in config.toml, aligning with the Phase 1 architecture defined in the identity-trust-none ADR (#1291).

Trust Level Scenarios (wide-open → strictest)

Level	Config	Use Case	Risk
🔓 Wide-open (NOT recommended)	allow_all_users = true	Public service bot — anyone who DMs or @mentions can use it	Any stranger can drive the agent; cost/abuse risk
🔒 Group-level trust	groups.policy = "open"	Bot added to specific LINE groups — anyone in those groups who @mentions can use it	Group membership = trust boundary; "unknown" senders permitted; audit only at group level
🔒🔒 Group + per-user	groups.policy = "members" + allowed_users	Bot in groups, but only specific users can trigger it	"unknown" senders denied; full per-user audit; requires users to have privacy settings that expose their ID
🔒🔒🔒 Strictest (per-user only)	allowed_users = ["Uaaa", "Ubbb"]	1:1 DM bot or tightly controlled group bot	Only listed users can use the bot; "unknown" always denied

Config Examples

Wide-open (not recommended):

[line]
allow_all_users = true

Group-level trust (recommended for group bots):

[line]
default_group_policy = "open"

# Optionally restrict to specific groups:
[[line.groups]]
id = "C1234567890"
policy = "open"

[[line.groups]]
id = "C0987654321"
policy = "members"  # stricter for this group

Per-user only (strictest):

[line]
allowed_users = ["U1234567890abcdef0123456789abcdef", "Uaabbccdd0011223344556677889900ff"]
default_group_policy = "members"

LINE-specific considerations

• "unknown" sender IDs: LINE privacy settings can hide user IDs in groups. policy = "open" handles this gracefully; policy = "members" rejects unknown senders.
• Deny-echo delivery: Must use Reply API only (never Push API) to avoid burning paid Push quota on attackers. If reply token expires (~50s), echo is silently dropped.
• @mention pre-filter: LINE Receiver drops non-@mention group messages BEFORE the Trust Gate to prevent deny-echo spam in noisy groups.

Current State (beta.8+)

LINE trust is controlled via gateway-level env vars:

GATEWAY_ALLOW_ALL_USERS=true/false
GATEWAY_ALLOWED_USERS=Uaaa,Ubbb

These apply to ALL gateway platforms uniformly — no per-platform granularity.

Target State (Phase 1)

First-class [line] section in config.toml with per-platform trust config, group policy support, and LINE-specific echo delivery.

Tasks

• Add [line] section to config schema with allowed_users, allow_all_users (feat(line): first-class [line] trust section (Phase 1) #1365)
• Wire LINE trust through the shared PlatformTrustConfigs registry (feat(line): first-class [line] trust section (Phase 1) #1365 — embedded/unified path; WS-path consolidation tracked on umbrella: Phase 1 trust migration — per-platform [section] for all adapters #1356)
• Implement LINE group policy (open/members) for "unknown" sender handling
• Implement deny-echo via Reply API only (never Push)
• Deprecate GATEWAY_ALLOW_ALL_USERS / GATEWAY_ALLOWED_USERS for LINE (warn on use) (feat(line): first-class [line] trust section (Phase 1) #1365)
• Update config.toml.example and docs (feat(line): first-class [line] trust section (Phase 1) #1365)
• Add migration guide in release notes

Context

• ADR: docs(adr): revise identity-trust-none — three-layer architecture #1291
• Phase 3 default flip (env var): bcd03ff (PR feat(trust): gateway echo-on-deny (Phase 2) + trust-none default (Phase 3) #1273)
• Reported by contributor (Max): bumping to beta.8 requires explicit GATEWAY_ALLOW_ALL_USERS=true in manifest for LINE to work

Refs

• feat(channels): default trust-none policy with UID echo for all channel adapters #1262 (tracking issue)
• docs(adr): identity trust-none default & trust pyramid #1264 (original ADR)
• docs(adr): revise identity-trust-none — three-layer architecture #1291 (v2 ADR — three-layer architecture)

[github-actions]

⚠️ This issue is missing the following required information and will not be processed until completed:

• Use Case

Please edit this issue to fill in the missing fields. Thank you!

Tip: Use headings like ## Description or ### Description — common synonyms (e.g. ## Problem, ## Reproduction, ## Motivation) are also accepted.

[github-actions]

This issue has been open for more than 14 days with no linked pull request, so it is being closed as not planned.

If this is still needed, please open a new issue with updated context and reference this closed issue instead of reopening it. A linked PR is the strongest signal that the work matters.