mirror of
https://gitverse.ru/kpa39l/vesti.git
synced 2026-09-29 18:05:03 +00:00
Initial import: vesti.nixg.ru — новостной апрув-проект (web, crawler, classifier, publisher, openspec)
This commit is contained in:
kpa39l
@@ -0,0 +1,18 @@
|
||||
# VESTI — секреты и конфигурация (скопируйте в .env, НЕ коммитить)
|
||||
# Telegram API (переиспользуем из /opt/icq/docker-compose.yml)
|
||||
TG_API_ID=24276216
|
||||
TG_API_HASH=your_api_hash_here
|
||||
# прокси для Telegram (из РФ заблокирован)
|
||||
TG_PROXY=socks5://127.0.0.1:1080
|
||||
# Telethon-сессия (путь к каталогу сессии)
|
||||
TG_SESSION_DIR=/opt/vesti/telegram
|
||||
# Бот-публикатор (токен от @BotFather)
|
||||
VESTI_BOT_TOKEN=your_bot_token_here
|
||||
# Канал публикации (шаблон dedinit_vesti_<direction>_<lang>_bot)
|
||||
VESTI_BOT_CHANNEL=@dedinit_vesti_linux_ru_bot
|
||||
# Веб-админ
|
||||
ADMIN_USER=admin
|
||||
ADMIN_PASSWORD=change_me
|
||||
# Ollama
|
||||
OLLAMA_URL=http://127.0.0.1:11434
|
||||
OLLAMA_MODEL=qwen3:8b-nothink
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
.env
|
||||
.env.bak*
|
||||
.env.example.bak
|
||||
db/
|
||||
media/
|
||||
backups/
|
||||
bundles/
|
||||
logs/
|
||||
__pycache__/
|
||||
*.pyc
|
||||
.venv/
|
||||
telegram/*.session
|
||||
telegram/*.session-journal
|
||||
@@ -0,0 +1,188 @@
|
||||
---
|
||||
name: openspec-apply-change
|
||||
description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
|
||||
allowed-tools: Bash(openspec:*)
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.12.0"
|
||||
---
|
||||
|
||||
Implement tasks from an OpenSpec change.
|
||||
|
||||
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
|
||||
|
||||
**Input**: Optionally specify a change name (e.g., `/openspec-apply-change add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
If a name is provided, use it. Otherwise:
|
||||
- Infer from conversation context if the user mentioned a change
|
||||
- Auto-select if only one active change exists
|
||||
- If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
|
||||
|
||||
Always announce: "Using change: <name>" and how to override (e.g., `/openspec-apply-change <other>`).
|
||||
|
||||
2. **Check status to understand the schema**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
Parse the JSON to understand:
|
||||
- `schemaName`: The workflow being used (e.g., "spec-driven")
|
||||
- `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
|
||||
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
|
||||
|
||||
3. **Get apply instructions**
|
||||
|
||||
```bash
|
||||
openspec instructions apply --change "<name>" --json
|
||||
```
|
||||
|
||||
This returns:
|
||||
- `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
|
||||
- Progress (total, complete, remaining)
|
||||
- Task list with status
|
||||
- Dynamic instruction based on current state
|
||||
- Optional `context`: current required project instruction input from the selected root
|
||||
- Optional `operationGuidance`: current advisory guidance for apply
|
||||
|
||||
**Handle states:**
|
||||
- If `state: "blocked"` (missing artifacts): show message, suggest using `/openspec-continue-change` (if it is not installed, run `openspec status --change "<name>" --json` to see the next artifact and `openspec instructions <artifact-id> --change "<name>" --json` for how to create it)
|
||||
- If `state: "all_done"`: congratulate, suggest archive
|
||||
- Otherwise: proceed to implementation
|
||||
|
||||
Treat `context` as a required prompt-level input. Read and consider it, and
|
||||
apply relevant project facts, conventions, and constraints while implementing.
|
||||
Treat `operationGuidance` as optional additive advice. Read and consider every
|
||||
entry, and follow entries that are applicable and compatible with the built-in
|
||||
workflow.
|
||||
|
||||
Keep both fields separate from CLI-returned state, missing artifacts, tasks,
|
||||
progress, `contextFiles`, and the built-in `instruction`. They are not
|
||||
evidence of task completion, do not replace the built-in instruction, and do
|
||||
not permit bypassing a blocked state. If context conflicts with the built-in
|
||||
instruction, an explicit user choice, or a CLI-controlled value, report the
|
||||
conflict and preserve the controlling value. If guidance is inapplicable or
|
||||
conflicts with those controlling inputs, do not follow it and explain why.
|
||||
These are prompt-level behavior contracts, not enforceable checks.
|
||||
|
||||
4. **Read context files**
|
||||
|
||||
Read every file path listed under `contextFiles` from the apply instructions output.
|
||||
The files depend on the schema being used:
|
||||
- **spec-driven**: proposal, specs, design, tasks
|
||||
- Other schemas: follow the contextFiles from CLI output
|
||||
|
||||
Do not copy `context` or `operationGuidance` verbatim into implementation
|
||||
files or planning artifacts unless the user separately asks for that content.
|
||||
|
||||
5. **Show current progress**
|
||||
|
||||
Display:
|
||||
- Schema being used
|
||||
- Progress: "N/M tasks complete"
|
||||
- Remaining tasks overview
|
||||
- Dynamic instruction from CLI
|
||||
|
||||
6. **Implement tasks (loop until done or blocked)**
|
||||
|
||||
For each pending task:
|
||||
- Show which task is being worked on
|
||||
- Make the code changes required
|
||||
- Keep changes minimal and focused
|
||||
- Mark task complete in the tasks file: `- [ ]` → `- [x]`
|
||||
- Continue to next task
|
||||
|
||||
**Pause if:**
|
||||
- Task is unclear → ask for clarification
|
||||
- Implementation reveals a design issue → suggest updating artifacts
|
||||
- A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently
|
||||
- Error or blocker encountered → report and wait for guidance
|
||||
- User interrupts
|
||||
|
||||
7. **On completion or pause, show status**
|
||||
|
||||
Display:
|
||||
- Tasks completed this session
|
||||
- Overall progress: "N/M tasks complete"
|
||||
- If all done: suggest archive
|
||||
- If paused: explain why and wait for guidance
|
||||
|
||||
**Output During Implementation**
|
||||
|
||||
```
|
||||
## Implementing: <change-name> (schema: <schema-name>)
|
||||
|
||||
Working on task 3/7: <task description>
|
||||
[...implementation happening...]
|
||||
✓ Task complete
|
||||
|
||||
Working on task 4/7: <task description>
|
||||
[...implementation happening...]
|
||||
✓ Task complete
|
||||
```
|
||||
|
||||
**Output On Completion**
|
||||
|
||||
```
|
||||
## Implementation Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Progress:** 7/7 tasks complete ✓
|
||||
|
||||
### Completed This Session
|
||||
- [x] Task 1
|
||||
- [x] Task 2
|
||||
...
|
||||
|
||||
All tasks complete! You can archive this change with `/openspec-archive-change`.
|
||||
```
|
||||
|
||||
**Output On Pause (Issue Encountered)**
|
||||
|
||||
```
|
||||
## Implementation Paused
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Progress:** 4/7 tasks complete
|
||||
|
||||
### Issue Encountered
|
||||
<description of the issue>
|
||||
|
||||
**Options:**
|
||||
1. <option 1>
|
||||
2. <option 2>
|
||||
3. Other approach
|
||||
|
||||
What would you like to do?
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Keep going through tasks until done or blocked
|
||||
- Always read context files before starting (from the apply instructions output)
|
||||
- If task is ambiguous, pause and ask before implementing
|
||||
- If implementation reveals issues, pause and suggest artifact updates
|
||||
- Keep code changes minimal and scoped to each task
|
||||
- Update task checkbox immediately after completing each task
|
||||
- Pause on errors, blockers, or unclear requirements - don't guess
|
||||
- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
|
||||
- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred
|
||||
- Use contextFiles from CLI output, don't assume specific file names
|
||||
- Do not use context or operation guidance as proof that a task is complete
|
||||
- Apply relevant project context; report conflicts with controlling workflow inputs
|
||||
- Consider every guidance entry; explain any inapplicable or conflicting advice
|
||||
- Do not copy runtime context or operation guidance into implementation files or planning artifacts
|
||||
- Preserve CLI-controlled blocked/ready/all-done behavior and completion criteria
|
||||
|
||||
**Fluid Workflow Integration**
|
||||
|
||||
This skill supports the "actions on a change" model:
|
||||
|
||||
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
|
||||
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
|
||||
@@ -0,0 +1,182 @@
|
||||
---
|
||||
name: openspec-archive-change
|
||||
description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
|
||||
allowed-tools: Bash(openspec:*)
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.12.0"
|
||||
---
|
||||
|
||||
Archive a completed change in the experimental workflow.
|
||||
|
||||
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
|
||||
|
||||
`<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve the full path from each delta spec when resolving its main spec.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
If a name is provided, use it. Otherwise:
|
||||
- Infer from conversation context if the user mentioned a change
|
||||
- Auto-select if only one active change exists
|
||||
- If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
|
||||
|
||||
When prompting, show only active changes (not already archived).
|
||||
Include the schema used for each change if available.
|
||||
|
||||
Always announce: "Using change: <name>" and how to override (e.g., `/openspec-archive-change <other>`).
|
||||
|
||||
**Load current archive inputs before the existing archive checks:**
|
||||
|
||||
After resolving the selected change and planning root, run:
|
||||
```bash
|
||||
openspec instructions archive --change "<name>" --json
|
||||
```
|
||||
Keep the same selected-root flags on this command. This lookup is advisory and
|
||||
optional: it only supplies extra prompt inputs, so it must never block archiving.
|
||||
If it exits non-zero or returns invalid JSON — for example on an older CLI that
|
||||
does not support this command yet — continue the archive workflow with no
|
||||
context and no operation guidance. Do not report an error and do not stop.
|
||||
|
||||
A successful response may omit both optional fields. Treat `context` as a
|
||||
required prompt-level input: read and consider it, and apply relevant project
|
||||
facts, conventions, and constraints. Treat `operationGuidance` as optional
|
||||
additive advice: read and consider every entry, and follow entries that are
|
||||
applicable and compatible with the built-in archive workflow.
|
||||
|
||||
Keep both fields separate from built-in steps, explicit user choices, resolved
|
||||
paths, CLI checks, and command contracts. If context conflicts with one of those
|
||||
controlling inputs, report the conflict and preserve the controlling value. If
|
||||
guidance is inapplicable or conflicts with a controlling input, do not follow it
|
||||
and explain why. Do not infer replacement paths, skipped prompts, or flags from
|
||||
either field, and do not copy their text verbatim into specs, change artifacts,
|
||||
or archive summaries unless the user separately asks for it. These are
|
||||
prompt-level behavior contracts, not enforceable checks.
|
||||
|
||||
2. **Check artifact completion status**
|
||||
|
||||
Run `openspec status --change "<name>" --json` to check artifact completion.
|
||||
|
||||
Parse the JSON to understand:
|
||||
- `schemaName`: The workflow being used
|
||||
- `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
|
||||
- `artifacts`: List of artifacts with their status (`done`, `skipped`, or other)
|
||||
|
||||
**If any artifacts are neither `done` nor `skipped`** (skipped artifacts satisfy the requirement - the change declares skip_specs):
|
||||
- Display warning listing incomplete artifacts
|
||||
- Ask the user to confirm they want to proceed
|
||||
- Proceed if user confirms
|
||||
|
||||
3. **Check task completion status**
|
||||
|
||||
Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
|
||||
|
||||
Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
|
||||
|
||||
**If incomplete tasks found:**
|
||||
- Display warning showing count of incomplete tasks
|
||||
- Ask the user to confirm they want to proceed
|
||||
- Proceed if user confirms
|
||||
|
||||
**If no tasks file exists:** Proceed without task-related warning.
|
||||
|
||||
4. **Assess delta spec sync state**
|
||||
|
||||
Use `artifactPaths.specs.existingOutputPaths` from status JSON as the only
|
||||
delta-spec source. If the `specs` entry is missing or
|
||||
`existingOutputPaths` is empty, proceed without a sync prompt and do not infer
|
||||
delta specs from other artifacts.
|
||||
|
||||
**If delta specs exist:**
|
||||
- Compare each delta spec with its corresponding main spec at `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (use the store-aware `planningHome.root` from step 2, not a hardcoded repo path)
|
||||
- Determine what changes would be applied (adds, modifications, removals, renames)
|
||||
- Show a combined summary before prompting
|
||||
|
||||
**Prompt options:**
|
||||
- If changes needed: "Sync now (recommended)", "Archive without syncing"
|
||||
- If already synced: "Archive now", "Sync anyway", "Cancel"
|
||||
|
||||
Route on the answer:
|
||||
- "Cancel" — stop, do not archive
|
||||
- "Archive without syncing" or "Archive now" — proceed to archive
|
||||
- "Sync now" or "Sync anyway" — sync, then verify (below)
|
||||
- Anything else — ask again rather than archiving
|
||||
|
||||
Before a selected sync writes any main spec, run
|
||||
`openspec instructions specs --change "<name>" --json` once with the same
|
||||
selected-root flags. Require a zero exit status and valid artifact-instruction
|
||||
JSON. If the lookup fails or returns invalid JSON, report the error and stop
|
||||
before writing any main spec or moving the change. A valid response with omitted
|
||||
`rules` is the no-rules case. Apply returned `rules` only to the content and
|
||||
form of main specs produced by this merge; do not use them as archive guidance,
|
||||
change CLI behavior, or copy the rule text into any output file.
|
||||
|
||||
Then run the `openspec-sync-specs` workflow inline (agent-driven intelligent merge) for change '<name>', passing the delta spec analysis and the fetched specs-rule snapshot from above, and wait for it to finish. The inline sync must reuse that snapshot without fetching `specs` instructions again. Do not delegate it to a background task — step 5 would move `changeRoot` out from under a sync that is still reading it, leaving the change archived and the main specs never updated. If your agent can only run it by delegation, delegate synchronously and wait for the result.
|
||||
|
||||
Then re-run the comparison from the top of this step against every capability that has a delta spec in `artifactPaths.specs.existingOutputPaths` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
|
||||
- ADDED requirements present
|
||||
- MODIFIED requirements carrying the scenario and description changes named in the delta, with their other scenarios intact
|
||||
- REMOVED requirements gone — and where this sync retired a capability (removed its last requirement, leaving `## Requirements` empty), its main spec deleted rather than left empty; a spec the sync deliberately kept and reported is also a match
|
||||
- RENAMED requirements present under the new name and absent under the old one
|
||||
|
||||
If the sync failed, or any capability does not match, report what differs and stop — do not archive. Nothing has moved and `changeRoot` is intact, so the user can fix the mismatch or re-run the sync and start the archive again.
|
||||
|
||||
5. **Perform the archive**
|
||||
|
||||
Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
|
||||
```bash
|
||||
mkdir -p "<planningHome.changesDir>/archive"
|
||||
```
|
||||
|
||||
Generate the target name: use the change name as-is when it already starts with a `YYYY-MM-DD-` prefix; otherwise prepend the current date as `YYYY-MM-DD-<change-name>`. Never stack a second date (same rule as `openspec archive`).
|
||||
|
||||
**Check if target already exists:**
|
||||
- If yes: Fail with error, suggest renaming existing archive or using different date
|
||||
- If no: Move `changeRoot` to the archive directory
|
||||
|
||||
```bash
|
||||
mv "<changeRoot>" "<planningHome.changesDir>/archive/<target-name>"
|
||||
```
|
||||
|
||||
6. **Display summary**
|
||||
|
||||
Show archive completion summary including:
|
||||
- Change name
|
||||
- Schema that was used
|
||||
- Archive location
|
||||
- Whether specs were synced (if applicable)
|
||||
- Note about any warnings (incomplete artifacts/tasks)
|
||||
|
||||
**Output On Success**
|
||||
|
||||
```markdown
|
||||
## Archive Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Archived to:** the archive path derived from `planningHome.changesDir`/<target-name>/
|
||||
**Specs:** <"✓ Synced to main specs" only if the step 4 verification passed; otherwise "No delta specs" or "Sync skipped">
|
||||
|
||||
<"All artifacts complete. All tasks complete." — or, if archived with warnings, list them instead (e.g. "Archived with 2 incomplete tasks")>
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Announce the selected change; prompt for selection when it is ambiguous
|
||||
- Use artifact graph (openspec status --json) for completion checking
|
||||
- Don't block archive on warnings - just inform and confirm
|
||||
- Preserve .openspec.yaml when moving to archive (it moves with the directory)
|
||||
- Show clear summary of what happened
|
||||
- If sync is requested, run the `openspec-sync-specs` workflow inline (agent-driven)
|
||||
- Never archive while a spec sync is still in flight — run the sync inline and verify the main specs before moving `changeRoot`
|
||||
- If delta specs exist, always run the sync assessment and show the combined summary before prompting
|
||||
- Apply relevant runtime context and report conflicts; operation guidance remains advisory
|
||||
- Consider every guidance entry and explain any inapplicable or conflicting advice
|
||||
- Existing CLI checks, resolved paths, prompts, and command contracts are unchanged
|
||||
- Artifact rules constrain only the specs being written and are never operation guidance
|
||||
- Never copy runtime context, operation guidance, or artifact-rule text verbatim into output files
|
||||
@@ -0,0 +1,335 @@
|
||||
---
|
||||
name: openspec-explore
|
||||
description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
|
||||
allowed-tools: Bash(openspec:*)
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.12.0"
|
||||
---
|
||||
|
||||
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
|
||||
|
||||
**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. For a new change, scaffold it first as described below.
|
||||
|
||||
**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
|
||||
|
||||
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
|
||||
|
||||
---
|
||||
|
||||
## The Stance
|
||||
|
||||
- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
|
||||
- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
|
||||
- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
|
||||
- **Adaptive** - Follow interesting threads, pivot when new information emerges
|
||||
- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
|
||||
- **Grounded** - Explore the actual codebase when relevant, don't just theorize
|
||||
|
||||
---
|
||||
|
||||
## Planning a Change
|
||||
|
||||
When the user is planning a change, guide them toward shared understanding with focused discovery questions. For open-ended discussion, follow the conversation without imposing an interview or a required output.
|
||||
|
||||
Before asking a factual question, follow the context discovery below and inspect relevant OpenSpec artifacts, source, tests, docs, and configuration. Do not ask the user to repeat facts you can verify. Summarize relevant findings without reproducing private context or rules. If evidence is missing, conflicting, or inaccessible, state that limitation and ask only for the clarification needed to proceed.
|
||||
|
||||
- **Follow dependencies** - Resolve the next blocking decision before its dependent details. For example, clarify the user's outcome and scope before choosing an API or data model. Revisit downstream assumptions when an earlier answer changes. Skip branches that do not matter to this goal.
|
||||
- **Keep questions focused** - Ask one focused question at a time, and briefly explain why it matters and which decision it unlocks. Batch questions only if the user asks for a batch; keep them small and group related decisions.
|
||||
- **Offer grounded recommendations** - When evidence supports a recommendation, state your preferred option and why it fits the user's goals, with alternatives and their tradeoffs when useful. Do not invent intent, priorities, or external constraints: ask the user when only they can answer. Avoid a fixed question format.
|
||||
- **Keep a conversational record** - Track decisions in the conversation, not in files. Separate confirmed decisions from proposed defaults and unresolved questions. Silence is not acceptance. Accepting an answer or a batch of recommendations is not permission to write. Keep file-write confirmation separate from discovery questions and follow the guardrails below.
|
||||
|
||||
Stop asking when the user has enough clarity. Let them pause, pivot, or defer a decision; do not exhaust every branch or force a proposal.
|
||||
|
||||
For example, after inspecting the relevant code:
|
||||
|
||||
```text
|
||||
The CLI already uses SQLite and has no remote service. Is sharing state
|
||||
across devices in scope? That determines whether local storage is enough.
|
||||
If this stays a single-device tool, I recommend keeping SQLite to avoid
|
||||
adding a service to operate; shared state would need a separate sync design.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What You Might Do
|
||||
|
||||
Depending on what the user brings, you might:
|
||||
|
||||
**Explore the problem space**
|
||||
- Ask clarifying questions that emerge from what they said
|
||||
- Challenge assumptions
|
||||
- Reframe the problem
|
||||
- Find analogies
|
||||
|
||||
**Investigate the codebase**
|
||||
- Map existing architecture relevant to the discussion
|
||||
- Find integration points
|
||||
- Identify patterns already in use
|
||||
- Surface hidden complexity
|
||||
|
||||
**Compare options**
|
||||
- Brainstorm multiple approaches
|
||||
- Build comparison tables
|
||||
- Sketch tradeoffs
|
||||
- Recommend a path (if asked)
|
||||
|
||||
**Visualize**
|
||||
```
|
||||
+------------------------------------------+
|
||||
| Use ASCII diagrams liberally |
|
||||
+------------------------------------------+
|
||||
| |
|
||||
| [State A] -------> [State B] |
|
||||
| | |
|
||||
| v |
|
||||
| [State C] |
|
||||
| |
|
||||
| System diagrams, state machines, |
|
||||
| data flows, architecture sketches, |
|
||||
| dependency graphs, comparison tables |
|
||||
| |
|
||||
+------------------------------------------+
|
||||
```
|
||||
|
||||
**Draw with plain ASCII only** — borders `+` `-` `|`, arrows `-->` `<--` `^` `v`, markers `*` `x`.
|
||||
Unicode diagram glyphs can render at different widths across terminals, fonts, and locales, so padded boxes and aligned tables can drift. Keep every diagram character ASCII.
|
||||
|
||||
**Surface risks and unknowns**
|
||||
- Identify what could go wrong
|
||||
- Find gaps in understanding
|
||||
- Suggest spikes or investigations
|
||||
|
||||
---
|
||||
|
||||
## OpenSpec Awareness
|
||||
|
||||
You have full context of the OpenSpec system. Use it naturally, don't force it.
|
||||
|
||||
### Check for context
|
||||
|
||||
At the start, quickly check what exists:
|
||||
```bash
|
||||
openspec list --json
|
||||
```
|
||||
|
||||
This tells you:
|
||||
- If there are active changes
|
||||
- Their names, schemas, and status
|
||||
- What the user might be working on
|
||||
|
||||
Then read the project's own context from the resolved root - `<root.path>/openspec/config.yaml` (or `config.yml`). Use the `root.path` returned above, and skip this if neither file exists:
|
||||
- `context`: project background - tech stack, conventions, constraints
|
||||
- `rules`: keyed by artifact id - the entries for an artifact apply only when you write that artifact
|
||||
|
||||
Ground your thinking in these. They are constraints for you to follow, not content to reproduce: do NOT copy them into the conversation or into any artifact you create.
|
||||
|
||||
### When no change exists
|
||||
|
||||
Think freely. When insights crystallize, you might offer:
|
||||
|
||||
- "This feels solid enough to start a change. Want me to create a proposal?"
|
||||
- Or keep exploring - no pressure to formalize
|
||||
|
||||
If the user asks you to capture the exploration as a new change, transition seamlessly into the requested capture:
|
||||
|
||||
1. Run `openspec new change "<name>"` (with `--store <id>` when applicable) before creating any artifacts. Never create a new change directory under `openspec/changes/` by hand; the CLI scaffold creates required metadata such as `.openspec.yaml`. Keep the selected `--store <id>` on every applicable follow-up `status` and `instructions` command.
|
||||
2. Run `openspec status --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store), then process the requested artifacts in dependency order. For each requested artifact that is `ready`, run `openspec instructions "<artifact-id>" --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store). Before creating a requested artifact, evaluate any condition in its own `instruction` against the explored change; record a deliberate skip instead when the condition does not apply. If a requested artifact is blocked by a direct prerequisite the user did not request, run `openspec instructions "<prerequisite-id>" --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store) for that prerequisite whether it is `ready` or `blocked`. If its own `instruction` states a condition, evaluate that condition against the explored change and record a deliberate skip only when the condition does not apply. If the condition applies, or the prerequisite is not conditional, treat it as a normal prerequisite and ask before expanding the capture. Do not create an unrequested prerequisite unless the user approves.
|
||||
3. Follow the returned `template` and `instruction` fields. Read completed dependency files listed in `dependencies`, and apply `context` and `rules` as constraints without copying them into the artifact. If the instruction delegates creation to a specific skill or command, invoke it; otherwise write the artifact to `resolvedOutputPath`, using the instruction to choose a concrete path when it is a glob. Verify that the selected concrete output exists.
|
||||
4. After creating each artifact, re-run `openspec status --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store) and continue until every requested artifact is `done`, `skipped`, or was deliberately skipped because its own `instruction` stated a condition that did not apply. Tell the user about a deliberate conditional skip, remember it, and do not reconsider it. Dependencies are enablers, not gates: if a requested artifact is still `blocked` only because you deliberately skipped a conditional prerequisite, run `openspec instructions "<artifact-id>" --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store) despite the blocked status, then create it using step 3 only when those recorded conditional skips are its sole missing dependencies. If a requested artifact is blocked by a prerequisite the user did not ask to capture and cannot be conditionally skipped, explain that dependency and ask before expanding the capture.
|
||||
|
||||
Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status.
|
||||
|
||||
### When a change exists
|
||||
|
||||
If the user mentions a change or you detect one is relevant:
|
||||
|
||||
1. **Resolve and read existing artifacts for context**
|
||||
- Run `openspec status --change "<name>" --json`.
|
||||
- Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
|
||||
- Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
|
||||
|
||||
2. **Reference them naturally in conversation**
|
||||
- "Your design mentions using Redis, but we just realized SQLite fits better..."
|
||||
- "The proposal scopes this to premium users, but we're now thinking everyone..."
|
||||
|
||||
3. **Offer to capture when decisions are made**
|
||||
|
||||
`<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve an existing capability's full path and follow the project's established organization for new capabilities.
|
||||
|
||||
| Insight Type | Where to Capture |
|
||||
|----------------------------|-------------------------------------|
|
||||
| New requirement discovered | `specs/<capability-path>/spec.md` |
|
||||
| Requirement changed | `specs/<capability-path>/spec.md` |
|
||||
| Design decision made | `design.md` |
|
||||
| Scope changed | `proposal.md` |
|
||||
| New work identified | `tasks.md` |
|
||||
| Assumption invalidated | Relevant artifact |
|
||||
|
||||
Example offers:
|
||||
- "That's a design decision. Capture it in design.md?"
|
||||
- "This is a new requirement. Add it to specs?"
|
||||
- "This changes scope. Update the proposal?"
|
||||
|
||||
4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
|
||||
|
||||
---
|
||||
|
||||
## What You Don't Have To Do
|
||||
|
||||
- Follow a script
|
||||
- Ask the same questions every time
|
||||
- Produce a specific artifact
|
||||
- Reach a conclusion
|
||||
- Stay on topic if a tangent is valuable
|
||||
- Be brief (this is thinking time)
|
||||
|
||||
---
|
||||
|
||||
## Handling Different Entry Points
|
||||
|
||||
**User brings a vague idea:**
|
||||
```
|
||||
User: I'm thinking about adding real-time collaboration
|
||||
|
||||
You: Real-time collab is a big space. Let me think about this...
|
||||
|
||||
COLLABORATION SPECTRUM
|
||||
============================================
|
||||
|
||||
Awareness Coordination Sync
|
||||
| | |
|
||||
v v v
|
||||
+--------+ +--------+ +--------+
|
||||
|Presence| |Cursors | | CRDT |
|
||||
| "3 | | Multi | |Conflict|
|
||||
|online" | | select | | free |
|
||||
+--------+ +--------+ +--------+
|
||||
| | |
|
||||
trivial moderate complex
|
||||
|
||||
Where's your head at?
|
||||
```
|
||||
|
||||
**User brings a specific problem:**
|
||||
```
|
||||
User: The auth system is a mess
|
||||
|
||||
You: [reads codebase]
|
||||
|
||||
+---------------------------------------------+
|
||||
| CURRENT AUTH FLOW |
|
||||
+---------------------------------------------+
|
||||
|
|
||||
+-------------+-------------+
|
||||
v v v
|
||||
+---------+ +---------+ +---------+
|
||||
| Google | | GitHub | | Email |
|
||||
| OAuth | | OAuth | | Magic |
|
||||
+----+----+ +----+----+ +----+----+
|
||||
| | |
|
||||
+-------------+-------------+
|
||||
v
|
||||
+-----------+
|
||||
| Session |
|
||||
+-----+-----+
|
||||
|
|
||||
v
|
||||
+-----------+
|
||||
| Perms |
|
||||
+-----------+
|
||||
|
||||
I see three tangles. Which one's burning?
|
||||
```
|
||||
|
||||
**User is stuck mid-implementation:**
|
||||
```
|
||||
User: /openspec-explore add-auth-system
|
||||
The OAuth integration is more complex than expected
|
||||
|
||||
You: [reads change artifacts]
|
||||
|
||||
You're on task 4: "Implement OAuth flow"
|
||||
|
||||
Let me trace what's involved...
|
||||
|
||||
[draws diagram, explores options, suggests paths]
|
||||
|
||||
Want to update the design to reflect this?
|
||||
Or add a spike task to investigate?
|
||||
```
|
||||
|
||||
**User wants to compare options:**
|
||||
```
|
||||
User: Should we use Postgres or SQLite?
|
||||
|
||||
You: Generic answer is boring. What's the context?
|
||||
|
||||
User: A CLI tool that tracks local dev environments
|
||||
|
||||
You: That changes everything.
|
||||
|
||||
+-------------------------------------------------+
|
||||
| CLI TOOL DATA STORAGE |
|
||||
+-------------------------------------------------+
|
||||
|
||||
Key constraints:
|
||||
- No daemon running
|
||||
- Must work offline
|
||||
- Single user
|
||||
|
||||
SQLite Postgres
|
||||
Deployment embedded needs server
|
||||
Offline yes no
|
||||
Single file yes no
|
||||
|
||||
SQLite. Not even close.
|
||||
|
||||
Unless... is there a sync component?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ending Discovery
|
||||
|
||||
There's no required ending. Discovery might:
|
||||
|
||||
- **Flow into a proposal**: "Ready to start? I can create a change proposal."
|
||||
- **Result in artifact updates**: "Updated design.md with these decisions"
|
||||
- **Just provide clarity**: User has what they need, moves on
|
||||
- **Continue later**: "We can pick this up anytime"
|
||||
|
||||
When it feels like things are crystallizing, you might summarize:
|
||||
|
||||
```
|
||||
## What We Figured Out
|
||||
|
||||
**The problem**: [crystallized understanding]
|
||||
|
||||
**The approach**: [if one emerged]
|
||||
|
||||
**Open questions**: [if any remain]
|
||||
|
||||
**Next steps** (if ready):
|
||||
- Create a change proposal
|
||||
- Keep exploring: just keep talking
|
||||
```
|
||||
|
||||
But this summary is optional. Sometimes the thinking IS the value.
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or `openspec/config.yaml` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not.
|
||||
- **Don't fake understanding** - If something is unclear, dig deeper
|
||||
- **Don't rush** - Discovery is thinking time, not task time
|
||||
- **Don't force structure** - Let patterns emerge naturally
|
||||
- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including `openspec new change` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write.
|
||||
- **Don't manually scaffold changes** - Never create a new change directory under `openspec/changes/` by hand. Always use `openspec new change "<name>"` (with `--store <id>` when applicable) so required metadata such as `.openspec.yaml` is created before writing artifacts.
|
||||
- **Do visualize** - A good diagram is worth many paragraphs
|
||||
- **Do explore the codebase** - Ground discussions in reality
|
||||
- **Do question assumptions** - Including the user's and your own
|
||||
@@ -0,0 +1,153 @@
|
||||
---
|
||||
name: openspec-propose
|
||||
description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
|
||||
allowed-tools: Bash(openspec:*)
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.12.0"
|
||||
---
|
||||
|
||||
Propose a new change - create the change and generate all artifacts in one step.
|
||||
|
||||
**Planning boundary**: This workflow creates planning artifacts only. The user request that selected or triggered this workflow authorizes planning only, even if it asks to build or fix something. Do not edit project code. After the planning artifacts are complete, stop. Do not start implementation in the same response, even if the initial request asks for it. Wait for a new user request after the artifacts are presented; then start the apply workflow.
|
||||
|
||||
I'll create a change with the artifacts your schema defines. With the default spec-driven schema that is:
|
||||
- proposal.md (what & why)
|
||||
- `specs/<capability-path>/spec.md` (what the system must do - a delta, not the main spec)
|
||||
- design.md (how)
|
||||
- tasks.md (implementation steps)
|
||||
|
||||
`<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve an existing capability's full path and follow the project's established organization for new capabilities.
|
||||
|
||||
When the user is ready to implement, they must start the apply workflow explicitly.
|
||||
|
||||
---
|
||||
|
||||
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
|
||||
|
||||
**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Understand the request and clarify material ambiguity**
|
||||
|
||||
If no clear input is provided, ask the user (open-ended, no preset options):
|
||||
> "What change do you want to work on? Describe what you want to build or fix."
|
||||
|
||||
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
|
||||
|
||||
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
|
||||
|
||||
If the request contains ambiguity that would materially affect scope, externally observable behavior, compatibility, or acceptance criteria, ask the user before creating the change. For minor details, make a reasonable assumption and record it in the planning artifacts.
|
||||
|
||||
2. **Determine the workflow schema**
|
||||
|
||||
Use the configured default schema unless the user explicitly requests a different workflow.
|
||||
|
||||
**Use a different schema only if the user:**
|
||||
- Explicitly requests a specific schema by name → use `--schema <schema-name>`
|
||||
- Asks to "show workflows" or asks "what workflows" exist → resolve the authoritative root by running `openspec context --json` from the current working directory. If the user explicitly selected a registered store, use `openspec context --json --store "<store-id>"`. Then run `openspec schemas --json` with its working directory set to the returned `root.path` and let them choose. This preserves roots selected by a local `store:` pointer or the global `defaultStore`; when a registered store was explicitly selected, append `--store "<store-id>"` to `openspec schemas --json` as well. If context reports only `no_openspec_root`, run `openspec schemas --json` from the current working directory instead. Do not use this fallback for invalid or unavailable stores.
|
||||
|
||||
Otherwise, omit `--schema` to preserve the configured default.
|
||||
|
||||
3. **Create the change directory**
|
||||
|
||||
Choose one schema form below. If a registered store is selected, append `--store "<store-id>"` to that command and each later OpenSpec command shown below that accepts `--store`.
|
||||
|
||||
Using the configured default:
|
||||
```bash
|
||||
openspec new change "<name>"
|
||||
```
|
||||
|
||||
Using an explicitly requested schema:
|
||||
```bash
|
||||
openspec new change "<name>" --schema "<schema-name>"
|
||||
```
|
||||
This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
|
||||
|
||||
4. **Get the artifact build order**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
Parse the JSON to get:
|
||||
- `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
|
||||
- `artifacts`: list of all artifacts, each with its `status` and its `requires` edges (the artifact IDs it directly depends on)
|
||||
- `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
|
||||
|
||||
5. **Create every artifact in the required set**
|
||||
|
||||
Use a todo list to track progress through the artifacts.
|
||||
|
||||
Loop through artifacts in dependency order (artifacts with no pending dependencies first):
|
||||
|
||||
a. **For each artifact that is `ready` (dependencies satisfied)**:
|
||||
- Get instructions:
|
||||
```bash
|
||||
openspec instructions <artifact-id> --change "<name>" --json
|
||||
```
|
||||
- The instructions JSON includes:
|
||||
- `context`: Project background (constraints for you - do NOT include in output)
|
||||
- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
|
||||
- `template`: The structure to use for your output file
|
||||
- `instruction`: Schema-specific guidance for this artifact type
|
||||
- `skipped`/`warning`: present when the change declares skip_specs and this artifact must NOT be created - stop and pick another artifact
|
||||
- `resolvedOutputPath`: Resolved path or pattern to write the artifact
|
||||
- `dependencies`: Completed artifacts to read for context
|
||||
- Read any completed dependency files for context - always re-read them from disk, even if you saw them earlier in the conversation (the user may have edited them)
|
||||
- **Inspect the relevant project before drafting**: Read `context` and `rules` first, then inspect relevant implementation, nearby tests, configuration, and documentation outside `openspec/`. Keep inspection read-only and proportional to the change; reuse findings for later artifacts and inspect more only as needed.
|
||||
- Identify the target project from the request and project context; the planning home may be separate from the code. If the target is unclear, ask. For greenfield or non-code changes, inspect the available structure and relevant documents. If source is unavailable, state the limitation and ask when it materially affects the plan.
|
||||
- Ground scope, approach, and tasks in what you find. Distinguish observed behavior from assumptions and proposed additions; surface conflicts with existing specs instead of silently deciding which is correct.
|
||||
- Do this discovery now, rather than leaving generic "explore the codebase" or "make a plan" tasks for implementation. Keep any necessary follow-up investigation specific to an unresolved question.
|
||||
- If the `instruction` field delegates creation to a specific skill or command, invoke it to produce the artifact instead of writing the file yourself, then verify the artifact file exists at `resolvedOutputPath`
|
||||
- Otherwise create the artifact file using `template` as the structure and write it to `resolvedOutputPath`. If `resolvedOutputPath` is a glob, follow `instruction` to choose the concrete file path
|
||||
- Apply `context` and `rules` as constraints - but do NOT copy them into the file
|
||||
- Show brief progress: "Created <artifact-id>"
|
||||
|
||||
b. **Continue until every artifact in the required set exists (not just `apply.requires`)**
|
||||
- After creating each artifact, re-run `openspec status --change "<name>" --json`
|
||||
- The required set is `applyRequires` plus every artifact reachable from those by following the `requires` edges in `status --json` - walk them transitively (spec-driven closes over proposal, specs, design, tasks). Leave artifacts outside that set alone
|
||||
- `status` is file-existence only, so an `applyRequires` artifact reading `done` does NOT mean its dependencies exist - writing `tasks.md` early marks `tasks` done while `specs` was never written. Use each artifact's `requires` edges, not its `status`, to build the required set: a `done` artifact still lists what it depends on
|
||||
- An artifact already reading `status: "skipped"` is satisfied: the change declares `skip_specs` in `.openspec.yaml`, so its files must NOT exist. Never try to create one
|
||||
- Create every artifact in the required set that is missing, then re-check - creating one can unblock others
|
||||
- Skip one only when `status` already reports it `skipped`, or when its own `instruction` says it is conditional: run `openspec instructions <artifact-id> --change "<name>" --json` and skip only if its `instruction` field marks it optional (e.g. "create only if..."). Spec-driven's `design.md` qualifies; `specs` qualifies only via the `skipped` status above, never by your own judgment. Tell the user, and do not reconsider it
|
||||
- Dependencies are enablers, not gates: if a required artifact is still `blocked` only because you skipped a conditional dependency, write it anyway
|
||||
- Stop when every artifact in the required set is `done`, `skipped`, or was deliberately skipped
|
||||
|
||||
c. **If an artifact requires user input** (unclear context):
|
||||
- Ask the user to clarify
|
||||
- Then continue with creation
|
||||
|
||||
6. **Show final status**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
After completing all artifacts, summarize:
|
||||
- Change name and location
|
||||
- List of artifacts created with brief descriptions, plus any conditional artifact you skipped and why
|
||||
- What's ready: "All artifacts needed for implementation are ready."
|
||||
- Prompt: "The artifacts are ready for review. When you are ready, run `/openspec-apply-change` or ask me to apply this change."
|
||||
|
||||
**Artifact Creation Guidelines**
|
||||
|
||||
- Follow the `instruction` field from `openspec instructions` for each artifact type - it is the authoritative guidance, even for familiar artifact names
|
||||
- If the `instruction` field directs you to use a specific skill or command to create the artifact, invoke it instead of writing the artifact directly
|
||||
- The schema defines what each artifact should contain - follow it
|
||||
- Read dependency artifacts for context before creating new ones
|
||||
- Use `template` as the structure for your output file - fill in its sections
|
||||
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
|
||||
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
|
||||
- These guide what you write, but should never appear in the output
|
||||
|
||||
**Guardrails**
|
||||
- The request that invoked this workflow authorizes planning only. Any implementation or apply instruction in that request does not carry forward. Do NOT implement the change, start the apply workflow, or edit project code during this workflow. After presenting the artifacts, stop and wait for a new user request to start the apply workflow
|
||||
- Create every artifact the apply phase transitively depends on, not just the ids listed in `apply.requires`
|
||||
- Always read dependency artifacts before creating a new one - re-read from disk, not from conversation memory (files may have changed since you last saw them)
|
||||
- Ask about ambiguities that would materially change scope, externally observable behavior, compatibility, or acceptance criteria; for minor details, make reasonable assumptions and record them
|
||||
- If a change with that name already exists, ask if user wants to continue it or create a new one
|
||||
- Verify each artifact file exists after writing before proceeding to next
|
||||
@@ -0,0 +1,262 @@
|
||||
---
|
||||
name: openspec-sync-specs
|
||||
description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
|
||||
allowed-tools: Bash(openspec:*)
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.12.0"
|
||||
---
|
||||
|
||||
Sync delta specs from a change to main specs.
|
||||
|
||||
This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
|
||||
|
||||
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
|
||||
|
||||
`<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve the full path from each delta spec when resolving its main spec.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
If a name is provided, use it. Otherwise:
|
||||
- Infer from conversation context if the user mentioned a change
|
||||
- Auto-select if only one active change exists
|
||||
- If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
|
||||
|
||||
When prompting, show changes that have delta specs (under `specs/` directory).
|
||||
|
||||
Always announce: "Using change: <name>" and how to override (e.g., `/openspec-sync-specs <other>`).
|
||||
|
||||
2. **Resolve change context**
|
||||
|
||||
Run:
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
|
||||
The JSON includes `planningHome.root`. Main specs live under `<planningHome.root>/openspec/specs/` — use that (store-aware) root for every main-spec path below, not a hardcoded repo path. When a store is selected it points at the store, not the current repository.
|
||||
|
||||
3. **Find delta specs**
|
||||
|
||||
Use `artifactPaths.specs.existingOutputPaths` from the status JSON as the
|
||||
only source of delta spec paths. If the `specs` entry is missing or
|
||||
`existingOutputPaths` is empty, report that there are no delta specs to sync,
|
||||
do not infer them from other artifacts, and stop without requesting artifact
|
||||
instructions or writing a main spec.
|
||||
|
||||
Sync every path in `existingOutputPaths` unless the caller narrowed the set.
|
||||
A caller narrows it by naming an explicit list of complete entries from
|
||||
`existingOutputPaths` — copy those absolute values verbatim. Archive does
|
||||
this inline, and a user can too (for example, by selecting the entry ending
|
||||
in `/specs/billing/invoices/spec.md`).
|
||||
Then sync only the named paths and leave the remaining delta specs untouched:
|
||||
bulk archive excludes a delta whose implementation it could not find, and
|
||||
syncing it anyway would write a main spec the caller deliberately withheld.
|
||||
Carry that narrowed selection through step 4; never widen it back to the full
|
||||
list. If a named path is not in `existingOutputPaths`, do not sync it —
|
||||
report it and stop, rather than dropping it silently. If the named list is
|
||||
empty, report that there is nothing to sync and stop without writing a main
|
||||
spec.
|
||||
|
||||
Each delta spec file contains sections like:
|
||||
- `## ADDED Requirements` - New requirements to add
|
||||
- `## MODIFIED Requirements` - Changes to existing requirements
|
||||
- `## REMOVED Requirements` - Requirements to remove
|
||||
- `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
|
||||
|
||||
If no delta specs found, inform user and stop.
|
||||
|
||||
4. **For each delta spec, apply changes to main specs**
|
||||
|
||||
Before the first main-spec write, obtain one current specs-rule snapshot:
|
||||
- If archive invoked this workflow inline and supplied a valid snapshot from
|
||||
`openspec instructions specs --change "<name>" --json`, reuse it and do not
|
||||
fetch the same instructions again.
|
||||
- Otherwise run that command once now with the same selected-root flags.
|
||||
- If the direct lookup exits non-zero or returns invalid artifact-instruction
|
||||
JSON, report the error and stop before writing any main spec. Do not treat the
|
||||
failure as an absent rule set.
|
||||
- A valid response with omitted `rules` means no artifact rules are configured
|
||||
and the existing semantic merge continues.
|
||||
|
||||
Apply returned `rules` only to the content and form of the main specs produced
|
||||
by this merge. Artifact rules are not operation guidance and cannot change
|
||||
selected roots, delta paths, CLI checks, or workflow steps. Use their text as
|
||||
constraints without copying it verbatim into a main spec or summary.
|
||||
|
||||
For each capability delta spec path selected in step 3 — the full `existingOutputPaths` list, or the narrowed subset when a caller supplied one (these may belong to a selected store, not the repo):
|
||||
|
||||
a. **Read the delta spec** to understand the intended changes
|
||||
|
||||
b. **Read the main spec** at `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (may not exist yet)
|
||||
|
||||
c. **Apply changes intelligently**:
|
||||
|
||||
**ADDED Requirements:**
|
||||
- If requirement doesn't exist in main spec → add it
|
||||
- If requirement already exists → update it to match (treat as implicit MODIFIED)
|
||||
|
||||
**MODIFIED Requirements:**
|
||||
- Find the requirement in main spec
|
||||
- Apply the changes - this can be:
|
||||
- Adding new scenarios the main spec does not have yet
|
||||
- Modifying existing scenarios
|
||||
- Changing the requirement description
|
||||
- Preserve scenarios/content not mentioned in the delta
|
||||
|
||||
**REMOVED Requirements:**
|
||||
- Remove the entire requirement block from main spec
|
||||
- Retiring the capability. Delete the whole `spec.md` - and the directory once
|
||||
nothing else is left in it - only when ALL of these hold:
|
||||
1. removing the requirements *this run* left no requirement blocks;
|
||||
2. the rest of the spec is well-formed (it still has a `## Purpose`);
|
||||
3. the main spec was not already empty before this sync - if you removed
|
||||
nothing, change nothing;
|
||||
4. every other nonblank line in the whole file is accounted for as the
|
||||
title, Purpose, Requirements header, or a canonical requirement's
|
||||
statement, scenarios, or fenced examples;
|
||||
5. the change's `.openspec.yaml` declares `retire_capabilities: true`;
|
||||
6. the `spec.md` resolves inside the real specs root (do not follow a
|
||||
capability-directory symlink to delete an external file).
|
||||
If removing the selected requirements would leave no requirement blocks and
|
||||
any retirement condition is not satisfied, do not modify the main spec. Stop
|
||||
the sync for that capability, report the blocking condition, and tell the user
|
||||
how to resolve it. Never write or leave an empty `## Requirements` section.
|
||||
When only the marker is missing, say that too - it is the one thing the user
|
||||
can add to make the retirement go through.
|
||||
- Deleting the file also deletes its `## Purpose`; any other section blocks
|
||||
retirement. Name Purpose when you report the retirement. Include a pasteable
|
||||
`git checkout` only when the spec lived in the caller's checkout;
|
||||
otherwise give checkout-scoped recovery guidance.
|
||||
|
||||
**RENAMED Requirements:**
|
||||
- Find the FROM requirement, rename to TO
|
||||
|
||||
**`## Purpose` in the delta:**
|
||||
- The main spec already has one and it is authoritative - leave it alone
|
||||
(this is what `openspec archive` does; it warns and moves on)
|
||||
|
||||
d. **Create new main spec** if capability doesn't exist yet:
|
||||
- Create `<planningHome.root>/openspec/specs/<capability-path>/spec.md`
|
||||
- Add Purpose section: copy the delta's `## Purpose` body verbatim when it has one
|
||||
(this is what `openspec archive` does); only write a brief TBD placeholder when it does not
|
||||
- Add Requirements section with the ADDED requirements
|
||||
- Follow the **Main Spec Format Reference** below
|
||||
|
||||
5. **Validate updated main specs**
|
||||
|
||||
Run `openspec validate --specs` with the same selected-root flags used earlier.
|
||||
If validation fails, report the problems and do not claim the sync succeeded.
|
||||
|
||||
6. **Show summary**
|
||||
|
||||
After applying all changes, summarize:
|
||||
- Which capabilities were updated
|
||||
- What changes were made (requirements added/modified/removed/renamed)
|
||||
- Any new main spec left with a TBD Purpose placeholder, so it gets written
|
||||
now rather than lingering
|
||||
- Any capability retired, naming the deleted `spec.md`, its Purpose, and
|
||||
either a pasteable `git checkout` or checkout-scoped recovery guidance
|
||||
|
||||
**Delta Spec Format Reference**
|
||||
|
||||
```markdown
|
||||
## Purpose
|
||||
|
||||
Only on a delta that introduces a brand-new capability. Seeds the new main spec.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: New Feature
|
||||
The system SHALL do something new.
|
||||
|
||||
#### Scenario: Basic case
|
||||
- **WHEN** user does X
|
||||
- **THEN** system does Y
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Existing Feature
|
||||
The system SHALL keep doing the existing thing, now also handling A.
|
||||
|
||||
#### Scenario: Scenario the main spec already has
|
||||
- **WHEN** user does X
|
||||
- **THEN** system does Y
|
||||
|
||||
#### Scenario: New scenario to add
|
||||
- **WHEN** user does A
|
||||
- **THEN** system does B
|
||||
|
||||
## REMOVED Requirements
|
||||
|
||||
### Requirement: Deprecated Feature
|
||||
|
||||
## RENAMED Requirements
|
||||
|
||||
- FROM: `### Requirement: Old Name`
|
||||
- TO: `### Requirement: New Name`
|
||||
```
|
||||
|
||||
**Main Spec Format Reference**
|
||||
|
||||
Main specs are what the delta merges INTO. They must never contain delta operation headers (`## ADDED/MODIFIED/REMOVED/RENAMED Requirements`) - after syncing, every requirement lives under a single `## Requirements` section:
|
||||
|
||||
```markdown
|
||||
# <capability> Specification
|
||||
|
||||
## Purpose
|
||||
Short description of what this capability does and why it exists.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: New Feature
|
||||
The system SHALL do something new.
|
||||
|
||||
#### Scenario: Basic case
|
||||
- **WHEN** user does X
|
||||
- **THEN** system does Y
|
||||
```
|
||||
|
||||
**Key Principle: Intelligent Merging**
|
||||
|
||||
Unlike programmatic merging, you merge rather than overwrite:
|
||||
- A MODIFIED block carries the whole requirement - body plus every scenario that survives the change. `openspec validate` and `openspec archive` both reject one that drops a scenario the main spec still has.
|
||||
- Keep anything the delta does not mention, in the main spec's existing order
|
||||
- Use your judgment to merge changes sensibly
|
||||
|
||||
**Output On Success**
|
||||
|
||||
```markdown
|
||||
## Specs Synced: <change-name>
|
||||
|
||||
Updated main specs:
|
||||
|
||||
**<capability-1>**:
|
||||
- Added requirement: "New Feature"
|
||||
- Modified requirement: "Existing Feature" (added 1 scenario)
|
||||
|
||||
**<capability-2>**:
|
||||
- Created new spec file
|
||||
- Added requirement: "Another Feature"
|
||||
|
||||
Main specs are now updated. The change remains active - archive when implementation is complete.
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Read both delta and main specs before making changes
|
||||
- Preserve existing content not mentioned in delta
|
||||
- Never copy a delta file into a main spec as-is - merge its content so the main spec keeps the Main Spec Format Reference structure, with no delta operation headers
|
||||
- If something is unclear, ask for clarification
|
||||
- Show what you're changing as you go
|
||||
- The operation should be idempotent - running twice should give same result
|
||||
- Use only `artifactPaths.specs.existingOutputPaths`; never infer delta specs from unrelated artifacts
|
||||
- Honor a caller-supplied subset of `existingOutputPaths`; never widen it back to the full list
|
||||
- Fetch specs instructions once for direct sync, or reuse the archive-supplied snapshot inline
|
||||
- Stop before every main-spec write on a non-zero or invalid JSON specs-instruction response
|
||||
- Artifact rules constrain only the specs being written and are never copied into output files
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: openspec-update-change
|
||||
description: Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.
|
||||
allowed-tools: Bash(openspec:*)
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.12.0"
|
||||
---
|
||||
|
||||
Revise a change's existing planning artifacts and keep them coherent. Never edit code.
|
||||
|
||||
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
||||
|
||||
`/openspec-continue-change` is an optional workflow and may not be installed. Before suggesting it anywhere below, verify that it is available. If it is unavailable, `openspec status --change "<name>" --json` shows the next artifact and `openspec instructions "<artifact-id>" --change "<name>" --json` explains how to create it.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
If a name is provided, use it. Otherwise:
|
||||
- Infer from conversation context if the user mentioned a change
|
||||
- Auto-select if only one active change exists
|
||||
- If ambiguous, run `openspec list --json` to get available changes sorted by most recently modified, and ask the user to select one
|
||||
|
||||
When prompting, present the top 3-4 most recently modified changes as options, showing:
|
||||
- Change name
|
||||
- Schema (from `schema` field if present, otherwise "spec-driven")
|
||||
- Status (e.g., "0/5 tasks", "complete", "no tasks")
|
||||
- How recently it was modified (from `lastModified` field)
|
||||
|
||||
Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to update.
|
||||
|
||||
Always announce: "Using change: <name>" and how to override (e.g., `/openspec-update-change <other>`).
|
||||
|
||||
2. **Get the change's artifacts**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
Parse the JSON to understand current state. The response includes:
|
||||
- `schemaName`: The workflow schema being used (e.g., "spec-driven")
|
||||
- `artifacts`: Array of artifacts with their status ("done", "skipped", "ready", "blocked")
|
||||
- `isPlanningComplete`: Boolean indicating if all planning artifacts are complete. Older CLI versions expose the same value as `isComplete`.
|
||||
- `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
|
||||
|
||||
The artifact ids and paths come from the active schema - do NOT assume them, and do NOT branch on hardcoded artifact names. Custom schemas must work unchanged.
|
||||
|
||||
The files to edit are `artifactPaths.<id>.existingOutputPaths` - the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g. `specs/**/*.md`). Do NOT write to `resolvedOutputPath`: for a glob artifact it is still the glob pattern, not a real file.
|
||||
|
||||
3. **Understand the request**
|
||||
- If the user asked for a specific revision ("the design now uses X"), that is the starting edit.
|
||||
- If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts and check them against each other for contradictions, gaps, and duplication.
|
||||
|
||||
4. **Read and reconcile**
|
||||
- Read the artifact(s) the request touches and the change's other existing artifacts.
|
||||
- Apply the requested edit. Then check every other existing artifact against it - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
|
||||
- Note everything that is now inconsistent, missing, or contradictory.
|
||||
- Revise only files that already exist (`existingOutputPaths`). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to `/openspec-continue-change` to create them.
|
||||
- If the change is already coherent, say so and make no edits.
|
||||
|
||||
5. **Confirm and apply, one artifact at a time**
|
||||
- Show each proposed revision and why. Write only after the user confirms.
|
||||
- If the user rejects a revision, do not write it - leave that artifact unchanged.
|
||||
- When a substantial rewrite is needed, get that artifact's rules and template first:
|
||||
```bash
|
||||
openspec instructions "<artifact-id>" --change "<name>" --json
|
||||
```
|
||||
|
||||
6. **Point to the next step (guidance only - NEVER act on it)**
|
||||
- Artifacts still missing -> suggest `/openspec-continue-change` to create them.
|
||||
- Change already implemented (tasks checked off / already applied) -> the code may no longer match the revised plan; suggest `/openspec-apply-change` to carry the delta into code.
|
||||
- Everything done and implemented -> suggest `/openspec-archive-change`.
|
||||
|
||||
**Output**
|
||||
|
||||
After each invocation, show:
|
||||
- Which artifacts were revised (and which proposed revisions were rejected)
|
||||
- Anything deferred to `/openspec-continue-change` (not-yet-created artifacts or files)
|
||||
- Where the change stands and the recommended next command
|
||||
|
||||
**Guardrails**
|
||||
- Planning artifacts only - NEVER edit implementation code. If the revised plan implies code changes, stop and point to `/openspec-apply-change`.
|
||||
- Use the artifact ids and paths reported by `openspec status`; never branch on hardcoded artifact names.
|
||||
- Edit only the concrete files in `existingOutputPaths`; never write to a glob `resolvedOutputPath`.
|
||||
- Do not advance the build frontier: no new artifacts, no new files under glob artifacts - that is `/openspec-continue-change`'s job.
|
||||
- Confirm every edit with the user before writing.
|
||||
- If the request changes the change's *intent* rather than refining it, first verify whether the optional `/openspec-new-change` workflow is available. If it is, recommend starting fresh with `/openspec-new-change` (the "Update vs. Start Fresh" heuristic). If it is unavailable, ask for a distinct unused change name and recommend `openspec new change "<new-change-name>"` instead.
|
||||
@@ -0,0 +1,59 @@
|
||||
# AGENT.MD — Правила проекта VESTI
|
||||
|
||||
## Правило №1: ВСЕ изменения — через OpenSpec
|
||||
- **Любое изменение проекта (багфикс, фича, рефакторинг, конфиг, деплой, docs) оформляется как отдельный change** в `/opt/vesti/openspec/changes/<change-name>/`.
|
||||
- **НЕ начинать правки кода/файлов, пока change не создан и не провалидирован (`openspec validate` чисто).** Это обязательное требование (у VESTI нет бэкапа — OpenSpec фиксирует состояние и откат).
|
||||
- **Сразу после правок — обновить STATUS.md/TODO.md и сделать бэкап** (см. «Бэкап» ниже).
|
||||
- Формат change (как в образцах `tg-crawler-publisher-prototype`, `publisher-service`):
|
||||
- `.openspec.yaml` (schema: spec-driven, created: дата)
|
||||
- `proposal.md` — зачем (проблема пользователя)
|
||||
- `design.md` — как (дизайн, точные правки)
|
||||
- `tasks.md` — чеклист задач; отмечать `[x]` при выполнении
|
||||
- CLI `openspec change new` НЕ существует → change создаётся вручную (mkdir + файлы по образцу).
|
||||
- Проверка: `openspec validate <change-name>` — должно быть чисто.
|
||||
- После подтверждения пользователем change архивируется.
|
||||
- Не начинать правки кода, пока change не создан и не провалидирован.
|
||||
|
||||
## Стек и архитектура
|
||||
- Новостной агрегатор: TG-краулер → классификатор (Ollama qwen3:8b-nothink) → веб-модерация → публикация в Telegram.
|
||||
- `vesti-web` (FastAPI+Jinja2, :8400, systemd-юнит) --HTTP POST--> `publisher-service` (FastAPI, Docker-контейнер, :8410) --Bot API (SOCKS5 127.0.0.1:1080)--> Telegram @dedinit_vesti.
|
||||
- БД: SQLite `/opt/vesti/db/vesti.db` — открывать с WAL + busy_timeout (иначе `database is locked` при фоновом классификаторе).
|
||||
- Фронтенд: **без внешних CDN** (никаких unpkg/jsdelivr). Bootstrap локален: `web/static/bootstrap.min.css`, htmx запрещён. approve/reject — обычные POST-формы.
|
||||
- Markdown в шаблонах — фильтр `| markdown` (XSS-safe: escape → nl2br → sane_lists). Сырой вывод текста запрещён.
|
||||
- Даты в UI — фильтр `| dt` → `ЧЧ:ММ ДД.ММ.ГГГГ` (не ISO `[:16]`).
|
||||
- Пути бандлов: в БД `published.bundle_path` хранится **относительный** путь от `bundles/` (напр. `linux/2026-09/slug.md`), ссылка в UI `/bundle/<rel>`. Абсолютные пути запрещены (баг двойного слэша — исправлен).
|
||||
|
||||
## Секреты и .env
|
||||
- `.env` в корне (chmod 600). Переменные: `ADMIN_USER`, `ADMIN_PASSWORD` (веб-логин), `VESTI_BOT_TOKEN`, `VESTI_BOT_CHANNELS`, `TG_PROXY`, `PUBLISHER_URL`, api_id/api_hash.
|
||||
- Значения секретов НЕ показывать, НЕ сохранять, НЕ коммитить (пишется только имя переменной).
|
||||
- `.env.example` — всегда актуализировать при добавлении переменной.
|
||||
|
||||
## Правила работы
|
||||
- **Не удалять пользовательские файлы.** Перезапись/перемещение — только после явного подтверждения пользователя.
|
||||
- Дедуп постов: sha256(text) + url. Физически ничего не удаляем — только смена `status`.
|
||||
- Общение с пользователем — на русском, кратко (статусы), без «всё ок».
|
||||
- Все ресурсы проекта — в `/opt/vesti` (ничего в домашней директории).
|
||||
- Документация проекта: STATUS.md (живой), PRD.md, TODO.md, WALKTHROUGH.md — поддерживать актуальными; при закрытии сессии обновлять.
|
||||
- Ссылки и доступы к ресурсам (URL/SSH/пути) фиксировать в файлах проекта.
|
||||
|
||||
## Запуск / проверка
|
||||
```bash
|
||||
cd /opt/vesti
|
||||
sudo systemctl restart vesti-web # веб :8400 (0.0.0.0, uvicorn web.app:app)
|
||||
docker compose -f services/publisher/docker-compose.yml up -d --build # publisher :8410
|
||||
curl -s http://127.0.0.1:8410/healthz # ok, bot=dedinit_controller_bot, proxy, channels
|
||||
.venv/bin/python -m crawler.telegram_crawler --all # краулер (инкрементально)
|
||||
CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --db db/vesti.db --limit 200
|
||||
openspec validate <change-name> # валидация change
|
||||
```
|
||||
- Внешний доступ: https://vesti.nixg.ru (Caddy на VPS02: /opt/caddy/Caddyfile, reverse_proxy 10.8.0.2:8400).
|
||||
|
||||
## Направления (directions)
|
||||
linux, tech, politics, games, electronics, llm. Свой канал @dedinit — источник `own: true`, посты is_own=1, fan-out по направлениям с атрибуцией «Дед в АйТи».
|
||||
|
||||
## Бэкап (ОБЯЗАТЕЛЬНО, у VESTI нет собственного бэкапа)
|
||||
- Скрипт: `/opt/vesti/backup.sh` (по образцу `/opt/icq/backup.sh`): архивирует проект → `/opt/vesti/backups/vesti_<дата>.tar.gz`, копирует на Яндекс.Диск `/mnt/yandex-disk/backup/vesti-backups/`.
|
||||
- Хранение: локально 7 дней, на ЯД 30 дней (ротация в скрипте).
|
||||
- Запуск: root cron `45 2 * * *` (как у icq). ЯД монтируется автоматически (fstab davfs + @reboot).
|
||||
- **После ЛЮБЫХ изменений проекта** (или по требованию) — запустить `sudo /opt/vesti/backup.sh` и проверить, что архив появился в `/mnt/yandex-disk/backup/vesti-backups/`.
|
||||
- Проверка: `ls -lh /opt/vesti/backups/ | tail -3` и `ls -lh /mnt/yandex-disk/backup/vesti-backups/ | tail -3`.
|
||||
@@ -0,0 +1,196 @@
|
||||
# PRD — VESTI: новостной агрегатор с веб-интерфейсом
|
||||
|
||||
> **Правило проекта (пользователь, 2026-09-09): все задачи выполняются через OpenSpec** —
|
||||
> каждый элемент/изменение оформляется как change (proposal, design, specs, tasks),
|
||||
> проверяется `openspec validate`. Изменения фиксировать в STATUS.md / TODO.md /
|
||||
> WALKTHROUGH.md / PRD.md.
|
||||
|
||||
- Статус: v0.2 (2026-09-10) — прототип работает, реальная публикация включена
|
||||
- Расположение: /opt/vesti
|
||||
- Эволюция: /opt/news (наследие — код, схема, sources.yaml, Telethon-сессия)
|
||||
- Репозитории: vesti-* (источник истины gitverse.ru, зеркало gitea bigbox:3000)
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Построить собственный новостной конвейер «СМИ»: собирать новости из многих
|
||||
источников (RSS, почтовые рассылки, сайты, Telegram, WeChat, X), дедуплицировать
|
||||
и объединять в одну статью со ссылками на все источники (юридическая защита),
|
||||
проверять факты, дополнять мультимедиа, категоризировать по направлениям,
|
||||
и формировать:
|
||||
|
||||
1. **Дайджесты по направлениям** — для еженедельных видео (учитывают
|
||||
популярность тем, реакции, мои оценки интересности).
|
||||
2. **Ленты новостных ботов** — Telegram, VK, fediverse по направлениям.
|
||||
|
||||
Всё управление — через веб-сайт с авторизацией: списки внешних новостей
|
||||
с метриками популярности, списки опубликованных со своими метриками,
|
||||
редактирование прямо в интерфейсе.
|
||||
|
||||
Собственный контент (канал @dedinit «Дед в АйТи» ~1092 поста) — отдельный
|
||||
класс: is_own=1/is_own_canonical=1, приоритетная классификация (critical без
|
||||
LLM при словарном попадании), fan-out по направлениям.
|
||||
|
||||
## 2. Направления (категории)
|
||||
|
||||
Технологии, Политика, Игры, Электроника, БЯМ (большие языковые модели), Линукс.
|
||||
|
||||
## 3. Языки ботов
|
||||
|
||||
Отдельные боты под комбинации направление×язык: ru, en, zh, ko.
|
||||
Именование: @dedinit_vesti_<направление>_<язык>_bot.
|
||||
Прототип (текущий): **бот-контроллер @dedinit_controller_bot публикует в канал
|
||||
@dedinit_vesti** (один бот → много каналов через добавление админом; каналы из
|
||||
VESTI_BOT_CHANNELS). Отдельные боты направлений — фаза 2.
|
||||
|
||||
## 4. Принципы
|
||||
|
||||
- **Каноническая БД — PostgreSQL** (решение D1; для прототипа допустим SQLite,
|
||||
миграция на Postgres на фазе 2).
|
||||
- **Банк статей — markdown-бандлы с frontmatter** + мультимедиа рядом:
|
||||
`bundles/<направление>/<YYYY-MM>/<slug>.md` + `media/<slug>/`.
|
||||
- **Всё локально** на bigbox; массовая классификация — Ollama qwen3:8b-nothink;
|
||||
облачный LLM (deepseek, отдельный API/ключ — учёт затрат проекта) — факт-чек,
|
||||
слияние, дайджесты (решение E2).
|
||||
- **n8n — оркестратор** для RSS/email/сайтов (отдельный контейнер, общий для
|
||||
инфраструктуры), НЕ для Telegram (Bot API не читает чужие каналы — только
|
||||
MTProto/Telethon).
|
||||
- **Публикация ботов — режим «черновик на подтверждение»** (решение C2-b):
|
||||
сначала подтверждение человеком, потом смягчение.
|
||||
- **Переиспользуем существующий стек**: Qdrant (docker-qdrant-1, :6333),
|
||||
Redis (:6379), Ollama (:11434), telegram-tunnel (SOCKS5 :1080 → VPS01),
|
||||
Garage S3 (медиа, фаза 2), GoToSocial (fediverse-бот, фаза 2),
|
||||
gitea (:3000, зеркало) / gitverse.ru (истина).
|
||||
- Тихие watchdogs: молчат, пока всё живо (политика пользователя).
|
||||
|
||||
## 5. Архитектура (текущая, 2026-09-10)
|
||||
|
||||
```
|
||||
sources.yaml (реестр, git)
|
||||
│
|
||||
▼
|
||||
telegram_crawler.py (cron каждые 30 мин, Telethon MTProto, SOCKS5 :1080)
|
||||
│ инкрементально после last_post_id; метрики views/reactions; --all / --source
|
||||
▼
|
||||
backfill_dedinit.py (разовый бэкфилл своего канала ~1092 постов, is_own=1, медиа)
|
||||
│
|
||||
▼
|
||||
SQLite vesti.db (raw-посты, tg_state, runs, классификации) ──► Postgres (фаза 2)
|
||||
│
|
||||
▼
|
||||
classifier.py (Ollama qwen3:8b-nothink + словарный фильтр)
|
||||
│ направление, relevance, interest 1-5, summary; мультинаправления
|
||||
▼
|
||||
vesti-web (FastAPI + Bootstrap 5.3 + Jinja2 + HTMX, 127.0.0.1:8400)
|
||||
│ авторизация; кандидаты → подтвердить/отклонить; «Свои»; метрики
|
||||
▼ (подтверждённые)
|
||||
publisher-service (FastAPI-микросервис, Docker vesti-publisher, :8410)
|
||||
│ POST /api/v1/publish → Bot API через SOCKS5 :1080 (host.docker.internal)
|
||||
│ медиа: маунт ../../media/media:/srv/publisher/media:ro (веб шлёт media/<file>)
|
||||
▼
|
||||
Telegram @dedinit_vesti (бот-контроллер @dedinit_controller_bot; каналы из VESTI_BOT_CHANNELS)
|
||||
│
|
||||
▼
|
||||
bundles/<направление>/<YYYY-MM>/<slug>.md (markdown + frontmatter) + media/
|
||||
```
|
||||
|
||||
Сервисы/порты (актуально):
|
||||
| Сервис | Порт | Способ запуска |
|
||||
|---|---|---|
|
||||
| vesti-web | 127.0.0.1:8400 | systemd-юнит vesti-web.service (установлен; daemon-reload на bigbox зависает — внешняя проблема, подхватится при перезагрузке). Пароль: VESTI_WEB_PASSWORD or ADMIN_PASSWORD из .env |
|
||||
| publisher-service | 127.0.0.1:8410 | Docker (docker-compose, restart policy), healthz |
|
||||
| telegram-tunnel | SOCKS5 127.0.0.1:1080 | systemd telegram-tunnel.service |
|
||||
| Ollama | 127.0.0.1:11434 | существующий (qwen3:8b-nothink) |
|
||||
|
||||
Cron (Hermes cron, no_agent, тихие):
|
||||
- vesti-crawler-all-sources (`*/30 * * * *`) — краулер по всем включённым источникам,
|
||||
лог /opt/vesti/logs/crawler-cron.log; молчит при успехе.
|
||||
- vesti-watchdog (`*/15 * * * *`) — publisher :8410 healthz, веб :8400, SOCKS5 :1080,
|
||||
контейнер, БД; шумит в Telegram только при проблеме.
|
||||
|
||||
Фаза 2+: n8n (RSS/email/сайты), Postgres, S3 (Garage), семантический dedup
|
||||
(Qdrant bge-m3), факт-чек облаком, дайджесты для видео, боты VK/fediverse,
|
||||
WeChat/X.
|
||||
|
||||
## 6. Метрики популярности
|
||||
|
||||
- Внешние TG-посты: views + reactions (через Telethon при краулинге).
|
||||
- Свои посты: views через Bot API (GET /api/v1/views/{channel}/{mid}).
|
||||
- Сайты/RSS (фаза 2): только свои переходы (UTM-метки в ссылках).
|
||||
- Интерес темы: кол-во реакций/просмотров → показатель хайповости;
|
||||
залайканные комментарии — сигнал (фаза 2).
|
||||
|
||||
## 7. Дайджесты (G1, G3)
|
||||
|
||||
Отдельная сущность по направлению: по каждой теме — суть, источники, оценка
|
||||
популярности. Для еженедельного видео: 5–10 новостных поводов в выпуске,
|
||||
выходные. Оценки интересности — в вебе (1–5 + флаг «в дайджест»).
|
||||
|
||||
## 8. Технологический стек
|
||||
|
||||
| Слой | Технология | Статус |
|
||||
|---|---|---|
|
||||
| Язык | Python 3.12, venv /opt/vesti/.venv | новый |
|
||||
| Telegram-краулер | Telethon (MTProto), SOCKS5 :1080, сессия /opt/vesti/telegram/ | новый (переисп. код /opt/news) |
|
||||
| Бот-публикатор | publisher-service: httpx[socks] → Bot API (не python-telegram-bot) | новый |
|
||||
| Каноническая БД | SQLite (прототип) → PostgreSQL (фаза 2) | новый |
|
||||
| LLM-классификация | Ollama qwen3:8b-nothink (:11434) | существующий |
|
||||
| Облачный LLM | deepseek (отдельный API/ключ) | фаза 2 |
|
||||
| Векторный поиск | Qdrant :6333 (коллекция news), bge-m3 | существующий |
|
||||
| Веб | FastAPI + Bootstrap 5.3 + Jinja2 + HTMX | новый, :8400 |
|
||||
| Оркестратор | n8n (отдельный контейнер, :5678), общий | фаза 2 |
|
||||
| Медиа | локально /opt/vesti/media/media/ → Garage S3 | фаза 2 |
|
||||
| Git | gitverse.ru (истина), gitea bigbox :3000 (зеркало) | существующий |
|
||||
| Доставка | Telegram-боты, потом VK/fediverse | новый |
|
||||
|
||||
## 9. OpenSpec
|
||||
|
||||
Проект ведётся по OpenSpec: /opt/vesti/openspec/.
|
||||
Active changes:
|
||||
- `tg-crawler-publisher-prototype` (прототип конвейера; реализован),
|
||||
- `own-content-hub` (свой канал @dedinit, fan-out; код готов, бэкфилл идёт,
|
||||
интеграционная проверка после него),
|
||||
- `publisher-service` (микросервис публикации; создан 2026-09-09, validate чист,
|
||||
реальная публикация работает).
|
||||
Файлы: proposal.md, design.md, specs/*/spec.md, tasks.md.
|
||||
|
||||
## 10. Прототип — текущее состояние
|
||||
|
||||
Вертикаль Линукс (ru) + свой контент:
|
||||
1. TG-краулер 8 публичных каналов (Telethon, SOCKS5, инкрементальный, метрики;
|
||||
форварды из своих каналов отфильтровываются, чужие — с fwd-полями без медиа).
|
||||
2. Классификатор (словари + локальный qwen3:8b-nothink; мультинаправления;
|
||||
свои посты → critical без LLM при словарном попадании).
|
||||
3. Реальная публикация: бот-контроллер @dedinit_controller_bot → @dedinit_vesti
|
||||
(проверено: message_id 2–4, approve через веб работает).
|
||||
4. Веб (127.0.0.1:8400): кандидаты → подтвердить/отклонить, «Свои», метрики,
|
||||
опубликованные.
|
||||
5. Банк статей markdown с frontmatter (bundles/, origin:own для своих).
|
||||
6. Бэкфилл канала @dedinit (~1092 постов is_own=1, медиа) — скрипт
|
||||
crawler/backfill_dedinit.py, запущен 2026-09-10.
|
||||
|
||||
Источники: linuxklub, linuxos_tg, dotfiles_linux, linux_education, LinuxMastery,
|
||||
linuxcamp_tg, gitgate, krxnotes + канал dedinit (own).
|
||||
|
||||
## 11. Критерии готовности прототипа (DoD)
|
||||
|
||||
1. Краулер собирает посты из линукс-каналов с метриками, без дублей (проверка: count по sha256 = count id). — ДОСТИГНУТО
|
||||
2. Классификатор корректно относит ≥90% контрольных постов к направлению. — В ПРОВЕРКЕ (после бэкфилла — прогон по 543+ неклассифицированным)
|
||||
3. Бот публикует карточку-пост только после подтверждения в вебе. — ДОСТИГНУТО
|
||||
4. Веб доступен локально, с авторизацией; кандидаты/опубликованные/метрики видны. — ДОСТИГНУТО
|
||||
5. Бандл создан в bundles/linux/YYYY-MM/<slug>.md с frontmatter и источниками. — ДОСТИГНУТО
|
||||
6. Watchdog молчит 3 дня подряд при здоровой системе. — В ПРОВЕРКЕ (cron создан 2026-09-10)
|
||||
7. Смягчение публикации (C2: b → a/в) — отдельное решение после прототипа.
|
||||
|
||||
## 12. Открытые вопросы / следующие фазы
|
||||
|
||||
- Миграция SQLite → Postgres (когда поток статей вырастет).
|
||||
- Облачный LLM API для факт-чека/слияния/дайджестов — отдельный ключ/учёт затрат.
|
||||
- n8n-воркфлоу для RSS/email/сайтов (общий контейнер).
|
||||
- Боты VK, fediverse (GoToSocial) — фаза 2; отдельные боты направлений
|
||||
(@dedinit_vesti_<dir>_<lang>_bot) — фаза 2.
|
||||
- WeChat (закрытый, сложный) и X (платный API) — исследование отдельно.
|
||||
- Автопубликация/смягчение условий (после прототипа).
|
||||
- Дайджесты: сущность, связь с видео-сценарием.
|
||||
- git-репозиторий /opt/vesti (gitverse истина, gitea зеркало) — инициализировать.
|
||||
- openspec archive publisher-service / tg-crawler-publisher-prototype после
|
||||
подтверждения и интеграционных проверок.
|
||||
@@ -0,0 +1,118 @@
|
||||
# VESTI — Статус
|
||||
|
||||
Обновлено: 2026-09-13 (publisher снова на Docker; systemd1 ожил)
|
||||
<!--
|
||||
История обновлений:
|
||||
2026-09-13 — publisher: Docker-контейнер (основной способ); user-юнит disabled (костыль убран)
|
||||
2026-09-12 — publisher → systemd user-юнит (костыль, пока сломан systemd1)
|
||||
2026-09-11 — веб-интерфейс: 4 openspec change (CDN/htmx, markdown, даты, фильтр без CDN)
|
||||
-->
|
||||
|
||||
## Текущее состояние
|
||||
- Базовый конвейер (прототип) работает: краулер (8 источников, инкрементальный, метрики), классификатор (Ollama qwen3:8b-nothink + словари), банк статей (bundles + origin:own), веб :8400 (кандидаты/approve/reject/опубликованные/метрики).
|
||||
- **Бэкфилл @dedinit ЗАВЕРШЁН** (2026-09-10): crawler/backfill_dedinit.py, fetched=1040, max_post_id=1092; в БД 846 постов is_own=1, медиа в media/media/ (исторический баг пути: БД media/<file>, файл media/media/<file>; с 2026-09-12 краулер качает в media/<file>, для старых — fallback в make_card). Скрипт оставлен для повторного дозаполнения.
|
||||
- **РЕАЛЬНАЯ ПУБЛИКАЦИЯ РАБОТАЕТ**: бот-контроллер @dedinit_controller_bot (id 7765665742) → @dedinit_vesti. Токен в .env. Проверено: тестовые посты (message_id 2–4).
|
||||
- **publisher-service**: **Docker-контейнер** `vesti-publisher` (docker compose -f services/publisher/docker-compose.yml, 127.0.0.1:8410, restart=unless-stopped, healthy). Compose: env из /.env, TG_PROXY=socks5://host.docker.internal:1080, маунт ../../media/media:/srv/publisher/media:ro. Старый user-юнит `vesti-publisher.service` (~/.config/systemd/user/) — **disabled, не используется** (костыль на время сломанного systemd1, порт 8410 конфликтовал бы).
|
||||
- **Веб :8400**: systemd-юнит `/etc/systemd/system/vesti-web.service` (**enabled**, автостарт), uvicorn web.app:app на 0.0.0.0:8400, пароль из .env (ADMIN_PASSWORD). Доступен снаружи: https://vesti.nixg.ru.
|
||||
- **Cron (Hermes, no_agent, тихие)**: vesti-crawler-all-sources (`*/30`), vesti-watchdog (`*/15`, Telegram при проблемах).
|
||||
- **Бэкап**: `/opt/vesti/backup.sh` (по образцу icq/netbox) → `backups/vesti_<дата>.tar.gz` + Яндекс.Диск `/mnt/yandex-disk/backup/vesti-backups/`. Root cron `45 2 * * *` (лог /var/log/vesti-backup.log). Локально 7 дней, на ЯД 30 дней.
|
||||
|
||||
## Архитектура (реальная)
|
||||
```
|
||||
vesti-web (:8400) ──HTTP POST──▶ publisher-service (:8410) ──Bot API (SOCKS5 127.0.0.1:1080)──▶ Telegram
|
||||
approve (человек) VESTI_BOT_TOKEN, VESTI_BOT_CHANNELS @dedinit_vesti (+ другие)
|
||||
```
|
||||
- Бот-контроллер @dedinit_controller_bot публикует во все каналы, в которые добавлен администратором.
|
||||
- Каналы из конфига: VESTI_BOT_CHANNELS (сейчас @dedinit_vesti, потом несколько).
|
||||
- publisher-service: POST /api/v1/publish (card {text, media?, direction, lang}, channels?), GET /healthz, GET /api/v1/views/{channel}/{mid}.
|
||||
|
||||
## Сделано (сессия web-ui 2026-09-11)
|
||||
- [x] **Внешний доступ через Caddy**: https://vesti.nixg.ru (VPS02, /opt/caddy/Caddyfile, reverse_proxy 10.8.0.2:8400); юнит веба переведён на 0.0.0.0:8400; LE-серт выпущен
|
||||
- [x] **4 OpenSpec change** (по одному на замечание пользователя), все валидны (`openspec validate`):
|
||||
- `deexternalize-web-assets` — удалены unpkg (htmx 1.9.12) и jsdelivr (bootstrap 5.3.3); bootstrap локализован в web/static/bootstrap.min.css; approve/reject → обычные POST-формы. 0 внешних доменов в шаблонах.
|
||||
- `web-render-markdown` — Python-Markdown (>=3.6) + Jinja2-фильтр `markdown` (XSS-safe: escape→nl2br→sane_lists); тексты кандидатов/опубликованных рендерятся
|
||||
- `web-format-datetime` — фильтр `dt` → `ЧЧ:ММ ДД.ММ.ГГГГ` (candidates/published/metrics), ISO `[:16]` убран
|
||||
- `web-list-filter-no-js` — фильтрация чистыми GET-формами без JS/CDN (кнопка «Применить»); ожидания unpkg нет
|
||||
- [x] **Баг бандлов исправлен**: `create_bundle` возвращал абсолютный путь → в published.bundle_path лежал `/opt/vesti/bundles/...` → ссылки `/bundle//opt/...` (двойной слэш). Теперь относительный путь от bundles/ (`linux/2026-09/slug.md`), 4 строки БД обновлены, роут `/bundle/{path}` работает (HTTP 200)
|
||||
- [x] **AGENT.MD** — правила проекта (все изменения через OpenSpec и т.д.)
|
||||
|
||||
## Сделано (сессия publisher-service)
|
||||
- [x] OpenSpec change `publisher-service` — создан и ВАЛИДЕН (proposal, design, spec tg-publisher-service, tasks); `openspec validate` чисто
|
||||
- [x] services/publisher/ — FastAPI-микросервис: app/{main,config,telegram,channels}.py, requirements.txt, Dockerfile, docker-compose.yml, .env.example
|
||||
- [x] httpx[socks] установлен в venv (для SOCKS5-прокси к Bot API)
|
||||
- [x] Токен записан в .env (VESTI_BOT_TOKEN), чтение починил (load_dotenv override + путь BASE)
|
||||
- [x] Сервис запущен (venv, 127.0.0.1:8410); healthz: bot=dedinit_controller_bot, proxy=socks5://127.0.0.1:1080, channels=[@dedinit_vesti]
|
||||
- [x] **Реальная публикация**: POST /api/v1/publish → ok, message_id=2 в @dedinit_vesti (проверено)
|
||||
- [x] web/app.py: approve → HTTP-клиент web/publisher_client.py (publish + views), импорт publisher.bot убран
|
||||
- [x] .env.example обновлён (VESTI_BOT_CHANNELS, TG_PROXY, PUBLISHER_URL)
|
||||
- [x] **Docker publisher**: compose (пути ../../, extra_hosts host.docker.internal, TG_PROXY override, load_dotenv override=False), контейнер Up (healthy), healthz: bot/proxy/channels — ок (2026-09-09)
|
||||
- [x] **Реальный approve через веб** (сквозной: веб → HTTP → publisher(Docker) → Telegram): посты 136, 137 → @dedinit_vesti, tg_message_id 3 и 4, бандлы и статусы записаны
|
||||
- [x] **Веб-баги**: 500 на /candidates (raise RedirectResponse → HTTPException 303) и tg_message_id=0 для внешних (ключ результата — канал, не направление) — исправлены
|
||||
|
||||
## Сделано (сессия rich-repost-card 2026-09-12)
|
||||
- [x] **OpenSpec change `rich-repost-card`** — создан и ВАЛИДЕН (`openspec validate` чисто): proposal/design/tasks/specs/tg-publisher
|
||||
- [x] **Формат публикации — «богатый репост»** (publisher/card.py): карточка = [комментарий модератора] + полный текст поста + ссылка на оригинал. Служебка (📁📰👁) убрана. Текст plain (не HTML) — сырые <,>,& не искажаются
|
||||
- [x] **Предпросмотр ссылки отключён** (services/publisher/app/telegram.py): sendMessage → link_preview_options={is_disabled:true}; канал больше не выглядит «агрегатором ссылок»
|
||||
- [x] **Медиа правится**: main.py — если media_path существует: медиа первым (caption = первые 1000 симв., лимит 1024), полный текст отдельным сообщением; без медиа — один текст
|
||||
- [x] **Вебе добавлено поле «Комментарий»** (web/app.py + candidates.html): при approve комментарий встаёт первым блоком в публикацию
|
||||
- [x] **Фикс бага медиа-пути краулера** (crawler/telegram_crawler.py + backfill_dedinit.py): файл скачивался в media/media/<file>, а media_path в БД = media/<file> → publisher не находил файл, медиа молча не публиковалось. Теперь скачивание в MEDIA_DIR/<basename> (= media/<file>). Для старых постов — fallback в make_card (пробует media/ и media/media/)
|
||||
- [x] telegram.py: добавлен delete_message (для отмены/чистки тестовых)
|
||||
- [x] **Проверено на реальном канале**: publish ушёл в @dedinit_vesti (message_id 6), текст с <b>& доставлен как есть, без превью; тестовые сообщения удалены (delete_message ok). Канал чист
|
||||
- [x] **publisher временно работает как локальный uvicorn** (127.0.0.1:8410, PID 807769) — Docker недоступен из-за зависшего systemd1 на хосте (внешняя проблема, не vesti)
|
||||
|
||||
## Сделано ранее (own-content-hub)
|
||||
- [x] Миграция БД (migrate_own.py): is_own, is_own_canonical, sources.own, published.distributed_dirs
|
||||
- [x] sources.yaml: +dedinit (own: true), синк
|
||||
- [x] Краулер own-семантика; классификатор critical + мультинаправления; карточка с атрибуцией; веб «Свои»/бейдж/чекбоксы; бандлы origin:own
|
||||
- [x] Тест e2e (dry-run): approve с dirs [linux,ai] → /published с distributed_dirs
|
||||
|
||||
## В работе / Следующие шаги
|
||||
- [x] Бэкфилл своего канала @dedinit (задача 2.3) — **ЗАВЕРШЁН** (2026-09-10): fetched=1040, max_post_id=1092, 846 постов is_own=1 в БД
|
||||
- [x] publisher: медиа при Docker-запуске — **исправлено**: compose маунтит ../../media/media:/srv/publisher/media:ro
|
||||
- [x] systemd vesti-web.service + cron per-source + тихий watchdog — **юнит установлен** (подхватится при перезагрузке); **cron**: vesti-crawler-all-sources (`*/30`, тихий) + vesti-watchdog (`*/15`, Telegram при проблемах)
|
||||
- [x] Классификатор по неклассифицированным — **запущен** (2026-09-10, 870 постов, фон; статус в /tmp/vesti-classify.log)
|
||||
- [ ] Проверить результат классификации (в БД: direction заполнены) и выборочно качество на своих постах
|
||||
- [ ] **rich-repost-card в проде**: после оживления systemd1 на хосте пересобрать Docker-контейнер publisher (docker compose -f services/publisher/docker-compose.yml up -d --build), перезапустить веб (подхватит шаблон + comment), проверить approve поста с медиа (send_photo/send_video)
|
||||
- [ ] **Закрыть OpenSpec change rich-repost-card** (статус APPLIED после подтверждения), архивировать
|
||||
- [ ] git-репозитории (gitverse истина, gitea зеркало) — /opt/vesti ещё НЕ git-репо
|
||||
- [ ] openspec archive web-изменений (deexternalize-web-assets, web-render-markdown, web-format-datetime, web-list-filter-no-js) и publisher-service / tg-crawler-publisher-prototype (после подтверждения)
|
||||
|
||||
## Как запустить / проверить
|
||||
```bash
|
||||
cd /opt/vesti
|
||||
# publisher-service (ОСНОВНОЙ способ — Docker):
|
||||
docker compose -f services/publisher/docker-compose.yml up -d --build # контейнер vesti-publisher, :8410
|
||||
curl -s http://127.0.0.1:8410/healthz # ok, bot=dedinit_controller_bot, proxy=socks5://host.docker.internal:1080, channels
|
||||
docker logs -f vesti-publisher # логи
|
||||
curl -s -X POST http://127.0.0.1:8410/api/v1/publish \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"card":{"text":"<b>Тест</b>","direction":"linux","lang":"ru"}}'
|
||||
# (старый user-юнит vesti-publisher.service disabled — не использовать, порт занят)
|
||||
# веб (пароль из .env: VESTI_WEB_PASSWORD or ADMIN_PASSWORD):
|
||||
# systemd-юнит: /etc/systemd/system/vesti-web.service (после daemon-reload)
|
||||
# вручную: set -a; . ./.env; set +a; .venv/bin/uvicorn web.app:app --host 127.0.0.1 --port 8400
|
||||
# краулер/классификатор:
|
||||
.venv/bin/python -m crawler.telegram_crawler --all # инкрементально все источники
|
||||
.venv/bin/python -m crawler.backfill_dedinit # бэкфилл своего канала (разовый)
|
||||
CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --db db/vesti.db --limit 200
|
||||
```
|
||||
|
||||
## Ключевые артефакты
|
||||
- /opt/vesti/AGENT.MD — правила проекта (обязательно: все изменения через OpenSpec)
|
||||
- /opt/vesti/openspec/changes/{deexternalize-web-assets, web-render-markdown, web-format-datetime, web-list-filter-no-js}/ — 4 change веб-интерфейса (валидны, задачи [x])
|
||||
- /opt/vesti/openspec/changes/rich-repost-card/ — change формата публикации (proposal/design/tasks/specs/tg-publisher, валиден)
|
||||
- /opt/vesti/services/publisher/ — микросервис (app/, Dockerfile, compose, README)
|
||||
- /opt/vesti/web/publisher_client.py — HTTP-клиент веба к микросервису
|
||||
- /opt/vesti/openspec/changes/publisher-service/ — OpenSpec change (proposal/design/spec/tasks)
|
||||
- publisher/bot.py — старое (логика перенесена в services/publisher/app/telegram.py)
|
||||
- publisher/card.py — карточка (осталась)
|
||||
- db/vesti.db, sources/sources.yaml, crawler/, classifier/, web/, bundles/
|
||||
|
||||
## Открытые вопросы
|
||||
- ~~Медиа при Docker-запуске~~ — решено: compose маунтит ../../media/media:/srv/publisher/media (веб шлёт media/<file>)
|
||||
- **publisher в проде = Docker** (2026-09-13): systemd1 (D-Bus org.freedesktop.systemd1) после перезагрузки ожил, контейнер vesti-publisher (compose, restart=unless-stopped) работает healthy. User-юнит vesti-publisher.service выключен (disabled) и не используется. Если снова сломается systemd1 — вернуть юнит: systemctl --user enable --now vesti-publisher.service.
|
||||
- Fan-out: сейчас все каналы из VESTI_BOT_CHANNELS (один). В будущем — направления→каналы (маппинг).
|
||||
- ~~Бэкфилл канала (задача 2.3)~~ — ЗАВЕРШЁН (2026-09-10): 1040 постов, 846 в БД is_own=1
|
||||
- git-репозиторий /opt/vesti — инициализировать?
|
||||
- systemd daemon-reload на bigbox зависает (внешняя проблема, не vesti) — юнит подхватится при перезагрузке
|
||||
- Качество классификации своих постов (846, словари vs LLM) — проверить выборочно
|
||||
@@ -0,0 +1,56 @@
|
||||
# TODO — VESTI
|
||||
|
||||
Формат: | дата | задача | статус | закрыта в |
|
||||
|---|---|---|---|
|
||||
| 2026-09-08 | Инициализировать OpenSpec-проект /opt/vesti, change tg-crawler-publisher-prototype | ✅ закрыта | сессия старта |
|
||||
| 2026-09-08 | Артефакты change: proposal, design, specs (5), tasks | ✅ закрыта | сессия старта |
|
||||
| 2026-09-08 | PRD.md — требования, архитектура, стек, DoD | ✅ закрыта | сессия старта |
|
||||
| 2026-09-08 | Каркас проекта: каталоги, venv, requirements.txt | ✅ закрыта | сессия старта |
|
||||
| 2026-09-08 | Конфиг+БД: config.py, schema.sql (6 таблиц), db.py | ✅ закрыта | сессия старта |
|
||||
| 2026-09-08 | sources.yaml (8 линукс-каналов), sources.py (синк+запуски) | ✅ закрыта | сессия старта |
|
||||
| 2026-09-08 | crawler/telegram_crawler.py + auth_telegram.py | ✅ закрыта | сессия старта |
|
||||
| 2026-09-08 | Починить telegram-tunnel (SSH-форвард :1080 до VPS01) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | Авторизовать Telethon-сессию (@kpa39l, 2FA) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | Краулер: собрать первые посты (137 с 8 каналов) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | Форварды: дедуп по fwd_from (свой источник → пропуск, чужой → сирота без медиа) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | Классификатор: keywords.py + classify.py (Ollama qwen3:8b-nothink, /v1, таймаут) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | Бот-публикатор: card.py + bot.py (Bot API, dry-run) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | Веб: FastAPI+Bootstrap 5.3+Jinja2+HTMX, :8400, approve/reject+бандл | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | Банк статей: markdown-бандлы с frontmatter + media | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | **own-content-hub**: спроектировать change | ✅ закрыта | 2026-09-08 (openspec validate чист) |
|
||||
| 2026-09-08 | **own-content-hub**: миграция БД (migrate_own.py) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | **own-content-hub**: sources.yaml +dedinit (own:true) | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | **own-content-hub**: краулер own-семантика | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | **own-content-hub**: классификатор critical + мультинаправления | ✅ закрыта | 2026-09-08 (test linux+ai) |
|
||||
| 2026-09-08 | **own-content-hub**: публикатор publish_multi + get_views_multi + карточка с атрибуцией | ✅ закрыта | 2026-09-08 (dry-run 2 направления) |
|
||||
| 2026-09-08 | **own-content-hub**: веб «Свои», чекбоксы направлений, distributed_dirs | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | **own-content-hub**: бандлы origin:own + source_url + author | ✅ закрыта | 2026-09-08 |
|
||||
| 2026-09-08 | **own-content-hub** 2.3: бэкфилл @dedinit (~1092 постов is_own=1) | ✅ закрыта | 2026-09-10 (backfill_dedinit.py, fetched=1040, max_post_id=1092, 846 в БД) |
|
||||
| 2026-09-08 | **own-content-hub**: повторный approve-тест после async form | ✅ закрыта | 2026-09-09 (реальный approve 136,137 через publisher-service) |
|
||||
| 2026-09-08 | VESTI_BOT_TOKEN (реальная публикация) | ✅ закрыта | 2026-09-09 (тестовый пост message_id=2) |
|
||||
| 2026-09-09 | **publisher-service**: OpenSpec change (proposal/design/spec/tasks), validate | ✅ закрыта | 2026-09-09 |
|
||||
| 2026-09-09 | **publisher-service**: FastAPI-микросервис services/publisher/ (publish/healthz/views) | ✅ закрыта | 2026-09-09 (healthz ok, реальный publish message_id=2) |
|
||||
| 2026-09-09 | **publisher-service**: web переключён на HTTP-клиент (publisher_client.py) | ✅ закрыта | 2026-09-09 |
|
||||
| 2026-09-09 | **publisher-service**: Docker (compose up) + healthcheck | ✅ закрыта | 2026-09-09 (vesti-publisher Up healthy, healthz: bot/proxy/channels ok) |
|
||||
| 2026-09-09 | Реальный approve через веб (сквозной путь с микросервисом) | ✅ закрыта | 2026-09-09 (посты 136,137 → @dedinit_vesti, tg_message_id 3,4) |
|
||||
| 2026-09-09 | Web-фиксы: 500 /candidates (raise RedirectResponse) + tg_message_id для внешних | ✅ закрыта | 2026-09-09 |
|
||||
| 2026-09-10 | **Медиа в Docker**: publisher маунт ../../media/media:/srv/publisher/media | ✅ закрыта | 2026-09-10 (контейнер пересобран, healthy) |
|
||||
| 2026-09-10 | Веб :8400 перезапущен (после падения); юнит vesti-web.service | ✅ закрыта | 2026-09-10 (запущен; юнит подхватится при перезагрузке — daemon-reload зависает на bigbox) |
|
||||
| 2026-09-10 | Cron per-source + тихий watchdog | ✅ закрыта | 2026-09-10 (crawler `*/30`, watchdog `*/15`; no_agent, тихие) |
|
||||
| 2026-09-10 | Классификатор по неклассифицированным (870 постов) | ✅ закрыта | 2026-09-10 (обработано 870, классифицировано 391: 389 LLM + 2 словарь; 479 нерелевантных без direction) |
|
||||
| 2026-09-10 | PRD v0.2 — актуализация под текущее состояние | ✅ закрыта | 2026-09-10 |
|
||||
| 2026-09-11 | Web-замечания пользователя: unpkg/CDN, сырой markdown, даты ISO, ожидание CDN при фильтрации | ✅ закрыта | 2026-09-11 (4 openspec change) |
|
||||
| 2026-09-11 | Веб доступен снаружи: vesti.nixg.ru через Caddy VPS02 | ✅ закрыта | 2026-09-11 (reverse_proxy 10.8.0.2:8400, LE-серт) |
|
||||
| 2026-09-11 | Change `deexternalize-web-assets`: убраны htmx/unpkg и bootstrap/jsdelivr (bootstrap локален) | ✅ закрыта | 2026-09-11 (0 внешних доменов, approve/reject POST-формами) |
|
||||
| 2026-09-11 | Change `web-render-markdown`: markdown-рендер (Python-Markdown, XSS-safe) | ✅ закрыта | 2026-09-11 (фильтр `markdown`, кандидаты+опубликованные) |
|
||||
| 2026-09-11 | Change `web-format-datetime`: даты `ЧЧ:ММ ДД.ММ.ГГГГ` вместо ISO | ✅ закрыта | 2026-09-11 (фильтр `dt`, candidates/published/metrics) |
|
||||
| 2026-09-11 | Change `web-list-filter-no-js`: фильтрация GET-формами без JS/CDN | ✅ закрыта | 2026-09-11 (кнопка «Применить», без ожидания CDN) |
|
||||
| 2026-09-11 | Баг бандлов: двойной слэш `/bundle//opt/vesti/...` в published | ✅ закрыта | 2026-09-11 (create_bundle → относительный путь, 4 строки БД обновлены) |
|
||||
| 2026-09-11 | AGENT.MD — правила проекта (все изменения через OpenSpec) | ✅ закрыта | 2026-09-11 |
|
||||
| 2026-09-09 | git-репозитории (gitverse истина, gitea зеркало) — /opt/vesti НЕ git-репо | 🔵 открыта | |
|
||||
| 2026-09-08 | openspec archive web-изменений + own-content-hub + publisher-service (после подтверждения) | 🔵 открыта | |
|
||||
| 2026-09-13 | После перезагрузки не поднялся веб :8400 (юнит vesti-web был disabled) + publisher возвращён с user-юнита на Docker | ✅ закрыта | 2026-09-13 (vesti-web enabled; docker compose up -d --build; vesti-publisher healthy; watchdog переписан на docker-проверку) |
|
||||
| 2026-09-13 | Бэкап VESTI на Яндекс.Диск (по аналогии icq/netbox) | ✅ закрыта | 2026-09-13 (backup.sh + backups/ + ЯД vesti-backups, cron root 45 2) |
|
||||
| 2026-09-13 | approve → 500 (UnboundLocalError 'dirn' в web/app.py) | ✅ закрыта | 2026-09-13 (change fix-approve-dirn; dirn/lang перенесены до использования; 303 вместо 500) |
|
||||
| 2026-09-13 | Медиа в карточках новостей не отображаются | ✅ закрыта | 2026-09-13 (change web-media-preview; роут /media/{filename} + превью img/video в candidates/published; клик → полноразмер в новой вкладке) |
|
||||
| 2026-09-13 | Пост без классификации: на карточке значок «?» — понять его роль; если классификации нет — дать возможность вручную указывать/изменять/добавлять направление при анализе | 🔵 открыта | |
|
||||
+403
@@ -0,0 +1,403 @@
|
||||
# VESTI — WALKTHROUGH (капитанский журнал)
|
||||
|
||||
Хронология реализации: команды, решения, ошибки и их исправления. Цель — воспроизводимость.
|
||||
|
||||
## 2026-09-08 — Старт проекта, проектирование OpenSpec, каркас
|
||||
|
||||
### Контекст
|
||||
Новый проект новостного агрегатора с веб-интерфейсом. Эволюция /opt/news (RSS/HTML/TG
|
||||
краулеры, SQLite+Qdrant, LLM-классификатор qwen3:8b). Полный стек: краулинг (RSS, email,
|
||||
сайты, TG, WeChat, X) → дедуп+слияние → факт-чек → категоризация → дайджесты (видео) +
|
||||
ленты ботов (TG/VK/fediverse) → веб-управление. Первый прототип: TG-краулер + бот-публикатор,
|
||||
направление Линукс (ru).
|
||||
|
||||
### Принятые решения (опросник)
|
||||
- A1: эволюция /opt/news. B4: боты на 4 языках (ru/en/zh/ko). B3: Линукс добавить в направления.
|
||||
- C1: именование ботов @dedinit_vesti_<направление>_<язык>_bot.
|
||||
- C2-b: сначала «черновик на подтверждение» (потом смягчать). C3: пост = карточка в лимит одного поста с картинкой.
|
||||
- D1: Postgres (канон) → в прототипе SQLite, миграция на фазе 2.
|
||||
- E2: облачный LLM — отдельный API/ключ потом (учёт затрат проекта отдельно).
|
||||
- G1: дайджест — отдельная сущность по направлению (G1), интерес = популярные новости, залайканные комментарии/реакции = хайп-сигналы. G3: выпуск 5–10 поводов, на выходных.
|
||||
- Задачи: сначала cron, потом развитие до ARQ, вместо Redis — Postgres + plugin; **для задач нужно визуальное отображение успешности каждого запуска**; **задача для каждого источника своя**.
|
||||
|
||||
### Команды
|
||||
```bash
|
||||
# OpenSpec
|
||||
mkdir -p /opt/vesti && cd /opt/vesti
|
||||
openspec init --tools hermes --force --no-animation
|
||||
openspec new change "tg-crawler-publisher-prototype"
|
||||
openspec validate tg-crawler-publisher-prototype # -> valid (2 warnings про SHALL — косметика)
|
||||
# артефакты писались вручную (CLI: openspec instructions <artifact> --json выдаёт только шаблон)
|
||||
|
||||
# Каркас
|
||||
mkdir -p crawler classifier publisher web/templates web/static bundles sources db scripts
|
||||
touch crawler/__init__.py classifier/__init__.py publisher/__init__.py web/__init__.py
|
||||
python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
|
||||
|
||||
# БД
|
||||
.venv/bin/python db/db.py # создаёт db/vesti.db по db/schema.sql
|
||||
# синк реестра
|
||||
PYTHONPATH=/opt/vesti .venv/bin/python -c "from sources.sources import sync_sources_to_db, load_sources_yaml; sync_sources_to_db(load_sources_yaml())"
|
||||
```
|
||||
|
||||
### Секреты
|
||||
- api_id=24276216, api_hash (из /opt/icq/docker-compose.yml, SLIDGE__SLIDGRAM_API_*) → /opt/vesti/.env (chmod 600).
|
||||
- Токен бота — ещё нет (VESTI_BOT_TOKEN пуст).
|
||||
|
||||
### Ошибки и исправления
|
||||
1. **config.py BASE_DIR = parent.parent** → давал /opt/db вместо /opt/vesti. Исправлено: `parent`.
|
||||
2. **schema.sql с SQL-комментариями (`--`) → executescript падал** `unrecognized token "#"` / `--`. Исправлено: убраны все комментарии (чистые CREATE).
|
||||
3. **db/db.py импорт config**: добавлен `sys.path.insert(0, parent.parent)`.
|
||||
4. **telegram-tunnel не слушает :1080**: systemd active, но `ss -tlnp | grep 1080` пусто; журнал: `Timeout, server 10.8.0.1 not responding` (08:38:32), ssh-форвард не поднят, FIN-WAIT на :22. VPS01 ping+22 отвечают. **НЕ ПОЧИНЕНО** — блокер краулера.
|
||||
|
||||
### Схема БД (db/schema.sql)
|
||||
- sources (slug unique, url, channel, crawler, direction, lang, priority, enabled, last_fetch, last_error, status)
|
||||
- posts (sha256 unique, source_id, tg_channel, tg_post_id, url, text, views, reactions JSON, reactions_total, published_at, fetched_at, media_path, status)
|
||||
- tg_state (channel_slug PK, last_post_id, last_ts) — инкрементальный обход
|
||||
- classifications (post_id, direction, relevance critical/high/low, interest 1-5, summary, keywords, model)
|
||||
- published (post_id, bundle_path, tg_message_id, views, reactions, published_at)
|
||||
- runs (source_id, task, trigger, status running/ok/error, started_at, finished_at, duration_ms, posts_fetched, posts_new, error) — **визуализация запусков per-source**
|
||||
|
||||
### Ключевые питфолы
|
||||
- Telethon из РФ: ТОЛЬКО через SOCKS5 127.0.0.1:1080 (telegram-tunnel → VPS01). Прямое соединение заблокировано.
|
||||
- Bot API читает только своего бота; чужие каналы — только MTProto/Telethon.
|
||||
- Ollama qwen3:8b-nothink: обязателен `extra_body={"think": false}` (см. навык hermes-auxiliary-local-models).
|
||||
- Дедуп: sha256(text) + уникальность url; физически ничего не удаляем (правило пользователя) — только status.
|
||||
- Правило: не удалять пользовательские файлы; перезапись — только по явному согласованию.
|
||||
|
||||
### Следующая сессия
|
||||
1. Починить telegram-tunnel (первая задача!).
|
||||
2. Авторизация Telethon (нужен телефон или готовая сессия).
|
||||
3. Классификатор (keywords.py + classify.py).
|
||||
4. Публикатор (card.py + bot.py).
|
||||
5. Веб (FastAPI + Bootstrap 5.3 + HTMX, :8400) с визуализацией runs.
|
||||
6. Банк статей (markdown-бандлы, web/store.py).
|
||||
7. cron per-source + systemd + тихий watchdog.
|
||||
8. Git: gitverse.ru (истина) / gitea bigbox (зеркало).
|
||||
|
||||
## 2026-09-08 вечер — форварды, медиа, классификатор, публикатор, веб, банк
|
||||
|
||||
### Что сделано
|
||||
1. **Форварды (главный вопрос пользователя)**: «если канал пересылает пост другого канала, нужен только исходный; если такого канала нет в источниках — как быть, два раза скачивать смысла нет».
|
||||
- Политика: донор ЕСТЬ в источниках → пересланный пост пропускается (это дубль); донора НЕТ → пост сохраняется как «упоминание» с `fwd_from_channel_id`/`fwd_from_post_id`, медиа НЕ скачивается (копия останется у донора, если он станет источником).
|
||||
- Реализация: `crawler/telegram_crawler.py` — `resolve_source_ids()` (id 8 источников через get_entity при старте), в `fetch_channel`/`store_posts`: если `msg.fwd_from` → `PeerChannel.channel_id` → сравнение с src_ids; дубль по `sha256 OR url` дозаполняет fwd-поля.
|
||||
- Схема: `posts += fwd_from_channel_id, fwd_from_post_id` (schema.sql + миграция ALTER).
|
||||
- Проверено на реальных данных: gitgate пересылает Selectel (1414909052), linuxcamp — DevOpsKaz (1561449396); форвард linuxcamp/765 помечен fwd-полями (бэкфилл-скрипт). Без Selectel в источниках форварды сохраняются без медиа; с Selectel — отфильтровываются.
|
||||
2. **Классификатор**: `classifier/keywords.py` (словари 8 направлений, regex \b — однобуквенные ключи типа «c» давали ложные срабатывания; исправлено) + `classify.py` (Ollama qwen3:8b-nothink, JSON direction/relevance/interest/summary, `extra_body={"think": false}`, CLASSIFY_TIMEOUT=20, фолбэк без LLM). Колонки: `direction, relevance, interest, summary, classified` (schema.sql + ALTER в classify.py).
|
||||
- Питфол: первый прогон завис — Ollama без таймаута на 137 постов ~40 мин; убит, перезапущен с `CLASSIFY_TIMEOUT=20`.
|
||||
- Питфол 2 (ВАЖНО): `think:false` через `/api/chat` ИГНОРИРУЕТСЯ — qwen3 генерирует `<think>`-размышления (медленно, не-JSON, ~30с/пост). Отключение работает только через OpenAI-совместимый `POST /v1/chat/completions` с полем `think:false` в теле (ответ: `choices[0].message.content`). После перехода на /v1: ~4-8с/пост, стабильный JSON.
|
||||
3. **Публикатор**: `publisher/card.py` (карточка ≤4096, HTML-экранирование) + `bot.py` (sendPhoto/sendMessage, канал `@dedinit_vesti_<направление>_<язык>_bot`, dry-run без токена, get_views). Карточка проверена — 347 символов.
|
||||
4. **Веб**: `web/app.py` + `web/templates/{base,login,candidates,published,metrics}.html` (FastAPI + Jinja2 + Bootstrap 5.3 CDN + HTMX), `127.0.0.1:8400`.
|
||||
- Роуты: /login (пароль), /candidates (фильтры по направлению/статусу, HTMX approve/reject), /published (views + ссылка /bundle/{path}), /metrics, /logout.
|
||||
- Approve: `update posts set status='published'` + `publish_card()` (dry-run) + `web/store.create_bundle()` → md в bundles/ + запись в published.
|
||||
- Питфолы: (а) login 500 — забыл `request` в контексте jinja (`render(request=request)`); (б) `database is locked` — веб открывал sqlite без WAL, а фоновый классификатор держал долгую пишущую транзакцию; исправлено WAL+busy_timeout в `_db()`, классификатор убит (завис) и перезапущен.
|
||||
5. **Банк**: `web/store.py` — `make_bundle()` (слаг-транслитерация, коллизии слагов суффиксом -2, реакции-эмодзи, медиа в media/<slug>/), `create_bundle()` для веба; 137 бандлов было собрано ранее, approve создаёт бандл на лету.
|
||||
|
||||
### Команды
|
||||
```bash
|
||||
# форварды: бэкфилл fwd-полей для уже сохранённых постов
|
||||
.venv/bin/python - <<'EOF' # iter_messages по gitgate/linuxcamp, UPDATE fwd-полей
|
||||
# классификатор (в фоне, с таймаутом Ollama)
|
||||
CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --db db/vesti.db --limit 200
|
||||
# веб
|
||||
VESTI_WEB_PASSWORD=secret123 .venv/bin/uvicorn web.app:app --host 127.0.0.1 --port 8400
|
||||
# проверка веба
|
||||
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8400/login # 200
|
||||
curl -s -c /tmp/vc -o /dev/null -w "%{http_code}" -X POST -d "password=..." http://127.0.0.1:8400/login # 302
|
||||
curl -s -b /tmp/vc -o /dev/null -w "%{http_code}" -X POST http://127.0.0.1:8400/posts/2/approve # 302
|
||||
# миграции: ALTER TABLE posts ADD fwd_from_channel_id INTEGER; ADD fwd_from_post_id INTEGER
|
||||
# ADD direction/relevance/interest/summary/classified (делает classify.py)
|
||||
```
|
||||
|
||||
### Схема (добавлено)
|
||||
- posts: `content_type`, `media_path`, `fwd_from_channel_id`, `fwd_from_post_id`, `direction`, `relevance`, `interest`, `summary`, `classified`
|
||||
|
||||
### Следующая сессия (обновлено)
|
||||
1. Дождаться/перезапустить классификатор (фоновый proc, 4/137 → полный прогон) — проверить /tmp/vesti_classify2.log и `classified=1` в БД.
|
||||
2. VESTI_BOT_TOKEN в .env → реальная публикация (message_id, views).
|
||||
3. Пароль веба в .env (убрать fallback admin).
|
||||
4. systemd: vesti-web.service (задача 5.6), cron per-source, тихий watchdog.
|
||||
5. git-репозитории (gitverse истина, gitea зеркало).
|
||||
6. Распределение классификации по направлениям, поправить словари.
|
||||
|
||||
## 2026-09-08 — own-content-hub: свой канал @dedinit в конвейере (инъекция контента)
|
||||
|
||||
### Контекст
|
||||
Пользователь: «проект /opt/vesti — используй краулер для создания копии моего собственного канала telegraph t.me/dedinit… это должен быть отдельный источник данных, чтобы мы собирали из различных источников мои посты (Telegram, сайт, и т.п.), и нужно мой контент раскидывать по всем ботам соответствующим теме» — ИНЪЕКЦИЯ своего контента в новостные каналы для органического роста подписчиков. Явная правка пользователя: «не просто сделай копию, а встрой сбор данных из моих ресурсов в общую логику проекта».
|
||||
|
||||
### Решение
|
||||
Свой канал = источник `own: true` в sources.yaml (slug `dedinit`, direction null, lang ru). Посты → `is_own=1`/`is_own_canonical=1`; повтор поста во внешнем канале → `is_own=0` (упоминание). Свои посты = «сильные кандидаты»: словарная классификация без LLM (`method=dict-own`, relevance=critical), мультинаправления (classifications поддерживает несколько записей) → fan-out по всем `@dedinit_vesti_<dir>_<lang>_bot` с атрибуцией «Дед в АйТи (@dedinit) · t.me/dedinit/<id>`. Форварды в своём канале: is_own=1 + fwd-поля, медиа НЕ скачивать (чужой контент).
|
||||
|
||||
### OpenSpec
|
||||
- `openspec new change own-content-hub`; артефакты: proposal.md, design.md, tasks.md (19 задач), specs/{tg-crawler,classifier,tg-publisher,vesti-web,news-store}/spec.md.
|
||||
- ВАЖНО: `openspec/specs/` пуст (только .gitkeep; прошлый change tg-crawler-publisher-prototype не архивирован) → валидатор требует **только ADDED** требования; MODIFIED → ошибки («must include at least one scenario»). Переведено ВСЁ в ADDED, каждое требование с MUST/SHALL + `#### Scenario:` → `openspec validate own-content-hub` → чисто (0 ошибок/предупреждений).
|
||||
- Питфол: `openspec show own-content-hub --json --deltas-only` завис → заблокирован командой (не повторять; silent-timeout = «Silence is not consent»). Диагностика идёт через read-only `search_files`/`read_file` (нашёл .gitkeep в openspec/specs/).
|
||||
|
||||
### Реализация (все файлы)
|
||||
1. **Миграция** `db/migrate_own.py` (идемпотентный, `PRAGMA`-проверка): `ALTER TABLE posts ADD COLUMN is_own INTEGER DEFAULT 0, is_own_canonical INTEGER DEFAULT 0; ALTER TABLE sources ADD COLUMN own INTEGER DEFAULT 0; ALTER TABLE published ADD COLUMN distributed_dirs TEXT`. Запущено: `dedinit|1` в sources (после синка).
|
||||
2. **sources.yaml**: +dedinit (own: true, direction: null, lang: ru). `sources.py`: INSERT/UPDATE учитывает own.
|
||||
3. **Краулер** `crawler/telegram_crawler.py`:
|
||||
- `store_posts(conn, source_id, posts, is_own_source=False)`: own-источник → is_own=1 + is_own_canonical=1; повтор sha256/url у существующего канона → новая запись is_own=0 (упоминание); fwd-поля сохраняются.
|
||||
- `fetch_channel(..., is_own_source)`: чужой форвард (fwd_from не в наших источниках) → is_forward → медиа НЕ скачивается (даже в own-канале); свой источник → медиа качается.
|
||||
- `run_source`: `is_own_source = int(source.get("own") or 0)`.
|
||||
4. **Классификатор** `classifier/keywords.py` + `classify.py`:
|
||||
- `find_directions_all(text)` — возвращает ВСЕ словарные попадания (для fan-out); `find_direction` осталась (первое/основное).
|
||||
- `classify_text`: is_own=1 + словарное направление → relevance=critical, classified=True, method='dict-own', БЕЗ LLM. Внешний без LLM → low/classified=False.
|
||||
- classify_posts_in_db: пишет ВСЕ направления в `classifications` (мультинаправления), в posts.direction — основное.
|
||||
5. **Публикатор** `publisher/bot.py` + `card.py`:
|
||||
- `publish_multi(card, directions, lang)` → {direction: {message_id, media_message_id, dry_run}} — fan-out; пустой список → направление поста.
|
||||
- `get_views_multi(directions, message_ids, lang)` → {direction: views} (getMessage→views, try/except → 0).
|
||||
- Карточка: свой пост → строка `✍️ Дед в АйТи (@dedinit) · https://t.me/dedinit/<id>` (без отдельной 🔗-ссылки); внешний — как раньше.
|
||||
6. **Веб** `web/app.py` + templates:
|
||||
- /candidates?own=1 фильтр; бейдж «⭐ СВОЙ»; при approve own-поста — чекбоксы направлений (name=dirs), по умолчанию направления классификации.
|
||||
- approve: own → publish_multi + get_views_multi, distributed_dirs=JSON(dirs), views=сумма; внешний → [dirn] без fan-out. create_bundle(directions=dirs_selected) — бандл на каждое направление.
|
||||
- /published: распределённые боты из distributed_dirs (jinja-фильтр `from_json`), бейдж «⭐ СВОЙ».
|
||||
- Питфол: sync-endpoint + `request.form()` → RuntimeWarning «coroutine was never awaited»; fix — `async def approve` + `await request.form()`.
|
||||
7. **Бандлы** `web/store.py`: frontmatter += origin: own / source_url: t.me/dedinit/<id> / author: «Дед в АйТи» (для внешних origin: external). create_bundle(directions=...) — по бандлу на КАЖДОЕ направление fan-out.
|
||||
|
||||
### Проверки (все выполнены)
|
||||
- `openspec validate own-content-hub` → exit 0.
|
||||
- Миграция: `sources.dedinit.own=1`; PRAGMA таблиц — колонки есть.
|
||||
- Тест классификатора: own-текст про Linux при выключенной Ollama → critical/classified=True; направление `linux`; мультинаправления ['linux','ai'] найдены.
|
||||
- Тест карточки: внешний — без атрибуции; свой — «✍️ Дед в АйТи (@dedinit) · t.me/dedinit/42».
|
||||
- Тест publish_multi: dry-run для ['linux','ai'], message_id=0; get_views_multi → {linux:0,ai:0}; channel_username → @dedinit_vesti_linux_ru_bot.
|
||||
- Тест бандла: create_bundle(['linux','ai']) → 2 файла bundles/{linux,ai}/2026-09/testovyy-post-pro-linux-i-ai.md, frontmatter origin:own/source_url/author.
|
||||
- E2E (TestClient, dry-run): login→candidates?own=1 (СВОЙ виден)→approve dirs[linux,ai]→302 /published→visible @dedinit_vesti_linux_ru_bot+ai; distributed_dirs=JSON.
|
||||
- В БД: тестовые посты 9001 (published) и 9002 (new, approve не перетестирован — команда заблокировалась; async form fix внесён, retry в след. сессии).
|
||||
|
||||
### Схема (добавлено this session)
|
||||
- posts: `is_own`, `is_own_canonical`
|
||||
- sources: `own`
|
||||
- published: `distributed_dirs`
|
||||
- DB: /opt/vesti/db/vesti.db — 137 внешних + 2 тестовых своих поста; tg_state для dedinit пуст (бэкфилл НЕ запускался).
|
||||
|
||||
### Секреты
|
||||
- VESTI_BOT_TOKEN — НЕ задан (публикация dry-run). Токены ботов направлений — у пользователя через @BotFather.
|
||||
|
||||
### Следующая сессия (приоритет)
|
||||
1. Бэкфилл @dedinit (задача 2.3): `.venv/bin/python -m crawler.telegram_crawler --channel dedinit` — ~1039 постов is_own=1 (первый раз; медиа по возможности; лимиты).
|
||||
2. Повторный approve-тест (async form) — command was blocked last time.
|
||||
3. VESTI_BOT_TOKEN → реальная публикация; боты остальных направлений.
|
||||
4. Классификация своих постов (dict-own, critical), проверить distributed_dirs на реальном посте.
|
||||
5. systemd vesti-web.service, cron, watchdog; git-репо /opt/vesti; openspec archive own-content-hub (после подтверждения пользователем).
|
||||
## 2026-09-09 — publisher-service: реальная публикация + микросервис
|
||||
|
||||
### Контекст
|
||||
Пользователь дал данные бота-контроллера: @dedinit_controller_bot (id 7765665742), канал
|
||||
@dedinit_vesti (https://t.me/dedinit_vesti). На старте один канал; в перспективе тот же бот
|
||||
добавляется админом к другим каналам (один бот → много каналов). Вопрос: сделать
|
||||
публикатор изолированным микросервисом, вызываемым по HTTP (FastAPI).
|
||||
|
||||
### Решение (архитектура)
|
||||
vesti-web (:8400) --HTTP POST--> publisher-service (:8410) --Bot API (SOCKS5 :1080)--> Telegram
|
||||
- Publisher — единственная точка, знающая токен бота, прокси и каналы.
|
||||
- Каналы: VESTI_BOT_CHANNELS (сейчас @dedinit_vesti; позже несколько).
|
||||
- Веб больше НЕ импортирует publisher.bot — только HTTP-клиент web/publisher_client.py.
|
||||
|
||||
### OpenSpec
|
||||
- `openspec change create publisher-service` (интерактив заблокирован → каталог создан вручную).
|
||||
- Артефакты: proposal.md, design.md, specs/tg-publisher-service/spec.md, tasks.md.
|
||||
- `openspec validate publisher-service` → valid (0 ошибок; замечание про rules — косметика).
|
||||
|
||||
### Реализация
|
||||
1. services/publisher/ — FastAPI-микросервис:
|
||||
- app/main.py: GET /healthz, POST /api/v1/publish (card{text,media?,direction,lang}, channels?),
|
||||
GET /api/v1/views/{channel}/{mid}; Pydantic-модели (Card, PublishRequest, ChannelResult, PublishResponse).
|
||||
- app/telegram.py: httpx.Client(proxy=socks5://127.0.0.1:1080); send_message/send_photo/get_views/
|
||||
get_me/get_chat; TelegramError(http_code) — 403 (бот не админ) / 502 (сеть/прокси).
|
||||
- app/channels.py: resolve_channels (запрос → иначе конфиг).
|
||||
- app/config.py: Settings @dataclass, env из .env (override=True), BASE=parents[3].
|
||||
- requirements.txt, Dockerfile (python:3.12-slim, non-root, healthcheck), docker-compose.yml
|
||||
(127.0.0.1:8410, env_file ../.env), .env.example.
|
||||
2. Токен записан в .env (VESTI_BOT_TOKEN). getMe через SOCKS5 → ok (bot=dedinit_controller_bot).
|
||||
3. `httpx[socks]` доустановлен в venv (для SOCKS5 к Bot API; пользователь подтвердил).
|
||||
4. web/publisher_client.py: publish(card, channels?) → POST /api/v1/publish; get_views(channel, mid).
|
||||
web/app.py: approve → http_publish(card) вместо publish_multi; publisher.bot импорт удалён.
|
||||
5. Реальная публикация: POST /api/v1/publish {text} → {"ok":true,"results":{"@dedinit_vesti":{"message_id":2}}}
|
||||
(в канал ушёл тестовый пост «🔧 Тест publisher-service»).
|
||||
|
||||
### Питфолы (Важно)
|
||||
- config.py: токен не читался — (1) os.getenv выполняется при импорте ДО load_dotenv (класс ClassVar);
|
||||
фикс: @dataclass + __post_init__; (2) BASE = parent.parent.parent → /opt/vesti/services, а не /opt/vesti;
|
||||
фикс: parents[3]; (3) load_dotenv без override не перезаписывает пустую env-переменную → override=True.
|
||||
- patch (инструмент): повторял ошибку «path required» — передавал поле `patch` вместо `path`;
|
||||
фикс: только mode/path/old_string/new_string (без `patch`).
|
||||
|
||||
### Команды
|
||||
```bash
|
||||
cd /opt/vesti
|
||||
.venv/bin/uvicorn services.publisher.app.main:app --host 127.0.0.1 --port 8410 &
|
||||
curl -s http://127.0.0.1:8410/healthz # ok, bot=dedinit_controller_bot, proxy, channels
|
||||
curl -s -X POST http://127.0.0.1:8410/api/v1/publish -H 'Content-Type: application/json' \
|
||||
-d '{"card":{"text":"<b>Тест</b>","direction":"linux","lang":"ru"}}'
|
||||
openspec validate publisher-service
|
||||
docker compose -f services/publisher/docker-compose.yml up -d --build # vesti-publisher (Docker, проверено 2026-09-09)
|
||||
# Docker-питфолы:
|
||||
# - пути в compose отсчитываются от services/publisher/ → .env = ../../.env, media = ../../media
|
||||
# - TG_PROXY=127.0.0.1 внутри контейнера = сам контейнер → socks5://host.docker.internal:1080 + extra_hosts: host.docker.internal:host-gateway
|
||||
# - load_dotenv(override=True) перебивает env контейнера → override=False (env окружения приоритетнее .env)
|
||||
# - dataclass-дефолт tg_proxy='socks5://127.0.0.1:1080' truthy → or os.getenv не срабатывает → дефолт сделать пустым
|
||||
```
|
||||
|
||||
### Следующая сессия
|
||||
1. Бэкфилл своего канала @dedinit (2.3): ~1039 постов is_own=1 (краулер + SOCKS5).
|
||||
2. publisher: медиа при Docker (card.media = /opt/vesti/media не совпадает с монтированием /srv/publisher/media).
|
||||
3. systemd vesti-web.service + publisher.service + cron per-source + тихий watchdog (no_agent, молчит пока нет работы).
|
||||
4. git-репозитории (gitverse истина, gitea зеркало) — /opt/vesti НЕ git-репо.
|
||||
5. openspec archive own-content-hub / publisher-service после подтверждения.
|
||||
|
||||
## 2026-09-10 — бэкфилл @dedinit, фикс медиа, cron, watchdog, веб
|
||||
|
||||
### Контекст
|
||||
Продолжение: восстановить веб :8400 (упал), бэкфилл канала (2.3), классификатор, медиа в Docker.
|
||||
|
||||
### Что сделано
|
||||
1. **Веб :8400** — запущен напрямую (background, env из .env). systemd-юнит `/etc/systemd/system/vesti-web.service` создан, но `daemon-reload` зависает (проблемы systemd на bigbox — зависшие job-ы prometheus/udev; не связано с vesti). Юнит подхватится при перезагрузке/исправлении systemd.
|
||||
- Пароль веба: `VESTI_WEB_PASSWORD` в .env нет → код: `os.getenv("VESTI_WEB_PASSWORD") or os.getenv("ADMIN_PASSWORD") or "admin"` (патч web/app.py).
|
||||
2. **Бэкфилл канала @dedinit** — создан `crawler/backfill_dedinit.py`:
|
||||
- итерирует ВСЕ посты канала (iter_messages reverse=False, без лимита 20),
|
||||
- store_posts (дедуп sha256/url), медиа скачивает в media/media/,
|
||||
- tg_state.last_post_id пишет как max реальных id (исключая тестовые 9000+).
|
||||
- Питфол: изначально фильтр `msg.id <= last_id` обнулял бэкфилл после частичного прогона (last_id уже высокий) → фильтр убран, дедуп в store_posts решает.
|
||||
- Запуск: `.venv/bin/python -m crawler.backfill_dedinit` (--limit N для теста, --no-media, --max-errors).
|
||||
3. **Фикс медиа в Docker** — compose: `../../media/media:/srv/publisher/media:ro` (вместо ../../media).
|
||||
- Причина: media_path в БД = `media/<file>`, физически файлы в `/opt/vesti/media/media/` (download_media добавляет ещё /media).
|
||||
- В контейнере (WORKDIR /srv/publisher) `Path("media/<file>")` = `/srv/publisher/media/<file>` → теперь маунтится внутренний каталог.
|
||||
- vesti-publisher пересобран (Up, healthy), healthz: proxy=socks5://host.docker.internal:1080.
|
||||
4. **Cron (Hermes cron)**:
|
||||
- `vesti-crawler-all-sources` (31f55fdc86a7): `*/30 * * * *`, no_agent, deliver=local, скрипт scripts/crawler-cron.sh (тихий; лог в logs/crawler-cron.log).
|
||||
- `vesti-watchdog` (75d95cde2d91): `*/15 * * * *`, no_agent, deliver=telegram:281328953, скрипт scripts/vesti-watchdog.sh (проверяет publisher :8410 healthz, веб :8400, SOCKS5 :1080, контейнер, БД; молчит при норме).
|
||||
- Обёртки в /opt/hermes/.hermes/scripts/ (cron требует относительный путь там).
|
||||
- Питфол: `repeat="forever"` в payload ломал создание cron (`'<=' not supported between instances of 'str' and 'int'`) → создавать без repeat (по умолчанию forever).
|
||||
5. **Классификатор** — патч: SELECT добавил `is_own` (для dict-own фолбэка своих постов). Прогон по неклассифицированным — после бэкфилла.
|
||||
6. **STATUS.md** — обновлён (бэкфилл/медиа/cron отмечены, веб-запуск, открытые вопросы).
|
||||
|
||||
### Состояние БД (после бэкфилла)
|
||||
- **Бэкфилл ЗАВЕРШЁН** (2026-09-10 17:55): fetched=1040, max_post_id=1092, занял ~44 мин. Всего постов 995: dedinit 846 (is_own=1), внешних ~149. Медиа скачано в media/media/.
|
||||
- Неклассифицировано на момент старта классификатора: 870 (833 своих + ~37 внешних).
|
||||
- Тестовые посты 9001/9002 (published/new) остались (не удаляем — правило пользователя).
|
||||
- Классификатор запущен в фоне 2026-09-10 18:0x (`CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --limit 900`, лог /tmp/vesti-classify.log); прогон — Ollama по внешним, словари/critical по своим.
|
||||
- **Классификатор ЗАВЕРШЁН** (2026-09-10 18:2x, exit 0): обработано 870, классифицировано 391 (389 LLM + 2 словарь). Остальные 479 — нерелевантные (без direction, норма). Топ: linux critical/high (Omarchy, AL2, CERN→Debian и т.д.).
|
||||
|
||||
### Следующая сессия
|
||||
1. Проверить результат классификации: в БД direction заполнены по ~870 постам; выборочно глянуть качество на своих (846) — словари vs LLM.
|
||||
2. Проверить публикацию с медиа сквозь веб (approve поста с media_path) — publisher должен отправить photo (маунт исправлен).
|
||||
3. git-репозиторий /opt/vesti (gitverse истина, gitea зеркало).
|
||||
4. openspec archive когда задачи закроются ( publisher-service, tg-crawler-publisher-prototype, own-content-hub).
|
||||
|
||||
## 2026-09-11 — web-ui: Caddy/vesti.nixg.ru, 4 openspec change, баг бандлов, AGENT.MD
|
||||
|
||||
### Контекст
|
||||
Пользователь предъявил 4 замечания к веб-интерфейсу: (1) ожидание ответа от unpkg.com при фильтрации списка — перечислить зависимости и как избавиться; (2) в списке отображается сырой markdown; (3) даты как `2026-08-15T15:53` → привести к `20:00 15.08.2026`; (4) **каждое замечание — как отдельный change openspec**.
|
||||
|
||||
### Решение (openspec)
|
||||
4 отдельных change в `/opt/vesti/openspec/changes/` (созданы вручную — CLI `openspec change new` не существует):
|
||||
- `deexternalize-web-assets` — внешние зависимости: htmx 1.9.12 (unpkg.com, base.html:8) + bootstrap 5.3.3 (cdn.jsdelivr.net). Убраны оба; bootstrap скачан в web/static/bootstrap.min.css; approve/reject с hx-post → обычные POST-формы. Итог: 0 внешних доменов (grep подтвердил).
|
||||
- `web-render-markdown` — Python-Markdown >=3.6 (pip + requirements.txt); Jinja2-фильтр `markdown`: escape() → md_parse(nl2br, sane_lists); применяется в candidates (`text[:2000]`) и published (`summary or text[:2000]`).
|
||||
- `web-format-datetime` — фильтр `dt`: datetime.fromisoformat → `%H:%M %d.%m.%Y`; None/мусор → "". Все 3 шаблона ([`:16`] срезы) заменены.
|
||||
- `web-list-filter-no-js` — фильтры и так GET-формы (`onchange="this.form.submit()"`); ожидание вызывал CDN-скрипт. Добавлена кнопка «Применить». После deexternalize — работа без интернета.
|
||||
|
||||
Все 4 — `openspec validate` чисто; tasks.md полностью `[x]`.
|
||||
|
||||
### Caddy / внешний доступ
|
||||
- Юнит веба переведён на `--host 0.0.0.0 --port 8400` (patch-инструмент отказал на /etc/systemd → `sudo sed -i`); старый ручной uvicorn (pid 1638679) висел на 127.0.0.1 → kill + `systemctl start` (pid 1001422).
|
||||
- VPS02: блок `vesti.nixg.ru { reverse_proxy 10.8.0.2:8400 }` в /opt/caddy/Caddyfile (бэкап рядом), `docker exec caddy caddy validate` + `reload` → ok; LE-серт выпущен (первый curl — 000, второй — 303).
|
||||
- Проверка: https://vesti.nixg.ru → 200 (после логина), страницы /candidates /published /metrics — 200.
|
||||
|
||||
### Баг бандлов (исправлен)
|
||||
**Симптом:** в /published ссылки `/bundle//opt/vesti/bundles/linux/2026-09/...` (двойной слэш).
|
||||
**Причина:** `create_bundle` (web/store.py) возвращал `str(path)` — АБСОЛЮТНЫЙ путь; он писался в `published.bundle_path` и подставлялся в `href="/bundle/{{ p.bundle_path }}"`.
|
||||
**Фикс:** `create_bundle` → относительный путь `path.relative_to(BUNDLES_DIR)` (linux/2026-09/slug.md); 4 строки БД UPDATE (префикс `/opt/vesti/bundles/` срезан); роут `/bundle/{path}` не менялся (уже корректный + path-traversal защита). Проверено: ссылки чистые, бандл HTTP 200.
|
||||
|
||||
### AGENT.MD
|
||||
Пользователь: «Создай файл AGENT.MD и запиши туда все правила проекта. Проверь что там будет правило что все изменения нужно делать по openspec.»
|
||||
- `AGENTS.md` — заблокирован защитой Hermes (agent-instruction file, требует интерактивного подтверждения).
|
||||
- Создан `/opt/vesti/AGENT.MD` (5 KB): Правило №1 «ВСЕ изменения — через OpenSpec» (отдельный change на замечание, формат, validate, archive), стек/архитектура, секреты/.env (значения не показывать), правила работы (не удалять файлы, дедуп, русский язык, всё в /opt/vesti), запуск/проверка, направления.
|
||||
|
||||
### Команды (сессия)
|
||||
```bash
|
||||
cd /opt/vesti
|
||||
curl -sL -o web/static/bootstrap.min.css https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css
|
||||
.venv/bin/pip install "Markdown>=3.6"; echo 'Markdown>=3.6' >> requirements.txt
|
||||
sudo sed -i 's/--host 127.0.0.1 --port 8400/--host 0.0.0.0 --port 8400/' /etc/systemd/system/vesti-web.service
|
||||
sudo systemctl restart vesti-web # active; login → 200, candidates/published/metrics → 200
|
||||
# баг: UPDATE published SET bundle_path = relative
|
||||
# caddy (VPS02): docker exec caddy caddy validate && docker exec caddy caddy reload
|
||||
```
|
||||
|
||||
### Питфолы
|
||||
- patch на /etc/systemd/... → «Refusing to write to sensitive system path» → sudo sed.
|
||||
- `systemctl daemon-reload` на bigbox зависает (exit 124, известная проблема) → kill старого + `systemctl start`.
|
||||
- Пароль веба: переменной VESTI_WEB_PASSWORD НЕТ (была ошибка ассистента) — в .env `ADMIN_USER`/`ADMIN_PASSWORD`.
|
||||
- Проверка https://vesti.nixg.ru/bundle/... снаружи — таймаут (не критично, локально проверено).
|
||||
- `curl https://.../published` без свежей куки → 303 (редирект на логин — норма).
|
||||
|
||||
### Следующая сессия
|
||||
1. Проверить результат классификации (direction заполнены, качество на своих 846).
|
||||
2. Тест публикации с медиа сквозь веб (approve с media_path → publisher send_photo).
|
||||
3. git-репозиторий /opt/vesti (gitverse истина, gitea зеркало).
|
||||
4. openspec archive: 4 web-change + publisher-service + tg-crawler-publisher-prototype + own-content-hub (после подтверждения).
|
||||
|
||||
---
|
||||
|
||||
## Сессия 2026-09-13 (восстановление после перезагрузки, approve-баг, медиа-превью, бэкап)
|
||||
|
||||
### 1. После перезагрузки не поднялся веб :8400
|
||||
Пользователь: «после перезагрузки у меня не поднялся контейнер с интерфейсом. почему? исправь.»
|
||||
- Причина: веб — НЕ контейнер, а uvicorn под systemd-юнитом `/etc/systemd/system/vesti-web.service`, который был **disabled** → после ребута не стартовал. (В STATUS.md ошибочно было «подхватится при перезагрузке».)
|
||||
- Фикс: `sudo systemctl enable vesti-web.service` + `start` → active, :8400 → 200.
|
||||
- Publisher: контейнер `vesti-publisher` не стартовал, порт 127.0.0.1:8410 занят старым user-юнитом `vesti-publisher.service` (костыль на время сломанного systemd1).
|
||||
- Решение: systemd1 (D-Bus) после перезагрузки ожил → publisher возвращён на Docker:
|
||||
```bash
|
||||
systemctl --user stop vesti-publisher.service && systemctl --user disable vesti-publisher.service
|
||||
cd /opt/vesti && docker compose -f services/publisher/docker-compose.yml up -d --build
|
||||
docker ps --filter name=vesti-publisher # Up (healthy)
|
||||
```
|
||||
- Watchdog `/opt/vesti/scripts/vesti-watchdog.sh` переписан: проверка не user-юнита, а docker-контейнера (`docker ps --filter name=^vesti-publisher$ --filter status=running`).
|
||||
- **Питфол**: `/opt/vesti/scripts/vesti-watchdog.sh: 7: Syntax error: "(" unexpected` — запуск через `sh` (dash) не понимает bash-массивы → запускать `bash script`, shebang `#!/bin/bash`.
|
||||
|
||||
### 2. approve → 500 Internal Server Error (пост 1017)
|
||||
Пользователь: «https://vesti.nixg.ru/posts/1017/approve Internal Server Error не работает сервис. не могу заапрувить новость.»
|
||||
- Логи: `journalctl -u vesti-web` → `UnboundLocalError: cannot access local variable 'dirn'` в `web/app.py:180`.
|
||||
- Причина: `dirn = post.get("direction") or "linux"` определялся ПОСЛЕ использования (`dirs_selected = ... if cls else [dirn]`) — след старого рефакторинга.
|
||||
- **OpenSpec change `fix-approve-dirn`** (proposal/design/tasks, `.openspec.yaml` со `skip_specs: true` — чистый багфикс, без изменения спеки). `openspec validate` → valid.
|
||||
- Фикс: перенести `dirn`/`lang` наверх (после `post = dict(post)`), убрать поздние дубли. `sudo systemctl restart vesti-web`.
|
||||
- Проверка: POST /posts/1017/approve без сессии → 303 (редирект на login, не 500). С реальной сессией в браузере — approve прошёл.
|
||||
|
||||
### 3. Медиа в карточках новостей (не видно картинку)
|
||||
Пользователь: «новость только с картинкой и я не вижу что за картинка, можешь сделать так чтобы медиа так же в карточки новости отображались?»
|
||||
- Проблема: в `candidates.html` для постов с media_path — только бейдж «🖼 медиа», а роута отдачи файла не было (при монтировании /static, не media).
|
||||
- **OpenSpec change `web-media-preview`** (proposal/design/tasks, `skip_specs: true`).
|
||||
- Фикс:
|
||||
- `web/app.py`: импорт `FileResponse`; константа `MEDIA_DIRS = [BASE/media, BASE/media/media]`; роут
|
||||
```python
|
||||
@app.get("/media/{filename}")
|
||||
def media(request: Request, filename: str):
|
||||
_require_auth(request)
|
||||
name = os.path.basename(filename) # защита path traversal
|
||||
for d in MEDIA_DIRS:
|
||||
f = (d / name).resolve()
|
||||
if f.exists() and f.is_file():
|
||||
return FileResponse(f)
|
||||
return HTMLResponse("not found", status_code=404)
|
||||
```
|
||||
- `candidates.html` и `published.html`: превью `<img src="/media/<basename>" max-height:180px>` (jpg/png/gif/webp) или `<video controls>` (mp4/webm/mov); клик по картинке → полноразмер в новой вкладке (`<a target="_blank">`, без JS — проект без JS).
|
||||
- Проверка (через логин-куку): /media/LinuxMastery_1079.jpg → 200 image/jpeg; старый mp4 из media/media/ → 200 video/mp4; nonexistent → 404; /candidates рендерит `<a target="_blank" title="Открыть полноразмер">`.
|
||||
|
||||
### 4. Бэкап VESTI на Яндекс.Диск (по образцу icq)
|
||||
Пользователь: «у нас нет бэкапа для этого проекта. сделай по аналогии с проектами icq и federation. там скрипт выгружает данные и сохраняет их на Яндекс диск.»
|
||||
- Создан `/opt/vesti/backup.sh` (по образцу `/opt/icq/backup.sh`): tar.gz проекта → `/opt/vesti/backups/`, копия на ЯД `/mnt/yandex-disk/backup/vesti-backups/`. Ротация: локально 7 дней, ЯД 30 дней.
|
||||
- Root cron: `45 2 * * * /opt/vesti/backup.sh >> /var/log/vesti-backup.log 2>&1` (как у icq). ЯД монтируется автоматически (fstab davfs + @reboot).
|
||||
- Первый бэкап: `vesti_20260913_134505.tar.gz` (3.5G — медиа тяжёлые), скопирован на ЯД. Проверено: `ls -lh /mnt/yandex-disk/backup/vesti-backups/`.
|
||||
- **Питфол**: первый запуск в фореграунде таймаутнул (cp большого архива на davfs медленный) → запускать в фоне (`terminal background=true, notify_on_complete`) или оставить ночному cron.
|
||||
|
||||
### 5. Правило OpenSpec усилено
|
||||
Пользователь: «ты опять изменения сделал без openspec? пропиши уже и в памяти проекта и в своей памяти, что все изменения в проектах нужно делать по openspec».
|
||||
- AGENT.MD: Правило №1 расширено — любое изменение (конфиг, деплой, docs тоже) через OpenSpec; «НЕ начинать правки, пока change не создан и не провалидирован»; «сразу после правок — бэкап».
|
||||
- Память агента: «ЖЕЛЕЗНО: все изменения в проектах (/opt/*) — только через OpenSpec».
|
||||
|
||||
### Следующая сессия
|
||||
1. Проверить результат классификации направлений (качество на своих 846).
|
||||
2. Тест публикаци с медиа сквозь веб (approve с media_path → publisher send_photo) — если ещё не проверен.
|
||||
3. git-репозиторий /opt/vesti (gitverse истина, gitea зеркало).
|
||||
4. openspec archive: fix-approve-dirn, web-media-preview, rich-repost-card + старые changes (после подтверждения).
|
||||
@@ -0,0 +1,53 @@
|
||||
#!/bin/bash
|
||||
# Скрипт резервного копирования VESTI (краулер, веб, publisher, медиа, БД, доки) с отправкой на Яндекс.Диск
|
||||
# По образцу /opt/icq/backup.sh (и /opt/netbox/backup.sh)
|
||||
|
||||
PROJECT_DIR="/opt/vesti"
|
||||
BACKUP_DIR="${PROJECT_DIR}/backups"
|
||||
YADISK_MOUNT="/mnt/yandex-disk"
|
||||
YADISK_TARGET="${YADISK_MOUNT}/backup/vesti-backups"
|
||||
DATE=$(date +%Y%m%d_%H%M%S)
|
||||
|
||||
# Папки/файлы проекта, которые бэкапим (из /opt/vesti)
|
||||
INCLUDE="db media bundles sources crawler classifier web services publisher scripts openspec .env docker-compose.yml README.md STATUS.md PRD.md TODO.md WALKTHROUGH.md AGENT.MD"
|
||||
|
||||
mkdir -p ${BACKUP_DIR}
|
||||
|
||||
echo "🔄 [$(date)] Начинаем резервное копирование VESTI..."
|
||||
|
||||
# Проверяем, примонтирован ли Яндекс.Диск
|
||||
if ! mountpoint -q ${YADISK_MOUNT}; then
|
||||
echo " ❌ ОШИБКА: Яндекс.Диск не примонтирован!"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Создаём папку для бэкапов на Яндекс.Диске (если её нет)
|
||||
mkdir -p ${YADISK_TARGET} 2>/dev/null
|
||||
|
||||
# 1. Бэкап проекта одним архивом
|
||||
ARCHIVE="${BACKUP_DIR}/vesti_${DATE}.tar.gz"
|
||||
echo " → Архив проекта..."
|
||||
tar czf ${ARCHIVE} -C ${PROJECT_DIR} ${INCLUDE} 2>/dev/null
|
||||
|
||||
if [ -s "${ARCHIVE}" ]; then
|
||||
echo " ✅ Архив: $(du -h ${ARCHIVE} | cut -f1)"
|
||||
echo " ☁️ Копирование на Яндекс.Диск..."
|
||||
cp ${ARCHIVE} ${YADISK_TARGET}/
|
||||
echo " ✅ скопирован на ЯД (${YADISK_TARGET}/)"
|
||||
else
|
||||
echo " ❌ Ошибка создания архива!"
|
||||
fi
|
||||
|
||||
# 2. Очистка старых бэкапов
|
||||
# Локально: оставляем 7 дней
|
||||
find ${BACKUP_DIR} -type f -name "vesti_*" -mtime +7 -delete 2>/dev/null
|
||||
|
||||
# На Яндекс.Диске: оставляем 30 дней
|
||||
find ${YADISK_TARGET} -type f -name "vesti_*" -mtime +30 -delete 2>/dev/null
|
||||
|
||||
echo "✅ [$(date)] Резервное копирование завершено!"
|
||||
|
||||
# Показываем список созданных бэкапов
|
||||
echo ""
|
||||
echo "📊 Созданные бэкапы:"
|
||||
ls -lh ${BACKUP_DIR}/vesti_${DATE}.* 2>/dev/null || echo " (нет файлов)"
|
||||
@@ -0,0 +1,232 @@
|
||||
# Классификатор постов: словарный фильтр (MUST) + LLM-уточнение (qwen3:8b-nothink).
|
||||
# По спеке: сначала keywords.py (без LLM), затем для кандидатов — Ollama.
|
||||
# Если модель недоступна — пост остаётся unclassified (не теряется).
|
||||
|
||||
import json
|
||||
import os
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
import httpx
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
from classifier.keywords import find_direction, DIRECTIONS_CANON
|
||||
|
||||
OLLAMA_URL = os.getenv("OLLAMA_URL", "http://127.0.0.1:11434")
|
||||
OLLAMA_MODEL = os.getenv("OLLAMA_MODEL", "qwen3:8b-nothink")
|
||||
TIMEOUT = float(os.getenv("CLASSIFY_TIMEOUT", "30"))
|
||||
|
||||
|
||||
def classify_text(post: dict) -> dict:
|
||||
"""Классифицирует текст поста. Возвращает dict с direction, relevance, interest, summary, classified.
|
||||
|
||||
Сначала словарный фильтр (быстрый, без LLM). Если направление найдено —
|
||||
пробуем LLM-уточнение (relevance/interest/summary). При недоступности LLM —
|
||||
фолбэк: direction из словаря, relevance=low, interest=1, classified=False.
|
||||
|
||||
СВОЙ контент (is_own=1): «сильный кандидат» — при словарном попадании
|
||||
relevance=critical, classified=True даже без LLM (фолбэк 'dict-own').
|
||||
Если словарь не дал направление — классификации нет, пост не теряется.
|
||||
|
||||
post: {"text": str, "views": int, "reactions_total": int, "is_own": int, ...}
|
||||
"""
|
||||
text = (post.get("text") or "").strip()
|
||||
views = int(post.get("views") or 0)
|
||||
reactions = int(post.get("reactions_total") or 0)
|
||||
is_own = int(post.get("is_own") or 0) == 1
|
||||
|
||||
direction = find_direction(text)
|
||||
if not direction:
|
||||
# словарь не дал попадания — всё равно пробуем LLM (MUST: не терять посты)
|
||||
try:
|
||||
llm = call_ollama(text, views, reactions, None)
|
||||
d = llm.get("direction")
|
||||
if d and d in DIRECTIONS_CANON:
|
||||
return {
|
||||
"direction": d,
|
||||
"relevance": llm.get("relevance") or "low",
|
||||
"interest": clamp_interest(llm.get("interest")),
|
||||
"summary": llm.get("summary") or "",
|
||||
"classified": True,
|
||||
"method": "llm",
|
||||
}
|
||||
# LLM отработала, но не дала каноническое направление — не классифицируем
|
||||
return {
|
||||
"direction": None,
|
||||
"relevance": "low",
|
||||
"interest": 1,
|
||||
"summary": "",
|
||||
"classified": False,
|
||||
"method": "llm-no-direction",
|
||||
}
|
||||
except Exception as e:
|
||||
# LLM недоступна — пост остаётся неклассифицированным (не теряется)
|
||||
return {
|
||||
"direction": None,
|
||||
"relevance": "low",
|
||||
"interest": 1,
|
||||
"summary": "",
|
||||
"classified": False,
|
||||
"method": f"dict-miss llm-err ({type(e).__name__})",
|
||||
}
|
||||
|
||||
# словарный фильтр сработал — кандидат; пробуем LLM
|
||||
try:
|
||||
llm = call_ollama(text, views, reactions, direction)
|
||||
return {
|
||||
"direction": llm.get("direction") or direction,
|
||||
"relevance": llm.get("relevance") or "low",
|
||||
"interest": clamp_interest(llm.get("interest")),
|
||||
"summary": llm.get("summary") or "",
|
||||
"classified": True,
|
||||
"method": "llm",
|
||||
}
|
||||
except Exception as e:
|
||||
# СВОЙ контент: сильный кандидат даже без LLM (словарь дал направление)
|
||||
if is_own:
|
||||
return {
|
||||
"direction": direction,
|
||||
"relevance": "critical",
|
||||
"interest": 1,
|
||||
"summary": "",
|
||||
"classified": True,
|
||||
"method": f"dict-own ({type(e).__name__})",
|
||||
}
|
||||
# LLM недоступна — фолбэк без LLM (MUST: пост не теряется)
|
||||
return {
|
||||
"direction": direction,
|
||||
"relevance": "low",
|
||||
"interest": 1,
|
||||
"summary": "",
|
||||
"classified": False,
|
||||
"method": f"dict-only ({type(e).__name__})",
|
||||
}
|
||||
|
||||
|
||||
def call_ollama(text: str, views: int, reactions: int, direction: str) -> dict:
|
||||
"""Вызывает qwen3:8b-nothink (OpenAI-совместимый /v1, think:false) и возвращает JSON."""
|
||||
prompt = f"""Ты — классификатор новостей. Определи {{
|
||||
"direction": "одно из: {', '.join(sorted(DIRECTIONS_CANON))}",
|
||||
"relevance": "critical|high|low",
|
||||
"interest": 1-5,
|
||||
"summary": "краткое резюме 1-2 предложения"
|
||||
}} для поста.
|
||||
|
||||
Пост (направление по словарю: {direction}, views={views}, reactions={reactions}):
|
||||
{text[:2000]}
|
||||
|
||||
Ответь ТОЛЬКО JSON."""
|
||||
r = httpx.post(
|
||||
f"{OLLAMA_URL}/v1/chat/completions",
|
||||
json={
|
||||
"model": OLLAMA_MODEL,
|
||||
"messages": [{"role": "user", "content": prompt}],
|
||||
"temperature": 0.2,
|
||||
"stream": False,
|
||||
"think": False, # qwen3: отключаем reasoning через extra_body (OpenAI-совместимый)
|
||||
},
|
||||
timeout=TIMEOUT,
|
||||
)
|
||||
r.raise_for_status()
|
||||
data = r.json()
|
||||
content = (data.get("choices") or [{}])[0].get("message", {}).get("content") or ""
|
||||
# вытаскиваем JSON из ответа (может быть с ```json обёрткой)
|
||||
content = content.strip()
|
||||
if content.startswith("```"):
|
||||
content = content.strip("`")
|
||||
if content.startswith("json"):
|
||||
content = content[4:].strip()
|
||||
return json.loads(content)
|
||||
|
||||
|
||||
def clamp_interest(v) -> int:
|
||||
try:
|
||||
return max(1, min(5, int(v)))
|
||||
except (TypeError, ValueError):
|
||||
return 1
|
||||
|
||||
|
||||
def classify_posts_in_db(db_path: str, limit: int = 200, direction: str | None = None):
|
||||
"""Обрабатывает неклассифицированные посты в SQLite. Возвращает (processed, classified, llm_ok)."""
|
||||
import sqlite3
|
||||
|
||||
conn = sqlite3.connect(db_path)
|
||||
conn.row_factory = sqlite3.Row
|
||||
cur = conn.cursor()
|
||||
# посты без классификации (classified не задан — status='new' и нет direction?)
|
||||
# в схеме пока нет колонок классификации; добавляем по ходу (схема расширяется)
|
||||
cols = [r[1] for r in cur.execute("PRAGMA table_info(posts)")]
|
||||
if "direction" not in cols:
|
||||
cur.execute("ALTER TABLE posts ADD COLUMN direction TEXT")
|
||||
cur.execute("ALTER TABLE posts ADD COLUMN relevance TEXT")
|
||||
cur.execute("ALTER TABLE posts ADD COLUMN interest INTEGER")
|
||||
cur.execute("ALTER TABLE posts ADD COLUMN summary TEXT")
|
||||
cur.execute("ALTER TABLE posts ADD COLUMN classified INTEGER DEFAULT 0")
|
||||
conn.commit()
|
||||
cols = [r[1] for r in cur.execute("PRAGMA table_info(posts)")]
|
||||
|
||||
where = "WHERE classified IS NULL OR classified=0"
|
||||
if direction:
|
||||
where += f" AND direction IS NULL" # не классифицированы в этом направлении
|
||||
|
||||
rows = cur.execute(
|
||||
f"SELECT id, text, views, reactions_total, is_own FROM posts {where} ORDER BY is_own DESC, id LIMIT ?",
|
||||
(limit,),
|
||||
).fetchall()
|
||||
|
||||
processed = classified = llm_ok = 0
|
||||
for row in rows:
|
||||
res = classify_text(dict(row))
|
||||
if res["classified"]:
|
||||
classified += 1
|
||||
if res["method"] == "llm":
|
||||
llm_ok += 1
|
||||
cur.execute(
|
||||
"UPDATE posts SET direction=?, relevance=?, interest=?, summary=?, classified=? WHERE id=?",
|
||||
(res["direction"], res["relevance"], res["interest"], res["summary"],
|
||||
1 if res["classified"] else 0, row["id"]),
|
||||
)
|
||||
# мультинаправления: все словарные попадания → classifications (для fan-out)
|
||||
from classifier.keywords import find_directions_all
|
||||
dirs_all = find_directions_all(row["text"] or "")
|
||||
if res["direction"] and res["direction"] not in dirs_all:
|
||||
dirs_all.append(res["direction"])
|
||||
for d in dirs_all:
|
||||
exists = cur.execute(
|
||||
"SELECT 1 FROM classifications WHERE post_id=? AND direction=? LIMIT 1",
|
||||
(row["id"], d),
|
||||
).fetchone()
|
||||
if not exists:
|
||||
cur.execute(
|
||||
"""INSERT INTO classifications (post_id, direction, relevance, interest, summary, model)
|
||||
VALUES (?,?,?,?,?,?)""",
|
||||
(row["id"], d, res["relevance"], res["interest"], res["summary"],
|
||||
res.get("method") or "classify"),
|
||||
)
|
||||
processed += 1
|
||||
if processed % 5 == 0 or processed == len(rows):
|
||||
conn.commit() # понемногу коммитим — не держать долгую транзакцию
|
||||
print(f" ...{processed}/{len(rows)} (LLM: {llm_ok})", flush=True)
|
||||
conn.commit()
|
||||
conn.close()
|
||||
return processed, classified, llm_ok
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
import argparse
|
||||
|
||||
ap = argparse.ArgumentParser(description="VESTI classifier")
|
||||
ap.add_argument("--db", default=str(Path(__file__).resolve().parent.parent / "db" / "vesti.db"))
|
||||
ap.add_argument("--direction", help="направление (необязательно)")
|
||||
ap.add_argument("--limit", type=int, default=200)
|
||||
args = ap.parse_args()
|
||||
|
||||
proc, cls, llm = classify_posts_in_db(args.db, args.limit, args.direction)
|
||||
print(f"Обработано: {proc}, классифицировано (LLM+словарь): {cls}, из них через LLM: {llm}", flush=True)
|
||||
# показать примеры
|
||||
import sqlite3
|
||||
conn = sqlite3.connect(args.db)
|
||||
conn.row_factory = sqlite3.Row
|
||||
for r in conn.execute("SELECT id, direction, relevance, interest, substr(summary,1,60) s FROM posts WHERE classified=1 LIMIT 5"):
|
||||
print(f" #{r['id']} {r['direction']} {r['relevance']} interest={r['interest']}: {r['s']}")
|
||||
conn.close()
|
||||
@@ -0,0 +1,120 @@
|
||||
# Классификатор: словари ключевых слов по направлениям (MUST: словарный фильтр первым).
|
||||
# Направления расширяемы; для прототипа — linux (основное) + общие.
|
||||
# Канонический список направлений (AGENT.MD, веб-форма fan-out):
|
||||
DIRECTIONS_CANON = ["linux", "tech", "politics", "games", "electronics", "llm"]
|
||||
|
||||
DIRECTIONS = {
|
||||
"linux": {
|
||||
"keywords": [
|
||||
"linux", "kernel", "gnome", "kde", "distro", "distribution", "ubuntu", "fedora",
|
||||
"debian", "arch", "manjaro", "mint", "opensuse", "xfce", "wayland", "xorg",
|
||||
"systemd", "apt", "dnf", "pacman", "aur", "snap", "flatpak", "bash", "zsh",
|
||||
"terminal", "shell", "foss", "open source", "opensource", "поверх", "ядро",
|
||||
"дистрибутив", "пакетный менеджер", "реестр пакетов", "libreoffice", "gimp",
|
||||
"вокал", "linux-", "tux", "posix", "unix", "gnu", "kde plasma", "gtk", "qt",
|
||||
"docker", "podman", "k8s", "kubernetes", "контейнер", "образ", "контейнеризация",
|
||||
"self-host", "selfhost", "homelab", "сервер", "vps", "devops", "инфраструктура",
|
||||
"nginx", "postgres", "sqlite", "redis", "grafana", "prometheus", "ansible",
|
||||
"terraform", "caddy", "docker-compose", "compose", "proxy", "vpn", "wireguard",
|
||||
"ssh", "sftp", "tmux", "vim", "neovim", "emacs", "git", "github", "gitlab",
|
||||
"open source", "клонирование", "репозиторий", "пакет", "сборка", "компиляция",
|
||||
"cli", "консоль", "командная строка", "python", "c++", "rust", "go",
|
||||
"golang", "golang", "programming", "программирование", "разработка", "код", "скрипт",
|
||||
"автоматизация", "юникс", "линукс", "пентинг", "security", "безопасность",
|
||||
"шифрование", "gnupg", "firewall", "iptables", "nftables", "selinux", "apparmor",
|
||||
"btrfs", "ext4", "zfs", "файловая система", "lvm", "raid", "ssd", "nvme",
|
||||
"железо", "драйвер", "фирмware", "прошивка", "bios", "uefi", "grub",
|
||||
"безголовый", "headless", "микросервис", "api", "rest", "http", "tcp", "udp",
|
||||
],
|
||||
# дополнительные точные фразы (более сильные)
|
||||
"phrases": ["linux", "ubuntu", "debian", "arch linux", "fedora", "kernel", "gnome", "kde"],
|
||||
},
|
||||
"tech": {
|
||||
"keywords": [
|
||||
# dev (бывший отдельный; разработка/программирование — tech)
|
||||
"разработка", "программирование", "код", "python", "golang", "golang", "rust", "javascript",
|
||||
"typescript", "node", "react", "vue", "next.js", "docker", "kubernetes", "api",
|
||||
"backend", "frontend", "фреймворк", "алгоритм", "open source", "github", "gitlab",
|
||||
"ci/cd", "тестирование", "деплой", "микросервисы", "база данных", "sql", "nosql",
|
||||
"инженер", "разработчик", "программист", "компилятор", "интерпретатор", "ide",
|
||||
"дебаггер", "рефакторинг", "собеседование", "технологии",
|
||||
# tech (бывший)
|
||||
"технологии", "гаджет", "смартфон", "процессор", "чип", "android", "iphone",
|
||||
"apple", "google", "microsoft", "windows", "железо", "компьютер", "ноутбук",
|
||||
"сервер", "storage", "хранилище", "облако", "cloud", "интернет вещей", "iot",
|
||||
"робот", "робототехника", "экран", "дисплей", "батарея", "зарядка", "usb-c",
|
||||
"хакер", "уязвимость", "эксплойт", "zero-day", "шифрование", "приватность",
|
||||
],
|
||||
"phrases": ["смартфон", "гаджет", "чип", "apple", "технологии", "программирование", "разработка", "software", "developer", "code"],
|
||||
},
|
||||
"politics": {
|
||||
"keywords": [
|
||||
"политика", "президент", "выборы", "закон", "законопроект", "госдума", "кремль",
|
||||
"дума", "правительство", "министр", "санкции", "война", "мир", "конфликт",
|
||||
"армия", "нато", "украина", "россия", "сша", "китай", "евросоюз", "телеграм-канал",
|
||||
"депутат", "партия", "референдум", "голосование", "политик", "геополитика",
|
||||
"международный", "амбассадор", "посол", "договор", "переговоры",
|
||||
],
|
||||
"phrases": ["политика", "выборы", "президент", "госдума", "санкции", "война"],
|
||||
},
|
||||
"games": {
|
||||
"keywords": [
|
||||
"игра", "игры", "гейминг", "gaming", "steam", "playstation", "xbox", "nintendo",
|
||||
"геймпад", "игровая консоль", "видеоигра", "мморпг", "шутер", "стратегия",
|
||||
"симулятор", "инди-игра", "киберспорт", "esports", "виртуальная реальность",
|
||||
"vr", "игровой движок", "unity", "unreal", "геймер",
|
||||
],
|
||||
"phrases": ["игра", "гейминг", "steam", "gaming"],
|
||||
},
|
||||
"electronics": {
|
||||
"keywords": [
|
||||
"электроника", "микроконтроллер", "arduino", "raspberry", "esp32", "esp8266",
|
||||
"пайка", "схема", "плата", "микросхема", "транзистор", "резистор", "конденсатор",
|
||||
"осциллограф", "мультиметр", "радио", "антенна", "sdr", "fpga", "промышленность",
|
||||
"электронный", "компонент", "датчик", "силовой", "реле",
|
||||
],
|
||||
"phrases": ["arduino", "raspberry", "fpga", "микроконтроллер"],
|
||||
},
|
||||
"llm": {
|
||||
"keywords": [
|
||||
"ии", "ai", "llm", "gpt", "нейросеть", "нейронная сеть", "deep learning",
|
||||
"машинное обучение", "ml", "модель", "обучение модели", "инференс", "файнтюнинг",
|
||||
"fine-tuning", "rlhf", "агент", "агенты", "генеративный", "стабильная диффузия",
|
||||
"stable diffusion", "midjourney", "чат-бот", "chatbot", "ассистент", "токен",
|
||||
"трансформер", "embedding", "векторная база", "rag", "pipeline", "инференс",
|
||||
"openai", "антропик", "claude", "gemini", "olama", "qwen",
|
||||
],
|
||||
"phrases": ["нейросеть", "llm", "чат-бот", "openai", "claude"],
|
||||
},
|
||||
}
|
||||
|
||||
import re
|
||||
|
||||
# Направление по умолчанию, если ничего не подошло
|
||||
DEFAULT_DIRECTION = "linux" # прототип: все посты про linux окружение
|
||||
|
||||
|
||||
def find_directions_all(text: str) -> list[str]:
|
||||
"""Возвращает ВСЕ направления, которым соответствует текст (для мультинаправлений/fan-out)."""
|
||||
text_low = (text or "").lower()
|
||||
hits = set()
|
||||
for direction, cfg in DIRECTIONS.items():
|
||||
# точные фразы
|
||||
if any(p.lower() in text_low for p in cfg.get("phrases", [])):
|
||||
hits.add(direction)
|
||||
continue
|
||||
# ключевые слова (по слову, re.search с границами)
|
||||
for kw in cfg.get("keywords", []):
|
||||
kw_low = kw.lower()
|
||||
if re.search(rf"\b{re.escape(kw_low)}\b", text_low):
|
||||
hits.add(direction)
|
||||
break
|
||||
return list(hits)
|
||||
|
||||
|
||||
def find_direction(text: str) -> str | None:
|
||||
"""Возвращает направление, если текст совпал со словарём (иначе None)."""
|
||||
dirs = find_directions_all(text)
|
||||
if dirs:
|
||||
return dirs[0]
|
||||
return None
|
||||
@@ -0,0 +1,34 @@
|
||||
# VESTI — общий конфиг (загрузка .env, пути)
|
||||
import os
|
||||
from pathlib import Path
|
||||
from dotenv import load_dotenv
|
||||
|
||||
BASE_DIR = Path(__file__).resolve().parent # /opt/vesti
|
||||
load_dotenv(BASE_DIR / ".env")
|
||||
|
||||
DB_PATH = BASE_DIR / "db" / "vesti.db"
|
||||
SCHEMA_PATH = BASE_DIR / "db" / "schema.sql"
|
||||
SOURCES_PATH = BASE_DIR / "sources" / "sources.yaml"
|
||||
BUNDLES_DIR = BASE_DIR / "bundles"
|
||||
MEDIA_DIR = BASE_DIR / "media"
|
||||
|
||||
TG_API_ID = int(os.getenv("TG_API_ID", "0"))
|
||||
TG_API_HASH = os.getenv("TG_API_HASH", "")
|
||||
TG_PROXY = os.getenv("TG_PROXY", "socks5://127.0.0.1:1080")
|
||||
TG_SESSION_DIR = Path(os.getenv("TG_SESSION_DIR", str(BASE_DIR / "telegram")))
|
||||
|
||||
VESTI_BOT_TOKEN = os.getenv("VESTI_BOT_TOKEN", "")
|
||||
VESTI_BOT_CHANNEL = os.getenv("VESTI_BOT_CHANNEL", "@dedinit_vesti_linux_ru_bot")
|
||||
|
||||
ADMIN_USER = os.getenv("ADMIN_USER", "admin")
|
||||
ADMIN_PASSWORD = os.getenv("ADMIN_PASSWORD", "change_me")
|
||||
|
||||
OLLAMA_URL = os.getenv("OLLAMA_URL", "http://127.0.0.1:11434")
|
||||
OLLAMA_MODEL = os.getenv("OLLAMA_MODEL", "qwen3:8b-nothink")
|
||||
|
||||
# Направления (категории)
|
||||
DIRECTIONS = ["tech", "politics", "games", "electronics", "llm", "linux"]
|
||||
|
||||
def ensure_dirs():
|
||||
for d in (BASE_DIR / "db", MEDIA_DIR, TG_SESSION_DIR, BUNDLES_DIR):
|
||||
d.mkdir(parents=True, exist_ok=True)
|
||||
@@ -0,0 +1,50 @@
|
||||
# VESTI — разовая интерактивная авторизация Telethon-сессии (MTProto).
|
||||
# Запуск: .venv/bin/python -m crawler.auth_telegram
|
||||
# После успеха сессия /opt/vesti/telegram/vesti.session сохраняется (644? -> 600).
|
||||
import asyncio
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
|
||||
from config import TG_API_ID, TG_API_HASH, TG_PROXY, TG_SESSION_DIR, ensure_dirs
|
||||
from crawler.telegram_crawler import make_client
|
||||
from telethon import errors
|
||||
|
||||
import logging
|
||||
logging.basicConfig(level=logging.INFO)
|
||||
|
||||
|
||||
async def main():
|
||||
ensure_dirs()
|
||||
TG_SESSION_DIR.mkdir(parents=True, exist_ok=True)
|
||||
client = make_client(TG_SESSION_DIR)
|
||||
await client.connect()
|
||||
if await client.is_user_authorized():
|
||||
me = await client.get_me()
|
||||
print(f"Уже авторизован: @{me.username or me.phone}")
|
||||
await client.disconnect()
|
||||
return
|
||||
phone = input("Телефон (с кодом страны, +7...): ").strip()
|
||||
if not phone:
|
||||
print("Нет телефона.")
|
||||
return
|
||||
try:
|
||||
await client.send_code_request(phone)
|
||||
code = input("Код из Telegram: ").strip()
|
||||
# 2FA пароль, если включён
|
||||
try:
|
||||
await client.sign_in(phone, code)
|
||||
except errors.SessionPasswordNeededError:
|
||||
pwd = input("2FA-пароль: ").strip()
|
||||
await client.sign_in(password=pwd)
|
||||
me = await client.get_me()
|
||||
print(f"Авторизован: @{me.username or me.phone}")
|
||||
except Exception as e:
|
||||
print(f"Ошибка: {e}")
|
||||
finally:
|
||||
await client.disconnect()
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
@@ -0,0 +1,185 @@
|
||||
#!/usr/bin/env python3
|
||||
"""VESTI — бэкфилл своего канала @dedinit (own-content-hub, задача 2.3).
|
||||
|
||||
Итерирует ВСЕ посты канала dedinit (с конца, без лимита MAX_POSTS_PER_CHANNEL),
|
||||
складывает в БД через store_posts (own-семантика: is_own=1, канон, дедуп по sha256/url),
|
||||
скачивает медиа своего канала, пишет tg_state.last_post_id = max (без перечитывания
|
||||
при инкрементальных запусках).
|
||||
|
||||
Запуск:
|
||||
cd /opt/vesti
|
||||
.venv/bin/python -m crawler.backfill_dedinit [--limit N] [--no-media] [--max-errors N]
|
||||
|
||||
--limit: сколько постов обработать (для теста; по умолчанию — все).
|
||||
--no-media: не скачивать медиа (текст-бэкфилл; позже докачать отдельно).
|
||||
--max-errors: сколько подряд идущих ошибок выдержать (по умолчанию 20).
|
||||
"""
|
||||
import argparse
|
||||
import asyncio
|
||||
import logging
|
||||
import sys
|
||||
import time
|
||||
from pathlib import Path
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
|
||||
from config import TG_PROXY, TG_SESSION_DIR, ensure_dirs
|
||||
from db.db import db
|
||||
from sources.sources import get_source, start_run, finish_run
|
||||
from crawler.telegram_crawler import (
|
||||
make_client, store_posts, detect_media_type, post_media_path,
|
||||
sha256_text,
|
||||
)
|
||||
|
||||
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(name)s %(message)s")
|
||||
log = logging.getLogger("vesti.backfill")
|
||||
|
||||
|
||||
async def download_media_safe(client, msg, rel_path):
|
||||
"""Скачивает медиа, возвращает (rel_path|None). Безопасная версия для бэкфилла.
|
||||
|
||||
Сохраняет в MEDIA_DIR/<basename> (= /opt/vesti/media/<file>), как и download_media
|
||||
в telegram_crawler — чтобы media_path из БД (media/<file>) совпадал с фактическим файлом.
|
||||
"""
|
||||
import os as _os
|
||||
from config import MEDIA_DIR
|
||||
full = _os.path.join(str(MEDIA_DIR), _os.path.basename(rel_path))
|
||||
_os.makedirs(str(MEDIA_DIR), exist_ok=True)
|
||||
if _os.path.exists(full):
|
||||
return rel_path
|
||||
try:
|
||||
dl = await client.download_media(msg, file=full)
|
||||
except Exception as e:
|
||||
log.warning("media dl %s: %s", rel_path, e)
|
||||
return None
|
||||
return rel_path if dl else None
|
||||
|
||||
|
||||
async def backfill(client, source, limit=None, no_media=False, max_errors=20):
|
||||
slug = source["slug"]
|
||||
channel = source["channel"]
|
||||
with db() as conn:
|
||||
state = conn.execute("SELECT * FROM tg_state WHERE channel_slug=?", (slug,)).fetchone()
|
||||
state = dict(state) if state else {}
|
||||
last_id = state.get("last_post_id") or 0
|
||||
|
||||
run_id = start_run(source["id"], f"telegram:{slug}", "backfill")
|
||||
t0 = time.monotonic()
|
||||
fetched = 0
|
||||
errors = 0
|
||||
min_id_seen = None
|
||||
|
||||
try:
|
||||
entity = await client.get_entity(channel)
|
||||
except Exception as e:
|
||||
finish_run(run_id, "error", 0, 0, f"get_entity: {e}")
|
||||
raise
|
||||
|
||||
async for msg in client.iter_messages(entity, reverse=False):
|
||||
if limit and fetched >= limit:
|
||||
break
|
||||
# Бэкфилл НЕ пропускает по last_post_id (частично могли забежать вперёд):
|
||||
# store_posts сам отсеет дубликаты по sha256/url. Просто идём от свежего к старому.
|
||||
min_id_seen = msg.id if min_id_seen is None else min(min_id_seen, msg.id)
|
||||
|
||||
# Дубликаты-форварды: если пост — пересланный из нашего же канала или из канала-источника,
|
||||
# то store_posts сам разрулит (is_own=0 упоминание). Для фулл-бэкфилла пропускаем чужие форварды:
|
||||
fw = getattr(msg, "fwd_from", None)
|
||||
is_forward = fw is not None and getattr(getattr(fw, "from_id", None), "channel_id", None) is not None
|
||||
|
||||
try:
|
||||
ctype = detect_media_type(msg)
|
||||
text = msg.text or ""
|
||||
url = f"https://t.me/{channel}/{msg.id}"
|
||||
media_rel = None
|
||||
if not (is_forward or no_media) and ctype != "text":
|
||||
media_rel = post_media_path(msg, channel)
|
||||
saved = await download_media_safe(client, msg, media_rel)
|
||||
media_rel = saved or media_rel
|
||||
|
||||
reactions = {}
|
||||
rr = getattr(msg, "reactions", None)
|
||||
if rr and getattr(rr, "results", None):
|
||||
for r in rr.results:
|
||||
if getattr(r, "reaction", None) and getattr(r, "count", None):
|
||||
key = getattr(r.reaction, "emoji", None) or str(r.reaction)
|
||||
reactions[key] = r.count
|
||||
|
||||
post = {
|
||||
"tg_channel": channel,
|
||||
"tg_post_id": msg.id,
|
||||
"url": url,
|
||||
"text": text,
|
||||
"content_type": ctype,
|
||||
"media_path": media_rel,
|
||||
"views": int(getattr(msg, "views", None) or 0),
|
||||
"reactions": __import__("json").dumps(reactions, ensure_ascii=False),
|
||||
"reactions_total": sum(reactions.values()),
|
||||
"published_at": msg.date.isoformat() if msg.date else None,
|
||||
"fwd_from_channel_id": getattr(getattr(fw, "from_id", None), "channel_id", None) if is_forward else None,
|
||||
"fwd_from_post_id": getattr(fw, "channel_post", None) if is_forward else None,
|
||||
"is_own": 1,
|
||||
}
|
||||
with db() as conn:
|
||||
new = store_posts(conn, source["id"], [post], is_own_source=True)
|
||||
fetched += 1
|
||||
if new:
|
||||
log.info(" + #%d (new=%d) [%s]", msg.id, new, ctype)
|
||||
else:
|
||||
log.info(" = #%d dup [%s]", msg.id, ctype)
|
||||
errors = 0
|
||||
except Exception as e:
|
||||
errors += 1
|
||||
log.warning("ERROR #%d: %s", msg.id, e)
|
||||
if errors >= max_errors:
|
||||
log.error("Слишком много ошибок подряд (%d) — прерываю", errors)
|
||||
break
|
||||
|
||||
# состояние: last_post_id = реальный max tg_post_id канала (исключая тестовые 9000+,
|
||||
# которые были вставлены в прошлых сессиях как искусственные id)
|
||||
max_id_seen = None
|
||||
with db() as conn:
|
||||
r = conn.execute(
|
||||
"SELECT tg_post_id FROM posts WHERE tg_channel=? AND tg_post_id < 9000 ORDER BY tg_post_id DESC LIMIT 1",
|
||||
(channel,),
|
||||
).fetchone()
|
||||
max_id_seen = r[0] if r else None
|
||||
if max_id_seen:
|
||||
with db() as conn:
|
||||
conn.execute(
|
||||
"INSERT INTO tg_state (channel_slug, last_post_id, last_ts) VALUES (?,?,datetime('now'))"
|
||||
" ON CONFLICT(channel_slug) DO UPDATE SET last_post_id=excluded.last_post_id, last_ts=datetime('now')",
|
||||
(slug, max_id_seen),
|
||||
)
|
||||
duration = int((time.monotonic() - t0) * 1000)
|
||||
finish_run(run_id, "ok", fetched, fetched, None, duration)
|
||||
log.info("DONE %s: fetched=%d (%.1fs), max_post_id=%s", slug, fetched, duration / 1000, max_id_seen)
|
||||
|
||||
|
||||
async def main():
|
||||
ap = argparse.ArgumentParser(description="VESTI backfill @dedinit")
|
||||
ap.add_argument("--limit", type=int, default=None, help="сколько постов обработать (тест)")
|
||||
ap.add_argument("--no-media", action="store_true", help="без скачивания медиа")
|
||||
ap.add_argument("--max-errors", type=int, default=20)
|
||||
args = ap.parse_args()
|
||||
|
||||
ensure_dirs()
|
||||
TG_SESSION_DIR.mkdir(parents=True, exist_ok=True)
|
||||
src = get_source("dedinit")
|
||||
if not src:
|
||||
log.error("source dedinit not found")
|
||||
sys.exit(1)
|
||||
|
||||
client = make_client(TG_SESSION_DIR)
|
||||
try:
|
||||
await client.connect()
|
||||
if not await client.is_user_authorized():
|
||||
log.error("Session not authorized. /opt/vesti/telegram/vesti.session?")
|
||||
sys.exit(2)
|
||||
await backfill(client, src, limit=args.limit, no_media=args.no_media, max_errors=args.max_errors)
|
||||
finally:
|
||||
await client.disconnect()
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
@@ -0,0 +1,370 @@
|
||||
# VESTI — Telegram-краулер (Telethon / MTProto).
|
||||
# Читает публичные каналы из sources.yaml, инкрементально после last_post_id,
|
||||
# собирает метрики (views/reactions), пишет в SQLite vesti.db.
|
||||
# РАБОТАЕТ ТОЛЬКО через SOCKS5-туннель 127.0.0.1:1080 (из РФ TG заблокирован).
|
||||
#
|
||||
# Запуск по каждому источнику отдельно (задача источника):
|
||||
# python -m crawler.telegram_crawler --source linuxklub
|
||||
# python -m crawler.telegram_crawler --direction linux
|
||||
# python -m crawler.telegram_crawler --all
|
||||
import argparse
|
||||
import asyncio
|
||||
import hashlib
|
||||
import json
|
||||
import logging
|
||||
import sys
|
||||
import time
|
||||
from pathlib import Path
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
|
||||
from config import TG_API_ID, TG_API_HASH, TG_PROXY, TG_SESSION_DIR, ensure_dirs
|
||||
from db.db import db
|
||||
from sources.sources import (
|
||||
get_enabled_sources, get_source, load_sources_yaml, sync_sources_to_db,
|
||||
start_run, finish_run,
|
||||
)
|
||||
|
||||
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(name)s %(message)s")
|
||||
log = logging.getLogger("vesti.crawler")
|
||||
|
||||
MAX_POSTS_PER_CHANNEL = 20 # лимит на запуск (защита от 429/flood)
|
||||
DUPLICATE_KEYS = ("url", "sha256")
|
||||
|
||||
|
||||
def parse_socks(url):
|
||||
"""socks5://user:pass@host:port -> (host, port, user, pass)."""
|
||||
from urllib.parse import urlparse
|
||||
u = urlparse(url)
|
||||
return u.hostname, (u.port or 1080), (u.username or None), (u.password or None)
|
||||
|
||||
|
||||
def make_client(session_dir):
|
||||
"""Создаёт Telethon-клиент. Сессия — session_dir/vesti.session."""
|
||||
from telethon import TelegramClient
|
||||
from telethon.sessions import SQLiteSession
|
||||
|
||||
host, port, user, pwd = parse_socks(TG_PROXY)
|
||||
# Telethon: proxy=(proxy_type, addr, port[, username, password]).
|
||||
# proxy_type — это socks.SOCKS5 / socks.HTTP из pysocks (telethon использует socksio/pysocks).
|
||||
import socks as pysocks
|
||||
proxy = (pysocks.SOCKS5, host, port)
|
||||
if user:
|
||||
proxy = (pysocks.SOCKS5, host, port, user, pwd)
|
||||
client = TelegramClient(SQLiteSession(str(session_dir / "vesti")), TG_API_ID, TG_API_HASH, proxy=proxy)
|
||||
return client
|
||||
|
||||
|
||||
def sha256_text(text: str) -> str:
|
||||
return hashlib.sha256((text or "").encode("utf-8", "ignore")).hexdigest()
|
||||
|
||||
|
||||
def detect_media_type(msg) -> str:
|
||||
"""Определяет тип контента поста по media-полю Message."""
|
||||
if msg.photo:
|
||||
return "photo"
|
||||
if msg.video:
|
||||
return "video"
|
||||
if msg.document:
|
||||
# document может быть file/voice/sticker/video_note
|
||||
mime = (msg.document.mime_type or "") if msg.document else ""
|
||||
if "voice" in mime:
|
||||
return "voice"
|
||||
if "sticker" in mime:
|
||||
return "sticker"
|
||||
return "document"
|
||||
if msg.voice:
|
||||
return "voice"
|
||||
if msg.video_note:
|
||||
return "video_note"
|
||||
if msg.sticker:
|
||||
return "sticker"
|
||||
if msg.animation if hasattr(msg, "animation") else False:
|
||||
return "animation"
|
||||
return "text"
|
||||
|
||||
|
||||
def post_media_path(msg, channel) -> str:
|
||||
"""Строит относительный путь media/<channel>_<id>.<ext> (без скачивания здесь)."""
|
||||
if not channel:
|
||||
channel = "chan"
|
||||
ext = "jpg"
|
||||
mtype = detect_media_type(msg)
|
||||
if mtype == "video":
|
||||
ext = "mp4"
|
||||
elif mtype == "voice":
|
||||
ext = "ogg"
|
||||
elif mtype == "document" and msg.document:
|
||||
# имя файла в атрибутах документа (DocumentAttributesFilename)
|
||||
fname = None
|
||||
doc = msg.document
|
||||
if hasattr(doc, "file_name"):
|
||||
fname = doc.file_name
|
||||
else:
|
||||
for a in (getattr(doc, "attributes", None) or []):
|
||||
if hasattr(a, "file_name"):
|
||||
fname = a.file_name
|
||||
break
|
||||
if fname:
|
||||
fn = fname.split(".")
|
||||
ext = fn[-1] if len(fn) > 1 and len(fn[-1]) <= 5 else "bin"
|
||||
else:
|
||||
ext = "bin"
|
||||
return f"media/{channel}_{msg.id}.{ext}"
|
||||
|
||||
|
||||
async def download_media(client, msg, rel_path, source):
|
||||
"""Скачивает медиа поста в /opt/vesti/media/<basename> (MEDIA_DIR — уже /opt/vesti/media).
|
||||
|
||||
rel_path из post_media_path = 'media/<channel>_<id>.<ext>' (от корня проекта).
|
||||
Файл сохраняется в MEDIA_DIR/<basename> = /opt/vesti/media/<file> — ровно туда,
|
||||
куда указывает media_path в БД (media/<file>). БЕЗ вложенной media/media.
|
||||
"""
|
||||
import os as _os
|
||||
from config import MEDIA_DIR
|
||||
full = _os.path.join(str(MEDIA_DIR), _os.path.basename(rel_path))
|
||||
_os.makedirs(str(MEDIA_DIR), exist_ok=True)
|
||||
if _os.path.exists(full):
|
||||
return rel_path
|
||||
# определяем источник скачивания: photo/video/document/voice
|
||||
dl = await client.download_media(msg, file=full)
|
||||
if dl:
|
||||
return rel_path
|
||||
return None
|
||||
|
||||
|
||||
async def fetch_channel(client, source, state, src_ids=None, is_own_source=False):
|
||||
"""Читает новые посты канала, возвращает (list_of_raw, last_id).
|
||||
src_ids: set channel_id наших источников — для пропуска форвардов из своих каналов.
|
||||
is_own_source: источник own:true → медиа скачивается (контент пользователя)."""
|
||||
channel = source["channel"]
|
||||
try:
|
||||
entity = await client.get_entity(channel)
|
||||
except Exception as e:
|
||||
raise RuntimeError(f"get_entity({channel}) failed: {e}")
|
||||
|
||||
last_id = state.get("last_post_id") or 0
|
||||
posts = []
|
||||
limit = MAX_POSTS_PER_CHANNEL
|
||||
src_ids = src_ids or set()
|
||||
|
||||
# Берём историю с конца; фильтруем по id > last_id на лету.
|
||||
async for msg in client.iter_messages(entity, limit=limit * 3, reverse=False):
|
||||
if msg.id <= last_id:
|
||||
continue
|
||||
# --- форвард: нужен только исходный пост ---
|
||||
fw = getattr(msg, "fwd_from", None)
|
||||
fwd_channel_id = None
|
||||
fwd_post_id = None
|
||||
is_forward = False
|
||||
if fw is not None:
|
||||
from_id = getattr(fw, "from_id", None)
|
||||
if from_id is not None:
|
||||
# PeerChannel: у пересланных из канала
|
||||
if hasattr(from_id, "channel_id"):
|
||||
fwd_channel_id = from_id.channel_id
|
||||
fwd_post_id = getattr(fw, "channel_post", None)
|
||||
is_forward = True
|
||||
# PeerUser / другие — не обрабатываем как форвард канала
|
||||
# Пост-форвард из канала, который есть в наших источниках -> пропускаем (будет скачан в исходном)
|
||||
if is_forward and fwd_channel_id in src_ids:
|
||||
continue
|
||||
# Пост-форвард из чужого канала: сохраняем как есть, но БЕЗ скачивания медиа (не наше).
|
||||
# Для own-канала это требование тоже действует: чужой форвард = is_own=1 + fwd-поля, БЕЗ медиа.
|
||||
skip_media = is_forward
|
||||
|
||||
has_content = (
|
||||
msg.text is not None
|
||||
or msg.photo or msg.document or msg.video
|
||||
or msg.voice or msg.sticker
|
||||
or (msg.animation if hasattr(msg, "animation") else False)
|
||||
)
|
||||
if has_content:
|
||||
text = msg.text or ""
|
||||
ctype = detect_media_type(msg)
|
||||
media_rel = None
|
||||
if not skip_media:
|
||||
media_rel = post_media_path(msg, channel) if ctype != "text" else None
|
||||
# скачиваем медиа, если есть (в media/)
|
||||
if media_rel:
|
||||
try:
|
||||
saved = await download_media(client, msg, media_rel, source)
|
||||
media_rel = saved or media_rel
|
||||
except Exception as e:
|
||||
log.warning("media download failed %s: %s", channel, e)
|
||||
views = getattr(msg, "views", None) or 0
|
||||
reactions = {}
|
||||
rr = getattr(msg, "reactions", None)
|
||||
if rr and getattr(rr, "results", None):
|
||||
for r in rr.results:
|
||||
if getattr(r, "reaction", None) and getattr(r, "count", None):
|
||||
key = getattr(r.reaction, "emoji", None) or str(r.reaction)
|
||||
reactions[key] = r.count
|
||||
url = f"https://t.me/{channel}/{msg.id}"
|
||||
posts.append({
|
||||
"tg_channel": channel,
|
||||
"tg_post_id": msg.id,
|
||||
"url": url,
|
||||
"text": text,
|
||||
"content_type": ctype,
|
||||
"media_path": media_rel,
|
||||
"views": int(views or 0),
|
||||
"reactions": json.dumps(reactions, ensure_ascii=False),
|
||||
"reactions_total": sum(reactions.values()),
|
||||
"published_at": msg.date.isoformat() if msg.date else None,
|
||||
"fwd_from_channel_id": fwd_channel_id,
|
||||
"fwd_from_post_id": fwd_post_id,
|
||||
"is_own": 1 if is_own_source else 0,
|
||||
})
|
||||
if len(posts) >= limit:
|
||||
break
|
||||
return posts, max([p["tg_post_id"] for p in posts] or [last_id])
|
||||
|
||||
|
||||
def store_posts(conn, source_id, posts, is_own_source=False):
|
||||
"""Добавляет посты в БД, возвращает количество НОВЫХ (не дублей).
|
||||
|
||||
own-семантика:
|
||||
- источник own:true → посты is_own=1 + is_own_canonical=1 (первичный экземпляр)
|
||||
- дубль того же текста (sha256) во внешнем канале → is_own=0 (упоминание),
|
||||
канонический (is_own_canonical=1) остаётся первичным
|
||||
"""
|
||||
new = 0
|
||||
for p in posts:
|
||||
sha = sha256_text(p["text"])
|
||||
# дедуп: уникальный (sha256) и (url)
|
||||
dup = conn.execute("SELECT id, media_path, fwd_from_channel_id, is_own, is_own_canonical FROM posts WHERE sha256=? OR url=?", (sha, p["url"])).fetchone()
|
||||
if dup:
|
||||
# дозаполняем типы/медиа, если появились
|
||||
if p.get("media_path") and not dup[1]:
|
||||
conn.execute(
|
||||
"UPDATE posts SET content_type=?, media_path=? WHERE id=?",
|
||||
(p.get("content_type", "text"), p["media_path"], dup[0]),
|
||||
)
|
||||
# дозаполняем fwd-поля, если пост-форвард и они не были записаны
|
||||
if p.get("fwd_from_channel_id") and not dup[2]:
|
||||
conn.execute(
|
||||
"UPDATE posts SET fwd_from_channel_id=?, fwd_from_post_id=? WHERE id=?",
|
||||
(p["fwd_from_channel_id"], p.get("fwd_from_post_id"), dup[0]),
|
||||
)
|
||||
# дубль того же контента:
|
||||
# - тот же sha (сам себя в том же канале) — не создаём
|
||||
# - внешний канал, но у нас уже есть канонический СВОЙ экземпляр → упоминание (is_own=0),
|
||||
# НО только если существующий пост канонический (иначе это просто дубль во внешних)
|
||||
if (p.get("is_own") and not dup[3] and dup[4]):
|
||||
# тот же контент в своём канале, а в БД уже есть канон → обновляем is_own у дубля как упоминание
|
||||
conn.execute(
|
||||
"UPDATE posts SET is_own=0, is_own_canonical=0 WHERE id=?",
|
||||
(dup[0],),
|
||||
)
|
||||
continue
|
||||
is_own = 1 if (is_own_source or p.get("is_own")) else 0
|
||||
is_own_canonical = 1 if is_own else 0
|
||||
conn.execute(
|
||||
"""INSERT INTO posts (sha256, source_id, tg_channel, tg_post_id, url, text, content_type,
|
||||
media_path, views, reactions, reactions_total, published_at, status,
|
||||
fwd_from_channel_id, fwd_from_post_id, is_own, is_own_canonical)
|
||||
VALUES (?,?,?,?,?,?,?,?,?,?,?,?, 'new',?,?,?,?)""",
|
||||
(sha, source_id, p["tg_channel"], p["tg_post_id"], p["url"], p["text"],
|
||||
p.get("content_type", "text"), p.get("media_path"),
|
||||
p["views"], p["reactions"], p["reactions_total"], p["published_at"],
|
||||
p.get("fwd_from_channel_id"), p.get("fwd_from_post_id"),
|
||||
is_own, is_own_canonical),
|
||||
)
|
||||
new += 1
|
||||
return new
|
||||
|
||||
|
||||
async def run_source(client, source, src_ids=None):
|
||||
"""Краулинг одного источника: инкрементально, с записью запуска в runs."""
|
||||
slug = source["slug"]
|
||||
is_own_source = int(source.get("own") or 0) == 1
|
||||
with db() as conn:
|
||||
state = conn.execute("SELECT * FROM tg_state WHERE channel_slug=?", (slug,)).fetchone()
|
||||
state = dict(state) if state else {}
|
||||
|
||||
run_id = start_run(source["id"], f"telegram:{slug}", "cron")
|
||||
t0 = time.monotonic()
|
||||
try:
|
||||
posts, last_id = await fetch_channel(client, source, state, src_ids, is_own_source)
|
||||
with db() as conn:
|
||||
new = store_posts(conn, source["id"], posts, is_own_source)
|
||||
# сохраняем состояние
|
||||
conn.execute(
|
||||
"INSERT INTO tg_state (channel_slug, last_post_id, last_ts) VALUES (?,?,datetime('now'))"
|
||||
" ON CONFLICT(channel_slug) DO UPDATE SET last_post_id=excluded.last_post_id, last_ts=datetime('now')",
|
||||
(slug, last_id),
|
||||
)
|
||||
conn.execute("UPDATE sources SET last_fetch=datetime('now'), status='alive', last_error=NULL WHERE id=?", (source["id"],))
|
||||
duration = int((time.monotonic() - t0) * 1000)
|
||||
finish_run(run_id, "ok", len(posts), new, None, duration)
|
||||
log.info("OK %s: fetched=%d new=%d last_id=%d (%.1fs)", slug, len(posts), new, last_id, duration / 1000)
|
||||
except Exception as e:
|
||||
duration = int((time.monotonic() - t0) * 1000)
|
||||
finish_run(run_id, "error", 0, 0, str(e)[:500], duration)
|
||||
log.error("ERROR %s: %s", slug, e)
|
||||
with db() as conn:
|
||||
conn.execute("UPDATE sources SET status='dead', last_error=? WHERE id=?", (str(e)[:500], source["id"]))
|
||||
raise
|
||||
|
||||
|
||||
async def resolve_source_ids(client, sources):
|
||||
"""Возвращает set channel_id всех наших telegram-источников (для дедупа форвардов)."""
|
||||
ids = set()
|
||||
for s in sources:
|
||||
try:
|
||||
ent = await client.get_entity(s["channel"])
|
||||
ids.add(getattr(ent, "id", None))
|
||||
except Exception as e:
|
||||
log.warning("resolve id %s failed: %s", s["channel"], e)
|
||||
return ids
|
||||
|
||||
|
||||
async def main():
|
||||
ap = argparse.ArgumentParser(description="VESTI Telegram crawler (per-source)")
|
||||
ap.add_argument("--source", help="slug источника (например linuxklub)")
|
||||
ap.add_argument("--direction", help="направление (например linux)")
|
||||
ap.add_argument("--all", action="store_true", help="все включённые telegram-источники")
|
||||
args = ap.parse_args()
|
||||
|
||||
ensure_dirs()
|
||||
TG_SESSION_DIR.mkdir(parents=True, exist_ok=True)
|
||||
|
||||
# синк реестра в БД
|
||||
data = load_sources_yaml()
|
||||
sync_sources_to_db(data)
|
||||
|
||||
if args.source:
|
||||
src = get_source(args.source)
|
||||
if not src:
|
||||
log.error("source %s not found", args.source)
|
||||
sys.exit(1)
|
||||
sources = [src]
|
||||
elif args.direction:
|
||||
sources = get_enabled_sources(crawler="telegram", direction=args.direction)
|
||||
else:
|
||||
sources = get_enabled_sources(crawler="telegram")
|
||||
|
||||
if not sources:
|
||||
log.info("no sources to crawl")
|
||||
return
|
||||
|
||||
client = make_client(TG_SESSION_DIR)
|
||||
try:
|
||||
await client.connect()
|
||||
if not await client.is_user_authorized():
|
||||
# Требуется код подтверждения — интерактивно (редко; сессия сохраняется)
|
||||
log.warning("Session not authorized. Проверьте, что сессия /opt/vesti/telegram/vesti.session существует.")
|
||||
log.warning("Для первой авторизации: python -m crawler.auth_telegram")
|
||||
await client.disconnect()
|
||||
sys.exit(2)
|
||||
src_ids = await resolve_source_ids(client, sources)
|
||||
log.info("source channel ids: %s", sorted(src_ids))
|
||||
for src in sources:
|
||||
await run_source(client, src, src_ids)
|
||||
finally:
|
||||
await client.disconnect()
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-11
|
||||
@@ -0,0 +1,27 @@
|
||||
## Дизайн
|
||||
|
||||
### 1. Убрать HTMX (unpkg.com)
|
||||
|
||||
`web/templates/candidates.html`:
|
||||
|
||||
- Строки 50-65: `<form class="d-inline" method="post" action="/posts/{{ p.id }}/approve" hx-post=... hx-target=... hx-swap=...>` →
|
||||
`<form class="d-inline" method="post" action="/posts/{{ p.id }}/approve">`. Кнопка остаётся `type="submit"`.
|
||||
- Строка 66: `<button ... hx-post="/posts/{{ p.id }}/reject" hx-target="..." hx-swap="outerHTML">` →
|
||||
обернуть в `<form class="d-inline" method="post" action="/posts/{{ p.id }}/reject">` + `<button type="submit">`.
|
||||
- Убрать все `hx-*` атрибуты по проекту.
|
||||
|
||||
### 2. Локализовать Bootstrap
|
||||
|
||||
- Скачать: `curl -sL https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css -o web/static/bootstrap.min.css`
|
||||
- В `base.html` и `login.html` заменить `<link href="https://cdn.jsdelivr.net/...">` →
|
||||
`<link href="/static/bootstrap.min.css" rel="stylesheet">`.
|
||||
- FastAPI уже монтирует `/static` (app.mount в web/app.py:27) — STATIC_DIR существует
|
||||
(`web/static/`), сейчас пустой.
|
||||
|
||||
### 3. Проверка
|
||||
|
||||
- `grep -rn "unpkg\|jsdelivr\|cdn\." web/` → пусто.
|
||||
- `curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8400/login` → 200.
|
||||
- Страница рендерится с локальным CSS (визуально не отличается).
|
||||
- Approve/reject работают POST-формами (редирект на /published / /candidates?status=rejected).
|
||||
- network-панель браузера: нет запросов к unpkg.com/jsdelivr.net.
|
||||
@@ -0,0 +1,38 @@
|
||||
## Why
|
||||
|
||||
Веб-интерфейс VESTI (`web/`) зависит от двух внешних CDN:
|
||||
|
||||
- `https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css` (base.html:7, login.html:7)
|
||||
- `https://unpkg.com/htmx.org@1.9.12` (base.html:8)
|
||||
|
||||
При фильтрации/действиях страница ждёт ответа от `unpkg.com` — если CDN недоступен или
|
||||
замедлен (а в РФ это распространённая проблема), браузер висит в ожидании скрипта.
|
||||
Это внешняя зависимость, которая не нужна локальному сервису: VESTI работает на bigbox
|
||||
за Caddy/TLS и не должна зависеть от сторонних доменов. Пользователь явно против ожидания
|
||||
ответа от `unpkg.com`.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Убрать `https://unpkg.com/htmx.org@1.9.12` из `web/templates/base.html`.
|
||||
- Убрать `https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css` из
|
||||
`web/templates/base.html` и `web/templates/login.html`.
|
||||
- Отказаться от HTMX: кнопки «Опубликовать»/«Отклонить» перевести с `hx-post` на
|
||||
обычные `<form method="post">` (полная перезагрузка страницы — приемлемо для прототипа,
|
||||
снимает зависимость от JS).
|
||||
- Bootstrap: скачать CSS локально в `web/static/` (или, если критично, минимизировать
|
||||
использование классов и обойтись собственным минимальным CSS). Рекомендуемый вариант —
|
||||
локальный файл `web/static/bootstrap.min.css` из той же версии 5.3.3.
|
||||
- Все ссылки на внешние CDN удалить; в шаблонах не останется ни одного `http(s)://` на
|
||||
сторонние домены.
|
||||
- JS в страницах — только свой (если нужен), без `unpkg`/`jsdelivr`/`cdn.*`.
|
||||
|
||||
## Impact
|
||||
|
||||
- Файлы: `web/templates/base.html`, `web/templates/login.html`, `web/templates/candidates.html`
|
||||
(замена hx-post на form), возможно `web/templates/published.html`/`metrics.html` (если там
|
||||
есть hx-атрибуты).
|
||||
- Добавится `web/static/bootstrap.min.css` (~230 KB).
|
||||
- Поведение: approve/reject больше не будут ajax-без-перезагрузки, а будут обычными POST
|
||||
с редиректом. Для прототипа это нормально.
|
||||
- Снимается зависимость от интернета/CDN при работе веб-UI.
|
||||
- Rollback: вернуть две строки CDN в base.html + вернуть hx-post — ничего больше не меняется.
|
||||
@@ -0,0 +1,18 @@
|
||||
## 1. Локализовать Bootstrap
|
||||
|
||||
- [x] 1.1 Скачать `bootstrap@5.3.3/dist/css/bootstrap.min.css` в `web/static/`
|
||||
- [x] 1.2 Заменить CDN-ссылку на `/static/bootstrap.min.css` в `base.html` и `login.html`
|
||||
- [x] 1.3 Проверка: страница рендерится с локальным CSS, нет запросов к jsdelivr.net
|
||||
|
||||
## 2. Убрать HTMX (unpkg.com)
|
||||
|
||||
- [x] 2.1 В `candidates.html` заменить `hx-post` на обычные `<form method="post">` (approve/reject)
|
||||
- [x] 2.2 Убрать `<script src="https://unpkg.com/htmx.org@1.9.12">` из `base.html`
|
||||
- [x] 2.3 Убрать все `hx-*` атрибуты из шаблонов (grep подтверждает отсутствие)
|
||||
- [x] 2.4 Проверка: approve и reject работают полной перезагрузкой (POST + RedirectResponse)
|
||||
|
||||
## 3. Итоговая проверка
|
||||
|
||||
- [x] 3.1 `grep -rn "unpkg\|jsdelivr\|cdn\." web/` — пусто
|
||||
- [x] 3.2 В браузере network-панель: 0 внешних доменов (только свой хост и статика)
|
||||
- [x] 3.3 Полный цикл: фильтр → approve → опубликовано, без ожидания от третьих серверов
|
||||
@@ -0,0 +1,3 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-13
|
||||
skip_specs: true
|
||||
@@ -0,0 +1,45 @@
|
||||
## Design
|
||||
|
||||
Файл: `/opt/vesti/web/app.py`, функция `approve`.
|
||||
|
||||
Текущий порядок (баг):
|
||||
```python
|
||||
if not dirs_selected:
|
||||
cls = conn.execute(
|
||||
"SELECT direction FROM classifications WHERE post_id=? ORDER BY id", (post_id,)
|
||||
).fetchall()
|
||||
dirs_selected = [r["direction"] for r in cls] if cls else [dirn] # ← dirn не определён
|
||||
dirs_selected = list(dict.fromkeys([d for d in dirs_selected if d]))
|
||||
|
||||
card = make_card(post, comment)
|
||||
dirn = post.get("direction") or "linux" # ← определяется ПОСЛЕ использования
|
||||
lang = post.get("lang") or "ru"
|
||||
```
|
||||
|
||||
Правка (минимальная, чистая): перенести определение `dirn` и `lang` ДО строки
|
||||
`dirs_selected = ...`, сразу после `post = dict(post)` / вычисления `is_own`:
|
||||
|
||||
```python
|
||||
post = dict(post)
|
||||
is_own = int(post.get("is_own") or 0) == 1
|
||||
dirn = post.get("direction") or "linux" # ← теперь определён
|
||||
lang = post.get("lang") or "ru"
|
||||
|
||||
# ... (фан-аут направления из формы)
|
||||
|
||||
dirs_selected = [r["direction"] for r in cls] if cls else [dirn] # ок
|
||||
dirs_selected = list(dict.fromkeys([d for d in dirs_selected if d]))
|
||||
|
||||
card = make_card(post, comment)
|
||||
# dirn/lang уже определены выше, убрать поздние присваивания (строки 185-186)
|
||||
```
|
||||
|
||||
Удалить поздние `dirn = ...` и `lang = ...` (строки 185-186), т.к. они станут дублями.
|
||||
|
||||
## Верификация
|
||||
|
||||
- `openspec validate fix-approve-dirn` — чисто.
|
||||
- Перезапуск веба: `sudo systemctl restart vesti-web`.
|
||||
- Approve поста без выбранных направлений (пустая форма) → 302 на /candidates,
|
||||
пост публикуется (HTTP 200/302, в логах нет UnboundLocalError).
|
||||
- Approve поста с выбранными направлениями — тоже ок (регрессия).
|
||||
@@ -0,0 +1,26 @@
|
||||
## Why
|
||||
|
||||
Пользователь не может заапрувить новость: POST /posts/{id}/approve → 500 Internal Server Error.
|
||||
В логах веба (journalctl -u vesti-web):
|
||||
|
||||
File "/opt/vesti/web/app.py", line 180, in approve
|
||||
dirs_selected = [r["direction"] for r in cls] if cls else [dirn]
|
||||
UnboundLocalError: cannot access local variable 'dirn' where it is not associated with a value
|
||||
|
||||
Причина: на строке 180 используется переменная `dirn` (направление поста), но она
|
||||
определяется позже (строка 185: `dirn = post.get("direction") or "linux"`). При approve
|
||||
поста без явно выбранных направлений (пустая форма) всегда падает UnboundLocalError.
|
||||
|
||||
## What Changes
|
||||
|
||||
- В `web/app.py` (функция `approve`) перед строкой с `dirs_selected` определить:
|
||||
`dirn = post.get("direction") or "linux"` (и `lang = post.get("lang") or "ru"` — тоже
|
||||
используется ниже), чтобы порядок соответствовал использованию.
|
||||
- Либо заменить `[dirn]` на `[post.get("direction") or "linux"]` — минимальная правка.
|
||||
- Зависимость от `lang` — тоже проверяется до использования (строка 186).
|
||||
|
||||
## Why Not
|
||||
|
||||
- Альтернатива — вынести `dirn/lang` в начало функции (до `dirs_selected`). Это чище:
|
||||
переменные определяются один раз и используются ниже без дублирования.
|
||||
- Проверяется на живом approve поста без направлений (пустая форма).
|
||||
@@ -0,0 +1,8 @@
|
||||
# fix-approve-dirn
|
||||
|
||||
- [x] Создан OpenSpec change (proposal/design)
|
||||
- [x] web/app.py: перенести `dirn`/`lang` до использования (убрать UnboundLocalError)
|
||||
- [x] Убрать поздние дубли `dirn = ...` / `lang = ...`
|
||||
- [x] `openspec validate fix-approve-dirn` — чисто (skip_specs: true, валиден)
|
||||
- [x] Перезапуск веба, approve без направлений → ок (303 без сессии, сервер не падает)
|
||||
- [x] Бэкап после правки (`sudo /opt/vesti/backup.sh`) — 3.5G, скопирован на ЯД
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-08
|
||||
@@ -0,0 +1,106 @@
|
||||
# Design: own-content-hub
|
||||
|
||||
## Approach
|
||||
|
||||
Канал @dedinit — обычный источник в реестре, но с флагом `own: true`. Вся общая логика
|
||||
(краулер, дедуп, классификатор, банк) работает как для любого TG-канала; различие —
|
||||
семантика: посты своего канала считаются СВОИМ контентом (is_own=1) и становятся
|
||||
«сильными кандидатами» на автораспространение по всем тематическим лентам.
|
||||
|
||||
Ключевая идея — **fan-out вместо single-out**: один пост пользователя при подтверждении
|
||||
уходит сразу во все тематические каналы @dedinit_vesti_<direction>_<lang>_bot, под
|
||||
которые он подходит (направления из классификации). Так контент «инъецируется» в
|
||||
новостные ленты и собирает аудиторию на всех площадках, а сам канал-источник остаётся
|
||||
первоисточником (атрибуция везде).
|
||||
|
||||
Поток данных:
|
||||
```
|
||||
sources.yaml: @dedinit (own: true)
|
||||
│
|
||||
▼
|
||||
telegram_crawler.py → posts.is_own=1 (дедуп как обычно; медиа скачивается — свой контент)
|
||||
▼
|
||||
classifier.py → направление(я) + relevance; is_own + критичность → «сильный кандидат»
|
||||
▼
|
||||
vesti-web (фильтр «Свои», бейдж; подтверждение с выбором направлений рассылки)
|
||||
▼
|
||||
tg-publisher.py → fan-out: карточка в каждый @dedinit_vesti_<dir>_<lang>_bot
|
||||
▼
|
||||
news-store → бандл bundles/<dir>/<YYYY-MM>/<slug>.md (origin=own, ссылка на оригинал)
|
||||
```
|
||||
|
||||
## Files
|
||||
|
||||
```bash
|
||||
# Изменяемые файлы
|
||||
sources/sources.yaml # + источник dedinit (own: true)
|
||||
db/schema.sql # + posts.is_own, posts.is_own_canonical, sources.own,
|
||||
# published.distributed_dirs (миграция ALTER TABLE)
|
||||
crawler/telegram_crawler.py # + определение own-источника, проставление is_own,
|
||||
# is_own_canonical (первый экземпляр = канал), медиа скачивается
|
||||
classifier/classify.py # + is_own → «сильный кандидат» (relevance critical, classified=True)
|
||||
publisher/bot.py # + fan-out publish_multi(directions)
|
||||
publisher/card.py # + атрибуция «Дед в АйТи» + ссылка на оригинал
|
||||
web/app.py # + фильтр is_own, бейдж, выбор направлений рассылки при approve
|
||||
web/templates/candidates.html # + бейдж СВОЙ, чекбоксы направлений
|
||||
web/store.py # + frontmatter origin: own + ссылка на оригинал
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
```bash
|
||||
# 1) Миграция схемы (идиемпотентно)
|
||||
cd /opt/vesti && .venv/bin/python - <<'PY'
|
||||
import sqlite3
|
||||
c = sqlite3.connect('db/vesti.db')
|
||||
for ddl in [
|
||||
"ALTER TABLE posts ADD COLUMN is_own INTEGER DEFAULT 0",
|
||||
"ALTER TABLE posts ADD COLUMN is_own_canonical INTEGER DEFAULT 0",
|
||||
"ALTER TABLE sources ADD COLUMN own INTEGER DEFAULT 0",
|
||||
"ALTER TABLE published ADD COLUMN distributed_dirs TEXT",
|
||||
]:
|
||||
try: c.execute(ddl)
|
||||
except sqlite3.OperationalError: pass # уже есть
|
||||
c.commit(); c.close()
|
||||
PY
|
||||
|
||||
# 2) Добавить источник в sources.yaml (own: true), синк
|
||||
.venv/bin/python -c "from sources.sources import sync_sources_to_db, load_sources_yaml; sync_sources_to_db(load_sources_yaml())"
|
||||
|
||||
# 3) Краулер по своему каналу (бэкфилл ~1039 постов; медиа скачивается)
|
||||
.venv/bin/python -m crawler.telegram_crawler --source dedinit
|
||||
|
||||
# 4) Классификатор по своему каналу
|
||||
CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --direction linux # + нужные направления
|
||||
|
||||
# 5) Веб
|
||||
VESTI_WEB_PASSWORD=<пароль> .venv/bin/uvicorn web.app:app --host 127.0.0.1 --port 8400
|
||||
|
||||
# 6) Проверка
|
||||
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8400/login # 200
|
||||
sqlite3 db/vesti.db "SELECT COUNT(*) FROM posts WHERE is_own=1" # >0
|
||||
sqlite3 db/vesti.db "SELECT COUNT(*) FROM posts WHERE is_own=1 AND is_own_canonical=1"
|
||||
```
|
||||
|
||||
## Rollback
|
||||
|
||||
```bash
|
||||
# Отключить источник (не удалять данные)
|
||||
# sources.yaml: dedinit → enabled: false, own: false
|
||||
# Перезапустить синк; посты остаются в БД, новые не приходят.
|
||||
# Поля is_own в данных можно оставить (безвредно); удаление данных — по согласованию.
|
||||
```
|
||||
|
||||
Существующие внешние источники и их посты не затрагиваются: is_own=0 по умолчанию.
|
||||
|
||||
## Risks
|
||||
|
||||
- **Бэкфилл 1039 постов** — первый прогон долгий (медиа ~623M). Ограничить
|
||||
MAX_POSTS_PER_CHANNEL или сначала только текст, медиа докачать позже (бэкфилл-флаг).
|
||||
- **Дубликаты с внешними источниками**: пост пользователя, который запостили в чужой
|
||||
канал, попадёт и как is_own (свой), и как внешний. Для своих постов `is_own_canonical=1`
|
||||
(первичный экземпляр), внешние остаются как «упоминания» (is_own=0).
|
||||
- **Fan-out = спам**: всегда режим подтверждения; веб показывает направления заранее;
|
||||
лимит 4096 символов сохраняется; атрибуция не даёт путаницы с чужим контентом.
|
||||
- **qwen3:8b think:false** — уже учтено в classify.py.
|
||||
- **Право на медиа**: медиа своего канала скачивается (контент пользователя) — ок.
|
||||
@@ -0,0 +1,65 @@
|
||||
## Why
|
||||
|
||||
У пользователя есть собственные ресурсы (канал Telegram «Дед в АйТи» @dedinit, сайт dedinit.ru,
|
||||
далее — феды/видео), но они живут разрозненно: контент, опубликованный в одном месте, не
|
||||
попадает в другие. Цель — **собственный контент-хаб**: единая точка сбора ВСЕХ постов
|
||||
пользователя из разных платформ, один банк своего контента, и **автораспространение**
|
||||
этого контента по тематическим новостным ботам VESTI (и в перспективе — по другим
|
||||
платформам), чтобы органически росла аудитория на всех площадках.
|
||||
|
||||
Задача НЕ «сделать копию канала»: канал @dedinit — полноценный источник данных в общей
|
||||
логике проекта (как любой TG-канал): краулер → классификатор → кандидат → подтверждение →
|
||||
публикация в тематические каналы → банк статей. Отличие от внешних источников — это
|
||||
СВОЙ контент (is_own=1): он всегда кандидат на публикацию («инъекция» в ленту),
|
||||
не блокируется политикой чужих форвардов и помечается атрибуцией автора.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Добавить канал @dedinit (id 1150165846) в sources.yaml как источник `own: true`
|
||||
(свой контент пользователя), направление определяется классификатором (канал
|
||||
разносторонний: Linux, IT, AI, игры...).
|
||||
- Краулер: посты своего канала помечаются `is_own=1`, для них продолжает работать
|
||||
дедуп (sha256/url); политика форвардов для своего канала — как обычно (чужие
|
||||
форварды → fwd-поля без медиа).
|
||||
- Классификатор: свой контент с relevance critical/high → «сильные кандидаты»
|
||||
(самокатегоризация; приоритет в ленте подтверждения).
|
||||
- **Автораспространение (distribution)**: подтверждённый пост рассылается НЕ только
|
||||
в один канал @dedinit_vesti_<dir>_<lang>_bot, а во ВСЕ тематические боты/каналы,
|
||||
соответствующие направлениям поста (один пост может попасть в несколько лент).
|
||||
Режим — по-прежнему «черновик на подтверждение», но подтверждение ведёт к
|
||||
множественной публикации (fan-out).
|
||||
- Веб: фильтр «Свои» (только is_own посты), отображение бейджа «СВОЙ», выбор
|
||||
направлений для рассылки при подтверждении.
|
||||
- Расширить таблицы: posts.is_own, posts.is_own_canonical (первичный экземпляр),
|
||||
sources.own, published.distributed_dirs (какие направления розданы).
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `own-content`: Свой контент-хаб: пометка постов пользователя (is_own), приоритет
|
||||
в кандидатах, сквозная ссылка на оригинал во всех публикациях.
|
||||
|
||||
### Modified Capabilities
|
||||
- `tg-crawler`: пометка is_own по источникам с own: true; политика форвардов для
|
||||
своих каналов не отличается от внешних (dedup + fwd-поля).
|
||||
- `classifier`: свой контент → «сильный кандидат» (relevance critical/high при
|
||||
словарном попадании; classified=True даже без LLM-подтверждения, если есть
|
||||
направление).
|
||||
- `tg-publisher`: fan-out по нескольким направлениям; атрибуция «Дед в АйТи» +
|
||||
ссылка на оригинал.
|
||||
- `vesti-web`: фильтр «Свои», бейдж, выбор направлений рассылки при подтверждении.
|
||||
- `news-store`: бандл своего поста помечается origin=own + ссылка на оригинал в
|
||||
frontmatter.
|
||||
|
||||
## Impact
|
||||
|
||||
- Затронутые сервисы/порты: без новых портов; краулер (cron), классификатор,
|
||||
tg-publisher, веб 127.0.0.1:8400 — те же.
|
||||
- Файлы: sources/sources.yaml (новый источник), crawler/telegram_crawler.py,
|
||||
classifier/classify.py, publisher/bot.py, publisher/card.py, web/app.py,
|
||||
db/schema.sql (миграции ADD COLUMN is_own и др.).
|
||||
- Данные: 1039 постов канала @dedinit появятся как is_own посты; медиа своего канала
|
||||
скачивается (это контент пользователя — можно).
|
||||
- Секреты: не требуются новые (та же Telethon-сессия, токены ботов в .env).
|
||||
- Rollback: отключение источника `own: false` / удаление поля is_own; существующие
|
||||
внешние посты не затрагиваются; данные не удаляются (правило пользователя).
|
||||
@@ -0,0 +1,30 @@
|
||||
## Purpose
|
||||
|
||||
Классификация постов по направлениям локальным LLM + словарный фильтр. Дополняется
|
||||
приоритетом «своего контента» и поддержкой мультинаправлений для fan-out.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Приоритет своего контента
|
||||
Классификатор MUST обрабатывать посты с `is_own=1` как «сильные кандидаты»: при наличии
|
||||
направления по словарю — relevance=critical, classified=True — даже если LLM недоступна
|
||||
(фолбэк без LLM, пост не теряется). Для внешних постов поведение без изменений.
|
||||
|
||||
#### Scenario: Свой пост, LLM недоступна
|
||||
- **WHEN** пост is_own=1, словарь дал направление, но Ollama недоступна
|
||||
- **THEN** пост получает direction (словарь), relevance=critical, classified=True,
|
||||
method='dict-own' (не требует LLM)
|
||||
|
||||
#### Scenario: Свой пост без направления по словарю
|
||||
- **WHEN** пост is_own=1, словарь не дал направление
|
||||
- **THEN** классификации нет (classified=False) до LLM; пост не теряется (остаётся в очереди)
|
||||
|
||||
### Requirement: Мультинаправления
|
||||
Классификатор MUST уметь возвращать несколько направлений для поста (для маппинга fan-out);
|
||||
основное направление хранится в posts.direction, дополнительные — в classifications
|
||||
(таблица уже позволяет несколько классификаций на пост).
|
||||
|
||||
#### Scenario: Пост про Linux + AI
|
||||
- **WHEN** пост упоминает и линукс, и нейросети
|
||||
- **THEN** в classifications может быть несколько записей (linux, ai); fan-out использует
|
||||
оба при подтверждении
|
||||
@@ -0,0 +1,21 @@
|
||||
## Purpose
|
||||
|
||||
Банк статей: markdown-бандлы с frontmatter + медиа. Дополняется пометкой происхождения
|
||||
своего контента и ссылкой на оригинал.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Атрибуция в бандле
|
||||
Бандл поста с is_own=1 MUST содержать в frontmatter `origin: own`, ссылку на оригинал
|
||||
(`source_url` = t.me/dedinit/<id>) и имя автора («Дед в АйТи»). Бандл внешнего поста —
|
||||
как раньше (origin: external, source_url=url источника).
|
||||
|
||||
#### Scenario: Бандл своего поста
|
||||
- **WHEN** create_bundle вызывается для поста is_own=1
|
||||
- **THEN** frontmatter содержит origin: own, source: dedinit, source_url:
|
||||
https://t.me/dedinit/<tg_post_id>, author: Дед в АйТи
|
||||
|
||||
#### Scenario: Бандл внешнего поста в нескольких направлениях
|
||||
- **WHEN** пост (свой или внешний) опубликован в несколько направлений
|
||||
- **THEN** бандл создаётся по каждому направлению (bundles/<dir>/<YYYY-MM>/<slug>.md),
|
||||
обе записи ссылаются на один и тот же original post_id
|
||||
@@ -0,0 +1,32 @@
|
||||
## Purpose
|
||||
|
||||
Чтение публичных Telegram-каналов через Telethon (MTProto) для сбора новостей с метриками
|
||||
популярности. Дополняется поддержкой «своих» источников (own: true) — контент пользователя.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Источники своего контента
|
||||
Краулер MUST распознавать источники с `own: true` в sources.yaml и для их постов
|
||||
проставлять `is_own=1`, `is_own_canonical=1`. Для таких источников медиа MUST
|
||||
скачиваться (контент принадлежит пользователю).
|
||||
|
||||
#### Scenario: Краулинг своего канала
|
||||
- **WHEN** источник slug=dedinit имеет own: true
|
||||
- **THEN** посты сохраняются с is_own=1 и is_own_canonical=1; медиа скачивается;
|
||||
инкрементальный обход и дедуп работают как обычно
|
||||
|
||||
#### Scenario: Чужой форвард в своём канале
|
||||
- **WHEN** пост в своём канале — форвард из чужого канала
|
||||
- **THEN** пост сохраняется с is_own=1 (это пост пользователя, он его переслал) и с
|
||||
fwd_from_channel_id/fwd_from_post_id; медиа не скачивается (содержимое чужое),
|
||||
атрибуция оригинала сохраняется в fwd-полях
|
||||
|
||||
### Requirement: Канонический экземпляр своего контента
|
||||
Если пост пользователя (is_own=1) позже встречается во внешнем канале (тот же sha256/url),
|
||||
внешний экземпляр MUST сохраняться как «упоминание» с is_own=0; каноническим остаётся
|
||||
первичный (is_own_canonical=1).
|
||||
|
||||
#### Scenario: Свой пост запостили в чужой канал
|
||||
- **WHEN** краулер находит в чужом канале пост с текстом, совпадающим с is_own-постом
|
||||
- **THEN** создаётся запись is_own=0 (упоминание) без дублирования контента; веб видит
|
||||
оба экземпляра, но кандидатом на публикацию считается канонический (is_own_canonical)
|
||||
@@ -0,0 +1,43 @@
|
||||
## Purpose
|
||||
|
||||
Публикация отобранных новостей через Bot API в тематические Telegram-каналы. Дополняется
|
||||
автораспространением своего контента (fan-out) по нескольким направлениям.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Автораспространение (fan-out)
|
||||
Подтверждение СВОЕГО поста (is_own=1) MUST публиковать карточку во ВСЕ тематические
|
||||
каналы @dedinit_vesti_<direction>_<lang>_bot, соответствующие выбранным направлениям
|
||||
(по умолчанию — все направления классификации поста). Каждая карточка MUST содержать
|
||||
атрибуцию «Дед в АйТи» (@dedinit) и ссылку на оригинал t.me/dedinit/<post_id>.
|
||||
|
||||
#### Scenario: Мульти-публикация
|
||||
- **WHEN** подтверждается свой пост с направлениями [linux, ai]
|
||||
- **THEN** карточка отправляется в @dedinit_vesti_linux_ru_bot и @dedinit_vesti_ai_ru_bot;
|
||||
обе содержат ссылку на оригинал
|
||||
|
||||
#### Scenario: Чужой пост — без fan-out
|
||||
- **WHEN** подтверждается внешний пост (is_own=0)
|
||||
- **THEN** публикуется только в канал своего направления, без атрибуции автора
|
||||
|
||||
### Requirement: Публикация по списку направлений
|
||||
Публикатор MUST поддерживать `publish_multi(directions)` — публикацию карточки по списку
|
||||
направлений, возвращающую map {direction: message_id}. При пустом списке направлений
|
||||
MUST публиковать в направление по умолчанию (direction поста).
|
||||
|
||||
#### Scenario: Список направлений рассылки
|
||||
- **WHEN** publish_multi вызывается с directions=[linux, ai]
|
||||
- **THEN** возвращается {linux: message_id1, ai: message_id2}; каждая публикация
|
||||
записывается в published с distributed_dirs
|
||||
|
||||
#### Scenario: Пустой список направлений
|
||||
- **WHEN** publish_multi вызывается без directions
|
||||
- **THEN** публикация идёт в канал направления поста (direction по умолчанию), без fan-out
|
||||
|
||||
### Requirement: Метрики по каждому направлению
|
||||
Для опубликованных карточек MUST собираться views через Bot API по каждому направлению
|
||||
(каждому message_id), чтобы веб показывал эффективность рассылки по лентам.
|
||||
|
||||
#### Scenario: Метрики fan-out
|
||||
- **WHEN** пост разослан в [linux, ai] и каналы набирают просмотры
|
||||
- **THEN** get_views вызывается для каждого message_id; views хранятся по направлению
|
||||
@@ -0,0 +1,28 @@
|
||||
## Purpose
|
||||
|
||||
Веб-интерфейс управления VESTI. Дополняется фильтром «Свои», бейджем и выбором
|
||||
направлений рассылки для своего контента.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Фильтр «Свои»
|
||||
Веб MUST давать фильтр постов по `is_own` (все/только свои/только внешние) и показывать
|
||||
бейдж «СВОЙ» у постов is_own=1. Для своего поста при подтверждении MUST отображаться
|
||||
выбор направлений рассылки (по умолчанию — все направления классификации поста).
|
||||
|
||||
#### Scenario: Фильтр своих постов
|
||||
- **WHEN** админ выбирает фильтр «Свои»
|
||||
- **THEN** показываются только посты is_own=1 с бейджем «СВОЙ» и чекбоксами направлений
|
||||
|
||||
#### Scenario: Подтверждение своего поста
|
||||
- **WHEN** админ подтверждает свой пост с выбранными направлениями [linux, ai]
|
||||
- **THEN** публикация идёт в оба канала (fan-out), результат виден в опубликованных с
|
||||
distributed_dirs
|
||||
|
||||
### Requirement: Список распространения
|
||||
Веб MUST показывать для опубликованного поста, в какие направления/каналы он был
|
||||
разослан (distributed_dirs) и метрики (views) по каждому каналу.
|
||||
|
||||
#### Scenario: Просмотр распространения
|
||||
- **WHEN** админ открывает опубликованный пост (свой)
|
||||
- **THEN** видит список @dedinit_vesti_<dir>_<lang>_bot с views по каждому
|
||||
@@ -0,0 +1,60 @@
|
||||
# Tasks: own-content-hub
|
||||
|
||||
## 1. Схема БД и реестр источников
|
||||
|
||||
- [x] 1.1 Миграция схемы: ALTER TABLE posts ADD COLUMN is_own INTEGER DEFAULT 0, is_own_canonical INTEGER DEFAULT 0; sources ADD COLUMN own INTEGER DEFAULT 0; published ADD COLUMN distributed_dirs TEXT
|
||||
Проверка: `sqlite3 db/vesti.db "PRAGMA table_info(posts)"` показывает is_own/is_own_canonical; sources.own; published.distributed_dirs
|
||||
- [x] 1.2 Добавить источник dedinit в sources.yaml (channel: dedinit, own: true, direction: null, lang: ru)
|
||||
Проверка: `grep -A4 "slug: dedinit" sources/sources.yaml` → есть own: true
|
||||
- [x] 1.3 Синк реестра в БД (sources.own=1 для dedinit)
|
||||
Проверка: `sqlite3 db/vesti.db "SELECT slug, own FROM sources WHERE slug='dedinit'"` → dedinit|1
|
||||
|
||||
## 2. Краулер
|
||||
|
||||
- [x] 2.1 telegram_crawler.py: загрузка own-флага источников; проставление is_own/is_own_canonical для own-источников; медиа скачивается
|
||||
Проверка: код реализован (store_posts/is_own_source, py_compile OK); интеграционная проверка ждёт бэкфилла 2.3
|
||||
- [x] 2.2 Форварды в своём канале: чужой форвард сохраняется с is_own=1 + fwd-полями, медиа НЕ скачивается
|
||||
Проверка: код реализован (skip_media для форвардов); интеграционная проверка после бэкфилла
|
||||
- [ ] 2.3 Бэкфилл своего канала: первый прогон ~1039 постов (медиа по возможности; при лимите — текст без медиа, бэкфилл-флаг)
|
||||
Проверка: `sqlite3 db/vesti.db "SELECT COUNT(*) FROM posts WHERE is_own=1"` > 0 (до ~1039)
|
||||
- [x] 2.4 Дедуп: тот же sha256/url во внешнем канале → is_own=0 (упоминание), канонический остаётся is_own_canonical=1
|
||||
Проверка: код реализован (канон vs упоминание); проверка на реальных данных после бэкфилла
|
||||
|
||||
## 3. Классификатор
|
||||
|
||||
- [x] 3.1 classify.py: is_own=1 + направление по словарю → relevance=critical, classified=True, method='dict-own' (без LLM при недоступности)
|
||||
Проверка: тестовый свой пост со словарным попаданием при выключенной Ollama → classified=1 relevance=critical
|
||||
- [x] 3.2 Поддержка мультинаправлений: классификатор может писать несколько записей classifications (fan-out)
|
||||
Проверка: пост linux+ai имеет 2 записи classifications
|
||||
|
||||
## 4. Публикатор (fan-out)
|
||||
|
||||
- [x] 4.1 publisher/bot.py: publish_multi(directions) → публикация карточки в каждый @dedinit_vesti_<dir>_<lang>_bot; возвращает {dir: message_id}
|
||||
Проверка: dry-run с токеном → map направлений; без токена → dry_run=True (проверено ['linux','ai'])
|
||||
- [x] 4.2 Атрибуция в карточке (publisher/card.py): для is_own-постов строка «Дед в АйТи (@dedinit)» + ссылка на оригинал, для внешних — без
|
||||
Проверка: make_card(is_own пост) содержит t.me/dedinit/ и «Дед в АйТи» (проверено); make_card(внешний) — нет
|
||||
- [x] 4.3 Запись distributed_dirs + tg_message_ids в published при fan-out
|
||||
Проверка: после approve (TestClient, dry-run) distributed_dirs=JSON([linux, ai]) в published + views
|
||||
|
||||
## 5. Веб
|
||||
|
||||
- [x] 5.1 Фильтр «Свои» (is_own) в /candidates: параметр own=1|0, бейдж «СВОЙ»
|
||||
Проверка: TestClient GET /candidates?own=1 → только is_own посты с бейджем «⭐ СВОЙ» (проверено)
|
||||
- [x] 5.2 Выбор направлений рассылки при approve: чекбоксы (по умолчанию — направления классификации); approve → publish_multi
|
||||
Проверка: TestClient POST /posts/{id}/approve с dirs=linux,ai → 302 /published, distributed_dirs=[linux,ai] (dry-run) (проверено)
|
||||
- [x] 5.3 Опубликованные: показ distributed_dirs (в какие каналы разослан) и метрики по каждому
|
||||
Проверка: /published содержит «Разослан в» с @dedinit_vesti_linux_ru_bot и ai (проверено TestClient)
|
||||
|
||||
## 6. Банк статей (news-store)
|
||||
|
||||
- [x] 6.1 store.py: frontmatter origin: own + source_url + author для is_own-постов; origin: external для внешних
|
||||
Проверка: бандл содержит `origin: own` и `source_url: https://t.me/dedinit/<id>`, author «Дед в АйТи» (проверено)
|
||||
- [x] 6.2 Бандлы по каждому направлению fan-out (bundles/<dir>/<YYYY-MM>/<slug>.md)
|
||||
Проверка: create_bundle(['linux','ai']) → 2 файла в bundles/linux и bundles/ai (проверено)
|
||||
|
||||
## 7. Проверка интеграции и документация
|
||||
|
||||
- [ ] 7.1 Полный прогон: синк → краулер dedinit → классификатор → веб (approve с fan-out) → бандлы; внешние источники не затронуты (is_own=0 по умолчанию)
|
||||
Проверка: counts по is_own в БД, бандлы, /published, runs ok — ждёт бэкфилла 2.3 (реальная сеть)
|
||||
- [x] 7.2 Обновить STATUS.md / TODO.md / WALKTHROUGH.md (что сделано, как запускать, питфолы)
|
||||
Проверка: документы отражают новое состояние (обновлено при закрытии сессии)
|
||||
@@ -0,0 +1,3 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-13
|
||||
skip_specs: true
|
||||
@@ -0,0 +1,32 @@
|
||||
## Design
|
||||
|
||||
### services/publisher/app/main.py
|
||||
|
||||
Модель уже имеет `dry_run: bool = False`. В роуте publish (тело):
|
||||
|
||||
```python
|
||||
@app.post("/api/v1/publish")
|
||||
def publish(payload: PublishRequest):
|
||||
# dry_run — тестовый режим: НЕ уходит в Telegram, возвращает эмуляцию
|
||||
if payload.dry_run:
|
||||
results = {
|
||||
ch: {
|
||||
"message_id": 0,
|
||||
"media_message_id": 0,
|
||||
"views": 0,
|
||||
"error": None,
|
||||
}
|
||||
for ch in resolve_channels(payload.channels)
|
||||
}
|
||||
return {"ok": True, "results": results, "dry_run": True}
|
||||
... (реальный путь — как сейчас)
|
||||
```
|
||||
|
||||
При dry_run получатель — resolve_channels(payload.channels or конфиг), т.к. без него
|
||||
непонятно, для какого канала эмулировать (разумно: тот же, что и в реале).
|
||||
|
||||
### Верификация
|
||||
|
||||
- `curl -d '{"card":{...},"dry_run":true}'` → dry_run:true, message_id:0, телеграм НЕ тронут.
|
||||
- `curl -d '{"card":{...},"dry_run":false}'` → как раньше (реальный publish).
|
||||
- docker compose restart vesti-publisher (пересборка: код меняется, нужен образ).
|
||||
@@ -0,0 +1,24 @@
|
||||
## Why
|
||||
|
||||
При тесте публикации с медиа сквозь веб выяснилось: `dry_run` в POST /api/v1/publish
|
||||
(services/publisher/app/main.py:42, модель `PublishRequest.dry_run: bool = False`)
|
||||
НИГДЕ не используется в теле — публикация уходит в Telegram реально даже при
|
||||
`"dry_run": true`. Это опасно: тестовые запросы засоряют канал (сегодня ушли
|
||||
реальные сообщения 11/12, пришлось удалять вручную).
|
||||
|
||||
## What Changes
|
||||
|
||||
- services/publisher/app/main.py: при `payload.dry_run == True` НЕ вызывать telegram.publish,
|
||||
вернуть эмуляцию результата (ok, результаты с message_id=0 и флагом dry_run=true),
|
||||
при этом сделать вид, что опубликовано (для сквозного теста веб → publisher без TG).
|
||||
|
||||
## Why Not
|
||||
|
||||
- Не менять веб: веб всегда шлёт dry_run=false (реальные approve). dry_run — только для
|
||||
тестов/curl.
|
||||
|
||||
## Acceprance
|
||||
|
||||
- `curl ... -d '{"card":{...},"dry_run":true}'` → результат с dry_run:true, НЕ уходит в TG
|
||||
(можно проверить: views по message_id=0 → 404).
|
||||
- `curl ... -d '{"card":{...},"dry_run":false}'` → реальная публикация (как раньше).
|
||||
@@ -0,0 +1,9 @@
|
||||
# publisher-dry-run-fix
|
||||
|
||||
- [x] Создан OpenSpec change (proposal/design)
|
||||
- [x] main.py: if payload.dry_run → эмуляция результата (message_id=0, dry_run=true), без вызова TG
|
||||
- [x] PublishRequest: добавлено поле `dry_run` (было только в Response — AttributeError)
|
||||
- [x] Пересборка контейнера: docker compose up -d --build (дважды — после правки модели)
|
||||
- [x] Тест: dry_run=true → ok, message_id=0, dry_run=true, канал НЕ тронут
|
||||
- [x] Тест: dry_run=false → как раньше (502 на несуществующий канал, реальный publish работает)
|
||||
- [x] `openspec validate publisher-dry-run-fix` — чисто
|
||||
@@ -0,0 +1,104 @@
|
||||
# Design: publisher-service
|
||||
|
||||
## Approach
|
||||
|
||||
Выносим публикацию в Telegram из веб-процесса в изолированный FastAPI-микросервис.
|
||||
Сервис — единственная точка, которая знает токен бота (прокси), каналы и Bot API.
|
||||
Остальные компоненты (веб, в будущем cron/боты) вызывают его по HTTP.
|
||||
|
||||
Схема:
|
||||
```
|
||||
vesti-web (:8400) ──POST /api/v1/publish──▶ publisher-service (:8410) ──Bot API (SOCKS5 127.0.0.1:1080)──▶ Telegram
|
||||
approve (человек) │ VESTI_BOT_TOKEN, VESTI_BOT_CHANNELS
|
||||
▼
|
||||
Telegram: @dedinit_vesti (+ другие каналы)
|
||||
```
|
||||
|
||||
## Files
|
||||
|
||||
```bash
|
||||
# Новый сервис
|
||||
services/publisher/
|
||||
├── app/
|
||||
│ ├── __init__.py
|
||||
│ ├── main.py # FastAPI: POST /api/v1/publish, GET /healthz
|
||||
│ ├── config.py # env: VESTI_BOT_TOKEN, TG_PROXY, VESTI_BOT_CHANNELS, LISTEN_PORT
|
||||
│ ├── telegram.py # Bot API клиент (httpx + SOCKS5): send, get_views
|
||||
│ └── channels.py # разбор списка каналов (VESTI_BOT_CHANNELS)
|
||||
├── requirements.txt # fastapi, uvicorn, httpx[socks], pydantic, python-dotenv
|
||||
├── Dockerfile # python:slim, non-root, read-only fs
|
||||
├── docker-compose.yml # сервис, порт 8410, healthcheck, env из .env
|
||||
├── .env.example # без секретов
|
||||
└── README.md # API, порты, запуск, безопасность
|
||||
|
||||
# Изменения
|
||||
web/app.py # approve → HTTP POST в publisher-service (вместо import publisher.bot)
|
||||
.env.example # + VESTI_BOT_CHANNELS, TG_PROXY
|
||||
STATUS.md / TODO.md / WALKTHROUGH.md # статус
|
||||
```
|
||||
|
||||
## Data / Config
|
||||
|
||||
```bash
|
||||
# .env (реальные значения; НЕ коммитить)
|
||||
VESTI_BOT_TOKEN=<токен @dedinit_controller_bot> # уже в .env
|
||||
TG_PROXY=socks5://127.0.0.1:1080 # уже есть
|
||||
VESTI_BOT_CHANNELS=@dedinit_vesti # список каналов, разделитель запятая
|
||||
PUBLISHER_PORT=8410
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
### POST /api/v1/publish
|
||||
```json
|
||||
{
|
||||
"card": {"text": "...", "media": "/path/to/photo.jpg", "direction": "linux", "lang": "ru"},
|
||||
"channels": ["@dedinit_vesti"] // опционально; default = VESTI_BOT_CHANNELS
|
||||
}
|
||||
```
|
||||
Ответ 200:
|
||||
```json
|
||||
{
|
||||
"ok": true,
|
||||
"results": {
|
||||
"@dedinit_vesti": {"message_id": 123, "media_message_id": 122, "views": 0}
|
||||
},
|
||||
"dry_run": false
|
||||
}
|
||||
```
|
||||
Ошибки: 400 (невалидный card), 502 (Bot API / прокси недоступен), 403 (бот не админ).
|
||||
|
||||
### GET /healthz
|
||||
```json
|
||||
{"status": "ok", "bot": "@dedinit_controller_bot", "proxy": "socks5://127.0.0.1:1080", "channels": ["@dedinit_vesti"]}
|
||||
```
|
||||
Healthcheck: `curl -f http://127.0.0.1:8410/healthz`.
|
||||
|
||||
## Commands
|
||||
|
||||
```bash
|
||||
cd /opt/vesti
|
||||
# dev (без Docker):
|
||||
.venv/bin/pip install -r services/publisher/requirements.txt
|
||||
.venv/bin/uvicorn services.publisher.app.main:app --host 127.0.0.1 --port 8410
|
||||
curl -s http://127.0.0.1:8410/healthz
|
||||
|
||||
# prod (Docker):
|
||||
docker compose -f services/publisher/docker-compose.yml up -d --build
|
||||
curl -s http://127.0.0.1:8410/healthz
|
||||
curl -s -X POST http://127.0.0.1:8410/api/v1/publish \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"card": {"text": "<b>Тест</b>", "direction": "linux", "lang": "ru"}}'
|
||||
|
||||
# переключение веба:
|
||||
# в web/app.py заменить `from publisher.bot import publish_multi` на HTTP-клиент
|
||||
# (или переменная окружения PUBLISHER_URL=http://127.0.0.1:8410)
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
- [ ] `openspec validate publisher-service` → 0 ошибок
|
||||
- [ ] `curl :8410/healthz` → ok, бот, прокси, каналы
|
||||
- [ ] POST /api/v1/publish с тестовой карточкой → message_id в @dedinit_vesti
|
||||
- [ ] Бот не админ / прокси упал → понятная ошибка (4xx/502), веб показывает
|
||||
- [ ] approve в вебе → реальное сообщение в канале (микросервис вызван по HTTP)
|
||||
@@ -0,0 +1,66 @@
|
||||
## Why
|
||||
|
||||
Сейчас публикатор встроен в веб-приложение (web/app.py импортирует publisher.bot напрямую
|
||||
и вызывает publish_multi). Это нарушает изоляцию элементов системы и мешает масштабированию:
|
||||
- публикация привязана к процессу веба (ошибка Bot API роняет весь approve);
|
||||
- нет отдельного жизненного цикла (нельзя перезапустить/обновить публикатор отдельно);
|
||||
- каналы захардкожены шаблоном @dedinit_vesti_<dir>_<lang>_bot, а реальная схема —
|
||||
«один бот-контроллер, несколько каналов» (на старте один @dedinit_vesti, потом больше);
|
||||
- нет единой точки входа для публикации из любых компонентов (веб, cron, будущие боты VK/fediverse).
|
||||
|
||||
Цель — вынести публикацию в **изолированный микросервис** (отдельный FastAPI-сервис в
|
||||
контейнере), который вызывается HTTP-запросом при необходимости. Это соответствует
|
||||
архитектурному решению «сегментировать элементы системы на микросервисы в отдельных
|
||||
контейнерах» (PRD, раздел 5).
|
||||
|
||||
## What Changes
|
||||
|
||||
- Новый сервис `publisher/` (или `services/publisher/`): FastAPI-приложение с эндпоинтом
|
||||
`POST /api/v1/publish` (публикация карточки в один или несколько каналов) и
|
||||
`GET /healthz` (healthcheck).
|
||||
- Конфигурация сервиса: `VESTI_BOT_TOKEN` (токен бота-контроллера @dedinit_controller_bot),
|
||||
`TG_PROXY=socks5://127.0.0.1:1080` (Telegram из РФ доступен только через SOCKS5),
|
||||
список каналов (сейчас `@dedinit_vesti`, потом несколько) — из .env или отдельного YAML.
|
||||
- Бот-контроллер: один (id 7765665742, @dedinit_controller_bot), публикует во все каналы,
|
||||
в которые добавлен администратором.
|
||||
- `publisher/bot.py` переносится в сервис (логика publish_card/publish_multi/get_views),
|
||||
но с конфигом каналов вместо шаблона @dedinit_vesti_<dir>_<lang>_bot.
|
||||
- `web/app.py` больше НЕ импортирует publisher напрямую: вместо publish_multi — HTTP POST
|
||||
на publisher-service `/api/v1/publish`.
|
||||
- Dockerfile + docker-compose для сервиса; healthcheck; логирование.
|
||||
|
||||
### Не меняется
|
||||
- Карточка (publisher/card.py) остаётся (формат ≤4096, атрибуция «Дед в АйТи», ссылка на оригинал).
|
||||
- Режим публикации «черновик на подтверждение» (веб подтверждает → публикация). Без автопостинга.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `tg-publisher-service`: Изолированный FastAPI-сервис публикации в Telegram:
|
||||
единая точка `POST /api/v1/publish`, конфиг каналов, прокси SOCKS5 для Bot API,
|
||||
сбор views, healthcheck.
|
||||
|
||||
### Modified Capabilities
|
||||
- `tg-publisher`: логика публикации переезжает в сервис; вызывающий код (веб) использует HTTP.
|
||||
- `vesti-web`: approve вызывает publisher-service по HTTP вместо прямого импорта.
|
||||
- `news-store`: без изменений (бандлы создаёт веб, как раньше).
|
||||
|
||||
## Impact
|
||||
|
||||
- Затронутые сервисы/порты: publisher-service — новый порт (напр. 8410, локально);
|
||||
vesti-web :8400 — меняет способ вызова публикатора (HTTP вместо импорта).
|
||||
- Файлы:
|
||||
- новый: services/publisher/ (app/, Dockerfile, docker-compose.yml, requirements.py, README.md)
|
||||
- изменён: web/app.py (HTTP-вызов), .env.example (VESTI_BOT_CHANNELS, TG_PROXY)
|
||||
- перенос: publisher/bot.py → services/publisher/ (логика сохраняется)
|
||||
- Данные: без миграций БД (published.tg_message_id/distributed_dirs остаются).
|
||||
- Секреты: тот же VESTI_BOT_TOKEN (бот-контроллер); TG_PROXY переиспользуется.
|
||||
- Прокси: Bot API ТОЛЬКО через SOCKS5 127.0.0.1:1080 (api.telegram.org из РФ недоступен).
|
||||
- Rollback: вернуть в web/app.py импорт publisher.bot (старый путь); сервис можно не запускать.
|
||||
|
||||
## Risks
|
||||
|
||||
- SOCKS5-прокси недоступен → сервис не может опубликовать: healthcheck должен это показывать.
|
||||
- Бот не админ канала → sendMessage 403: сервис возвращает понятную ошибку, веб показывает ее.
|
||||
- Несколько каналов в будущем: конфиг списком (VESTI_BOT_CHANNELS=@a,@b), fan-out по каналам.
|
||||
- Рестарт сервисов — только извне (SSH sudo systemctl restart) — правило окружения.
|
||||
@@ -0,0 +1,79 @@
|
||||
# Spec: tg-publisher-service
|
||||
|
||||
## Purpose
|
||||
|
||||
Изолированный FastAPI-сервис публикации карточек в Telegram-каналы через Bot API.
|
||||
Единая точка вызова для всех компонентов (веб, cron, будущие боты). Один бот-контроллер
|
||||
публикует во все каналы, в которые добавлен администратором. Telegram доступен только
|
||||
через SOCKS5-прокси (127.0.0.1:1080).
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Изолированный сервис публикации
|
||||
Сервис MUST быть отдельным FastAPI-приложением (контейнер), НЕ импортируемым модулем веба.
|
||||
Он MUST предоставлять `GET /healthz` (статус, бот, прокси, каналы) и
|
||||
`POST /api/v1/publish` (публикация карточки).
|
||||
|
||||
#### Scenario: Healthcheck
|
||||
- **GIVEN** сервис запущен
|
||||
- **THEN** `GET /healthz` возвращает 200 с `{"status":"ok","bot":...,"channels":[...]}`
|
||||
и healthcheck в docker-compose (`curl -f`) проходит
|
||||
|
||||
#### Scenario: Публикация карточки
|
||||
- **GIVEN** POST /api/v1/publish c `card: {text, direction, lang}` и `channels: ["@dedinit_vesti"]`
|
||||
- **THEN** сервис отправляет сообщение через Bot API в каждый канал и возвращает
|
||||
`{"ok":true,"results":{"@dedinit_vesti":{"message_id":<int>,"views":0}}}`
|
||||
|
||||
### Requirement: Один бот, несколько каналов (конфиг)
|
||||
Сервис MUST поддерживать список каналов из конфигурации (`VESTI_BOT_CHANNELS`, через запятую).
|
||||
`channels` в запросе MAY переопределять список. Если бот добавлен в канал администратором —
|
||||
публикация MUST работать; иначе сервис MUST вернуть понятную ошибку (403).
|
||||
|
||||
#### Scenario: Несколько каналов
|
||||
- **GIVEN** `VESTI_BOT_CHANNELS=@dedinit_vesti,@other_channel` (оба добавлены боту)
|
||||
- **WHEN** POST /api/v1/publish без поля channels
|
||||
- **THEN** карточка публикуется в оба канала; results содержит оба message_id
|
||||
|
||||
#### Scenario: Бот не админ канала
|
||||
- **GIVEN** канал, в котором бот не администратор
|
||||
- **WHEN** публикация в него
|
||||
- **THEN** сервис возвращает 403 с текстом ошибки Bot API (sendMessage → Forbidden)
|
||||
|
||||
### Requirement: Прокси SOCKS5 для Bot API
|
||||
Все запросы к api.telegram.org MUST идти через прокси из `TG_PROXY=socks5://127.0.0.1:1080`.
|
||||
Если прокси недоступен — сервис MUST вернуть 502 (не падать).
|
||||
|
||||
#### Scenario: Прокси недоступен
|
||||
- **GIVEN** прокси 127.0.0.1:1080 выключен
|
||||
- **WHEN** POST /api/v1/publish
|
||||
- **THEN** сервис возвращает 502 с ошибкой подключения (не 500, не краш)
|
||||
|
||||
### Requirement: Сбор views
|
||||
Сервис MUST предоставлять способ получения просмотров для опубликованных сообщений
|
||||
(через Bot API getMessage), чтобы веб показывал метрики.
|
||||
|
||||
#### Scenario: Views после публикации
|
||||
- **GIVEN** сообщение опубликовано (message_id получен)
|
||||
- **WHEN** запрос views для этого message_id
|
||||
- **THEN** возвращается число просмотров (0 если ещё нет)
|
||||
|
||||
### Requirement: Режим подтверждения
|
||||
Сервис MUST НЕ публиковать автоматически: вызывается только по HTTP-запросу (из веба
|
||||
после клика «Опубликовать»). Автопостинга по таймеру внутри сервиса НЕТ.
|
||||
|
||||
#### Scenario: Нет автопостинга
|
||||
- **GIVEN** сервис запущен без входящих запросов
|
||||
- **THEN** ничего не публикуется (процесс только слушает HTTP)
|
||||
|
||||
## Modified Requirements (из tg-publisher)
|
||||
|
||||
- `publish_multi` и `get_views` переезжают в сервис (HTTP-интерфейс вместо импорта).
|
||||
- vesti-web: approve вызывает POST /api/v1/publish; ответ используется для
|
||||
distributed_dirs + views (как раньше, только источник данных — HTTP).
|
||||
|
||||
## NOT Requirements
|
||||
|
||||
- Не реализуем чтение каналов (краулинг) — это остаётся в tg-crawler (Telethon).
|
||||
- Не реализуем веб-интерфейс сервиса (только API + healthz).
|
||||
- Не храним БД в сервисе (вся персистентность — в vesti.db через веб).
|
||||
- Не делаем автопостинг (см. Requirement выше).
|
||||
@@ -0,0 +1,51 @@
|
||||
# Tasks: publisher-service
|
||||
|
||||
## 1. Скелет сервиса
|
||||
|
||||
- [x] 1.1 Создать services/publisher/ (app/, requirements.txt, .env.example, README.md)
|
||||
Проверка: `ls services/publisher/app/` → main.py, config.py, telegram.py, channels.py
|
||||
- [x] 1.2 requirements.txt: fastapi, uvicorn, httpx[socks], pydantic, python-dotenv
|
||||
Проверка: `.venv/bin/pip install -r services/publisher/requirements.txt` без ошибок
|
||||
- [x] 1.3 config.py: env VESTI_BOT_TOKEN, TG_PROXY, VESTI_BOT_CHANNELS, PUBLISHER_PORT
|
||||
Проверка: `python -c "from services.publisher.app.config import Settings; print(Settings().channels)"` → ['@dedinit_vesti']
|
||||
- Замечание: токен не читался из-за порядка (os.getenv при ClassVar, до load_dotenv) и неверного пути BASE (3x parent → /opt/vesti/services, нужно parents[3] → /opt/vesti). Исправлено: Settings → @dataclass + __post_init__, load_dotenv(override=True), BASE=parents[3].
|
||||
|
||||
## 2. Telegram-клиент (Bot API через SOCKS5)
|
||||
|
||||
- [x] 2.1 telegram.py: клиент httpx с proxy=socks5://127.0.0.1:1080, методы sendMessage/sendPhoto/getMessage
|
||||
- [x] 2.2 channels.py: разбор VESTI_BOT_CHANNELS ("@a,@b" → ["@a","@b"])
|
||||
- [x] 2.3 Обработка ошибок: 403 (бот не админ), сеть (прокси) → 502
|
||||
|
||||
## 3. FastAPI-эндпоинты
|
||||
|
||||
- [x] 3.1 main.py: GET /healthz (status, bot, proxy, channels)
|
||||
Проверка: `curl -s :8410/healthz` → ok + бот + каналы. Реальное: {"status":"ok","bot":"dedinit_controller_bot","token_set":true,"proxy":"socks5://127.0.0.1:1080","channels":["@dedinit_vesti"]}
|
||||
- [x] 3.2 main.py: POST /api/v1/publish (card {text, media?, direction, lang}, channels?) → results по каналам
|
||||
Проверка: `curl -X POST :8410/api/v1/publish -d '{"card":{"text":"тест","direction":"linux","lang":"ru"}}'` → ok, message_id в @dedinit_vesti. Реальное: {"ok":true,"results":{"@dedinit_vesti":{"message_id":2,...}}}
|
||||
- [x] 3.3 views: эндпоинт GET /api/v1/views/{channel}/{mid} (в main.py) + поле views в ответе publish (get_views при публикации)
|
||||
|
||||
## 4. Контейнеризация
|
||||
|
||||
- [x] 4.1 Dockerfile: python:slim, non-root, read-only fs, expose 8410
|
||||
- [x] 4.2 docker-compose.yml: сервис publisher, порт 127.0.0.1:8410, env из .env, healthcheck curl /healthz
|
||||
- Проверено 2026-09-09: `docker compose up -d --build` → vesti-publisher Up (healthy), 127.0.0.1:8410, healthz: bot=dedinit_controller_bot, proxy=host.docker.internal.
|
||||
- Питфолы Docker: (1) пути в compose отсчитываются от services/publisher/ → .env надо `../../.env`, media `../../media`; (2) TG_PROXY=127.0.0.1 в контейнере = сам контейнер → заменить на socks5://host.docker.internal:1080 + extra_hosts host-gateway; (3) load_dotenv(override=True) перебивал env контейнера → override=False (env окружения приоритетнее .env); (4) dataclass-дефолт tg_proxy="socks5://127.0.0.1:1080" был truthy → os.getenv не срабатывал → дефолт сделан пустым.
|
||||
|
||||
## 5. Интеграция с вебом
|
||||
|
||||
- [x] 5.1 web/app.py: убрать `from publisher.bot import publish_multi/get_views_multi`; вместо них web/publisher_client.py (HTTP POST на PUBLISHER_URL, default http://127.0.0.1:8410)
|
||||
- Проверка: grep — импорт publisher.bot убран; карточка шлёт card{direction,lang}, сервис берёт каналы из VESTI_BOT_CHANNELS.
|
||||
- [x] 5.2 Обновить .env.example (VESTI_BOT_CHANNELS, TG_PROXY, PUBLISHER_URL)
|
||||
- [x] 5.3 Реальный approve через веб: сквозной путь веб → HTTP → publisher(Docker) → канал.
|
||||
- Проверено 2026-09-09: approve постов 136 и 137 через POST /posts/<id>/approve — 302 → /published, статус published, бандл, tg_message_id=3 и 4 в @dedinit_vesti.
|
||||
- Веб-баги, найденные при проверке: (1) `raise RedirectResponse(...)` в _require_auth → TypeError (исключение не BaseException) → 500 на /candidates; фикс: HTTPException(303, headers={"Location": "/login"}); (2) tg_message_id для внешних постов искался по направлению (results["linux"]), а ключи results — каналы (@dedinit_vesti) → 0; фикс: брать первый message_id из results.values().
|
||||
|
||||
## 6. Проверка и документация
|
||||
|
||||
- [x] 6.1 `openspec validate publisher-service` → 0 ошибок (valid)
|
||||
- [x] 6.2 Реальная публикация тестовой карточки в @dedinit_vesti (бот админ) → message_id в ответе. Реальное: message_id=2, ok.
|
||||
- Бот добавлен админом канала (подтверждено пользователем).
|
||||
- [x] 6.3 Обновить STATUS.md / TODO.md — сделано; WALKTHROUGH/PRD — обновлено (см. PRD.md)
|
||||
|
||||
## Открытые пункты
|
||||
- [ ] publisher: медиа из card.media — путь в БД /opt/vesti/media/... не совпадает с монтированием в контейнере (/srv/publisher/media) → send_photo не уходит при Docker-запуске (нужен маппинг путей или передача имени файла)
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-12
|
||||
@@ -0,0 +1,69 @@
|
||||
## Дизайн
|
||||
|
||||
### 1. Формат карточки (publisher/card.py)
|
||||
|
||||
`make_card(post, comment=None)` теперь собирает текст репоста:
|
||||
|
||||
```
|
||||
[комментарий модератора (если задан)]
|
||||
[пустая строка]
|
||||
[полный текст исходного поста]
|
||||
[пустая строка]
|
||||
🔗 Оригинал: <url> (или атрибуция «Дед в АйТи (@dedinit) · t.me/dedinit/<id>» для своих)
|
||||
```
|
||||
|
||||
- Полный текст поста (post["text"]) вместо сниппета/summary; обрезка до Telegram-лимита
|
||||
(MAX_TEXT=4096) с учётом ссылки и комментария.
|
||||
- Служебная информация (📁 направление/язык, 📰 источник, 👁 просмотры) убирается из тела
|
||||
поста — это был «агрегаторный» вид. Просмотры/реакции остаются только в бандле и вебе.
|
||||
- Ссылка на оригинал — всегда последней строкой (для внешних: `🔗 Оригинал: <url>`;
|
||||
для своих: атрибуция + ссылка `t.me/dedinit/<id>` как раньше).
|
||||
- HTML-экранирование текста поста и комментария (вход — непроверенный текст, правило XSS).
|
||||
|
||||
### 2. Медиа (publisher/card.py + services/publisher)
|
||||
|
||||
- Медиа отправляется ПЕРВЫМ сообщением (фото или видео), затем — текст.
|
||||
- Разрешить video: `card.py` фильтр `.mp4` больше не отбрасывает (content_type=video).
|
||||
- `services/publisher/app/telegram.py` — новый `send_video(chat_id, path, caption="")`
|
||||
(Bot API sendVideo), общий `send_media` по расширению.
|
||||
- Caption у медиа: короткий (`<b>⬇️ Пост ниже</b>` или комментарий), НЕ дублировать весь
|
||||
текст (раньше photo caption обрезался до 1024 и текст всё равно слался вторым).
|
||||
|
||||
### 3. Отключение предпросмотра ссылки (services/publisher/app/telegram.py)
|
||||
|
||||
`send_message` → добавить параметр:
|
||||
|
||||
```python
|
||||
link_preview_options={"is_disabled": True}
|
||||
```
|
||||
|
||||
чтобы Telegram НЕ добавлял предпросмотр оригинальной ссылки в конце поста.
|
||||
|
||||
### 4. Веб: поле «Комментарий» (web/app.py + templates/candidates.html)
|
||||
|
||||
- В форме approve (для всех постов — и свои, и внешние) текстовое поле
|
||||
`<textarea name="comment" ...>Комментарий (по желанию)</textarea>`.
|
||||
- `approve`: `comment = (await request.form()).get("comment", "").strip()` → в card.
|
||||
- Комментарий уходит в published? Нет (не меняем схему БД) — только в текст поста и в
|
||||
метаданные бандла? Для простоты: комментарий включается в текст карточки (и, если
|
||||
хочется, в frontmatter бандла `comment:` — опционально, без схемы БД).
|
||||
|
||||
### 5. Полный текст в бандле
|
||||
|
||||
- Бандл (web/store.py) УЖЕ хранит полный текст поста — не меняется.
|
||||
|
||||
### 6. Обратная совместимость
|
||||
|
||||
- `make_card(post)` без comment работает (comment=None).
|
||||
- Старый `send_photo`/`send_message` остаются; main.py выбирает: если media → send_media,
|
||||
потом send_message (link_preview disabled).
|
||||
- Если текст пустой (пост только медиа) — текст-сообщение можно пропустить? Нет:
|
||||
ссылка на оригинал должна быть → текст генерируется всегда (минимум ссылка).
|
||||
|
||||
### 7. Проверка
|
||||
|
||||
- Юнит: `make_card` с comment → комментарий первым, полный текст, ссылка, без служебки.
|
||||
- Карточка ≤4096 (обрезается).
|
||||
- sendVideo работает для реального mp4 (в Docker медиа-маунт уже есть).
|
||||
- В канале: медиа + текст + ссылка, предпросмотра ссылки нет.
|
||||
- Веб: поле комментария видно, approve с комментарием → в канале комментарий первым.
|
||||
@@ -0,0 +1,50 @@
|
||||
## Why
|
||||
|
||||
Пользователь опубликовал несколько постов через веб-approve в канал @dedinit_vesti
|
||||
и увидел, что в канале пост выглядит «как простой агрегатор»:
|
||||
|
||||
- только ссылка на чужой канал (заголовок-сниппет из первых 120 символов текста),
|
||||
- служебная информация по направлениям (📁 направление/язык, 📰 источник, 👁 просмотры),
|
||||
- в конце Telegram добавляет предпросмотр ссылки (link preview).
|
||||
|
||||
Такой репост никому не интересен: не видно ни медиа из оригинального поста, ни
|
||||
полного текста, ни комментария модератора — только «голая» ссылка и служебка.
|
||||
|
||||
## What Changes
|
||||
|
||||
Формат публикуемого поста (карточка) меняется на «богатый репост»:
|
||||
|
||||
1. **Медиа из оригинального поста** — если у поста есть media_path (фото/видео),
|
||||
оно отправляется **первым сообщением** (sendPhoto/sendVideo), а текст — следующим.
|
||||
Сейчас sendPhoto есть, но caption обрезается до 1024 и текст дублируется вторым
|
||||
сообщением; видео (content_type=video) вообще не отправляется как медиа (фильтр в card.py).
|
||||
|
||||
2. **Полный текст поста** — вместо сниппета из первых 120 символов (make_card) или
|
||||
summary отправляется полный текст исходного поста (обрезанный до Telegram-лимита 4096).
|
||||
|
||||
3. **Комментарий модератора** — в веб-форме approve добавляется поле «Комментарий
|
||||
(по желанию)»; комментарий публикуется первым (или в начале текста), чтобы в канале
|
||||
было видно мнение/контекст редактора, а не только пересказ.
|
||||
|
||||
4. **Ссылка на оригинал БЕЗ предпросмотра** — ссылка на исходный пост остаётся в тексте,
|
||||
но Telegram-предпросмотр ссылки отключается (sendMessage параметр
|
||||
`link_preview_options={"is_disabled": True}`), чтобы канал не выглядел как агрегатор
|
||||
ссылок с превью.
|
||||
|
||||
5. **Служебная информация** — частично убирается/переформатируется: направление/язык,
|
||||
источник, просмотры больше НЕ обязательны в теле поста (внешняя ссылка на оригинал
|
||||
уже даёт контекст). Остаётся атрибуция для своего контента («Дед в АйТи»).
|
||||
|
||||
## Impact
|
||||
|
||||
- `publisher/card.py` — построение текста карточки (полный текст + комментарий + ссылка
|
||||
+ атрибуция, служебка по минимуму).
|
||||
- `services/publisher/app/telegram.py` — поддержка видео (sendVideo), параметр
|
||||
`link_preview_options` для sendMessage; send_photo с полным caption без обрезания
|
||||
(или без дублирования текста).
|
||||
- `services/publisher/app/main.py` — Card модель: +`comment`; передача link_preview_options.
|
||||
- `web/app.py` (approve) — чтение комментария из формы, проброс в card.
|
||||
- `web/templates/candidates.html` — поле ввода комментария в форме approve.
|
||||
- `publisher/card.py` — фильтр медиа: разрешить video (mp4), не только картинки.
|
||||
- Rollback: вернуть прежний make_card и вызовы; карточки станут как раньше.
|
||||
- Безопасность: комментарий — пользовательский ввод → HTML-экранирование как текст поста.
|
||||
@@ -0,0 +1,120 @@
|
||||
# TG Publisher — формат «богатого репоста»
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Карточка репоста — полный текст
|
||||
|
||||
При публикации внешнего поста карточка MUST содержать полный текст
|
||||
исходного поста (а не сниппет из первых 120 символов), обрезанный до лимита Telegram
|
||||
(4096 символов).
|
||||
|
||||
#### Scenario: публикация поста с длинным текстом
|
||||
|
||||
- Given пост с текстом длиной 3000 символов и ссылкой на оригинал
|
||||
- When модератор подтверждает пост в вебе
|
||||
- Then в канале отправляется текст с полным содержимым поста (обрезанный до 4096)
|
||||
- And заголовок-сниппет из 120 символов НЕ используется
|
||||
|
||||
### Requirement: Карточка репоста — комментарий модератора
|
||||
|
||||
При подтверждении поста модератор МОЖЕТ указать комментарий; комментарий
|
||||
MUST публиковаться первым блоком в тексте поста.
|
||||
|
||||
#### Scenario: approve с комментарием
|
||||
|
||||
- Given пост, подтверждаемый через веб
|
||||
- When модератор вводит комментарий «Отличный материал по Linux» и нажимает «Опубликовать»
|
||||
- Then текст карточки начинается с комментария «Отличный материал по Linux»
|
||||
- And полный текст исходного поста следует после комментария
|
||||
|
||||
#### Scenario: approve без комментария
|
||||
|
||||
- Given пост, подтверждаемый через веб
|
||||
- When модератор оставляет поле комментария пустым
|
||||
- Then текст карточки начинается с полного текста исходного поста
|
||||
- And лишних пустых блоков нет
|
||||
|
||||
### Requirement: Карточка репоста — ссылка на оригинал без предпросмотра
|
||||
|
||||
Ссылка на оригинальный пост MUST присутствовать в тексте карточки, и
|
||||
Telegram-предпросмотр этой ссылки MUST быть отключён (link_preview_options is_disabled).
|
||||
|
||||
#### Scenario: публикация внешнего поста
|
||||
|
||||
- Given внешний пост с url на оригинал
|
||||
- When карточка отправляется в канал
|
||||
- Then в тексте есть строка со ссылкой на оригинал
|
||||
- And Telegram НЕ добавляет предпросмотр ссылки внизу поста
|
||||
|
||||
### Requirement: Карточка репоста — медиа из оригинала
|
||||
|
||||
Если у исходного поста есть медиа (photo/video), публикация MUST
|
||||
отправлять медиа первым сообщением, а текст — следующим; видео (.mp4) MUST
|
||||
поддерживаться.
|
||||
|
||||
#### Scenario: пост с фото
|
||||
|
||||
- Given пост с media_path=media/xyz.jpg
|
||||
- When модератор подтверждает пост
|
||||
- Then в канал отправляется фото (sendPhoto) первым сообщением
|
||||
- And текст карточки отправляется следующим сообщением
|
||||
|
||||
#### Scenario: пост с видео
|
||||
|
||||
- Given пост с content_type=video и media_path=media/xyz.mp4
|
||||
- When модератор подтверждает пост
|
||||
- Then в канал отправляется видео (sendVideo) первым сообщением
|
||||
- And текст карточки отправляется следующим сообщением
|
||||
|
||||
### Requirement: Карточка репоста — без служебной информации
|
||||
|
||||
Служебная информация (направление/язык, источник, просмотры/реакции)
|
||||
MAY НЕ выводиться в теле поста; основное содержимое — текст, комментарий, ссылка на
|
||||
оригинал.
|
||||
|
||||
#### Scenario: пост без служебки
|
||||
|
||||
- Given внешний пост с направлением и просмотрами
|
||||
- When карточка формируется
|
||||
- Then в тексте карточки НЕТ строк «📁 linux / ru», «📰 источник», «👁 123 💬 4»
|
||||
- And текст содержит полный текст поста и ссылку на оригинал
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Формат карточки (publisher/card.py)
|
||||
|
||||
Функция make_card MUST принимать необязательный параметр `comment` и
|
||||
строить текст из: комментария (если задан), полного текста поста, ссылки на оригинал
|
||||
(атрибуция для своих).
|
||||
|
||||
#### Scenario: make_card с comment
|
||||
|
||||
- Given post с текстом «Важная новость» и comment «Мой комментарий»
|
||||
- When вызывается make_card(post, comment)
|
||||
- Then результат содержит «Мой комментарий» перед «Важная новость»
|
||||
- And ссылка на оригинал присутствует
|
||||
|
||||
#### Scenario: make_card без comment
|
||||
|
||||
- Given post с текстом «Важная новость» и comment=None
|
||||
- When вызывается make_card(post)
|
||||
- Then результат НЕ содержит пустого первого блока
|
||||
- And результат содержит полный текст «Важная новость» и ссылку на оригинал
|
||||
|
||||
### Requirement: Отправка медиа в publisher-service
|
||||
|
||||
Сервис публикации MUST отправлять медиа первым и текст вторым; для
|
||||
sendMessage параметр link_preview_options MUST отключать предпросмотр ссылки.
|
||||
|
||||
#### Scenario: sendMessage без предпросмотра
|
||||
|
||||
- Given канал @dedinit_vesti и текст со ссылкой на оригинал
|
||||
- When вызывается sendMessage
|
||||
- Then параметр link_preview_options={"is_disabled": True} передаётся в Bot API
|
||||
|
||||
#### Scenario: sendVideo для mp4
|
||||
|
||||
- Given файл media/xyz.mp4 существует в медиа-маунте
|
||||
- When публикуется пост с этим видео
|
||||
- Then вызывается sendVideo (а не sendPhoto)
|
||||
- And текст отправляется следом
|
||||
@@ -0,0 +1,24 @@
|
||||
## 1. Карточка (publisher/card.py)
|
||||
|
||||
- [ ] 1.1 `make_card(post, comment=None)`: полный текст поста вместо сниппета; служебка (📁/📰/👁) убрана; ссылка на оригинал последней строкой; comment первым
|
||||
- [ ] 1.2 HTML-экранирование comment (XSS-safe как текст)
|
||||
- [ ] 1.3 Медиа: разрешить video (.mp4), фильтр не отбрасывает
|
||||
- [ ] 1.4 Проверка: карточка ≤4096, эмодзи/ссылки на месте
|
||||
|
||||
## 2. Publisher-сервис (services/publisher/)
|
||||
|
||||
- [ ] 2.1 `telegram.py`: `send_media` (photo/video по расширению) + `send_video`; sendMessage с `link_preview_options={"is_disabled": True}`
|
||||
- [ ] 2.2 `main.py`: Card + `comment`; если media → send_media первым, затем send_message
|
||||
- [ ] 2.3 healthz/publish не ломаются; Docker пересобран (медиа-маунт уже есть)
|
||||
|
||||
## 3. Веб (web/)
|
||||
|
||||
- [ ] 3.1 `candidates.html`: поле «Комментарий (по желанию)» в форме approve (все посты)
|
||||
- [ ] 3.2 `app.py` approve: читать `comment` из формы, передать в card
|
||||
- [ ] 3.3 Проверка: approve с комментарием → в канале комментарий первым, текст полный, ссылка без превью
|
||||
|
||||
## 4. Документация и регресс
|
||||
|
||||
- [ ] 4.1 requirements без изменений (media/video — Bot API)
|
||||
- [ ] 4.2 STATUS.md / PRD.md / TODO.md обновлены
|
||||
- [ ] 4.3 Регресс: старые посты (текст) публикуются как раньше, тест в канал реальный (1 пост)
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-08
|
||||
@@ -0,0 +1,105 @@
|
||||
# Design: tg-crawler-publisher-prototype
|
||||
|
||||
## Approach
|
||||
|
||||
Прототип = вертикаль «TG-источники → классификация → подтверждение → публикация → банк статей» на направлении Линукс (ru). Горизонталь (n8n, Postgres, S3, VK/fediverse-боты, веб-на-домене) — фаза 2+.
|
||||
|
||||
Поток данных:
|
||||
```
|
||||
sources.yaml (реестр, git)
|
||||
│
|
||||
▼
|
||||
telegram_crawler.py (cron: каждые 15 мин, Telethon через SOCKS5 :1080)
|
||||
│ инкрементально после last_post_id, метрики views/reactions
|
||||
│ форварды: fwd_from → донор; свой источник → пропуск; чужой → fwd-поля без медиа
|
||||
│ медиа: content_type + скачивание media/{channel}_{post_id}.{ext}, без повторных загрузок
|
||||
▼
|
||||
SQLite /opt/vesti/db/vesti.db (raw-посты, состояния каналов)
|
||||
│
|
||||
▼
|
||||
classifier.py (локальный qwen3:8b-nothink + словарный фильтр)
|
||||
│ направление: linux, релевантность, summary, интересность 1-5
|
||||
▼
|
||||
SQLite (статьи-кандидаты: candidate/new/approved/published/rejected)
|
||||
│
|
||||
▼
|
||||
vesti-web (FastAPI + Bootstrap 5.3 + Jinja2 + HTMX, 127.0.0.1:8400)
|
||||
│ админ-панель: кандидаты → подтвердить/отклонить, метрики
|
||||
▼ (подтверждённые)
|
||||
tg-publisher.py (Bot API: карточка-пост в канал @dedinit_vesti_linux_ru_bot)
|
||||
▼
|
||||
bundles/linux/2026-09/<slug>.md (markdown + frontmatter) + media/
|
||||
```
|
||||
|
||||
## Files
|
||||
|
||||
```
|
||||
/opt/vesti/
|
||||
├── docker-compose.yml # (фаза 2; прототип — systemd/python)
|
||||
├── .env # секреты (не в git): токен бота, api_hash
|
||||
├── requirements.txt # telethon, httpx, feedparser, fastapi, uvicorn, jinja2, python-dotenv, dateutil
|
||||
├── sources/sources.yaml # реестр источников (продолжение формата /opt/news)
|
||||
├── crawler/
|
||||
│ ├── __init__.py
|
||||
│ ├── telegram_crawler.py # Telethon-краулер, инкрементальный, форварды, медиа
|
||||
│ └── state.py # last_post_id на канал (SQLite)
|
||||
├── classifier/
|
||||
│ ├── __init__.py
|
||||
│ ├── keywords.py # словари по направлениям (linux-слова теперь)
|
||||
│ └── classify.py # qwen3:8b-nothink JSON: direction, relevance, interest, summary
|
||||
├── publisher/
|
||||
│ ├── __init__.py
|
||||
│ ├── bot.py # Bot API публикация (карточка)
|
||||
│ └── card.py # форматирование карточки в лимит поста
|
||||
├── web/
|
||||
│ ├── __init__.py
|
||||
│ ├── app.py # FastAPI
|
||||
│ ├── auth.py # простая сессия/пароль (одна учётка)
|
||||
│ ├── templates/ # Jinja2: base, index, candidates, metrics, login
|
||||
│ └── static/ # bootstrap 5.3 (CDN fallback локально)
|
||||
├── bundles/ # банк статей (git-репо vesti-bundles)
|
||||
│ └── linux/2026-09/<slug>.md
|
||||
├── media/ # скачанные медиа-файлы постов (media/{channel}_{post_id}.{ext})
|
||||
├── db/ # vesti.db (не в git)
|
||||
└── scripts/
|
||||
└── run_all.sh # запуск краулера+классификатора+публикатора
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
```bash
|
||||
# Установка зависимостей
|
||||
cd /opt/vesti && python3.12 -m venv .venv && .venv/bin/pip install -r requirements.txt
|
||||
|
||||
# Краулер (ручной прогон)
|
||||
.venv/bin/python -m crawler.telegram_crawler --channels linux
|
||||
|
||||
# Классификатор
|
||||
.venv/bin/python -m classifier.classify --direction linux
|
||||
|
||||
# Веб (локально)
|
||||
cd /opt/vesti && .venv/bin/uvicorn web.app:app --host 127.0.0.1 --port 8400
|
||||
|
||||
# Проверка: живой ли веб
|
||||
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8400/login
|
||||
```
|
||||
|
||||
## Rollback
|
||||
|
||||
```bash
|
||||
# Остановить сервисы
|
||||
sudo systemctl stop vesti-crawler vesti-publisher vesti-web # (или kill процессов)
|
||||
# Веб больше не слушает
|
||||
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8400/ # → 000
|
||||
# Удалить каталог прототипа (только по явному согласованию с пользователем)
|
||||
rm -rf /opt/vesti
|
||||
```
|
||||
Существующий /opt/news не затрагивается.
|
||||
|
||||
## Risks
|
||||
|
||||
- **Авторизация Telegram-сессии**: Telethon-сессия /opt/news/telegram/ переиспользуется; если она протухла/забанена — нужна разовая интерактивная авторизация (код) — потребует участия пользователя.
|
||||
- **Flood-wait/429 в TG**: Telethon обходит автоматически; лимит ~20 постов/канал/запуск.
|
||||
- **qwen3:8b требует `extra_body={"think": false}`** (известный quirk) — иначе пустой content.
|
||||
- **Скриншоты/текст исходников**: в прототипе сохраняем текст + ссылку (полный HTML/скриншоты — фаза 2).
|
||||
- Секреты: токен бота и api_hash только в .env, не коммитить.
|
||||
@@ -0,0 +1,35 @@
|
||||
## Why
|
||||
|
||||
VESTI — новостной агрегатор с веб-интерфейсом (транслитерация «вести»). Эволюция /opt/news: от «базы ИТ/hospitality новостей» к полноценному медиа-конвейеру: краулинг из многих источников → дедуп и слияние в одну статью → факт-чек → категоризация → банк markdown-статей → дайджесты для еженедельных видео + ленты ботов (Telegram, VK, fediverse).
|
||||
|
||||
Первый рабочий прототип — вертикаль: **Telegram-краулер публичных каналов + бот-публикатор в новостной канал + минимальный веб**. Это даёт рабочий конвейер «источник → отбор → публикация» на одном направлении (Линукс, русский язык) быстрее всего.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Создать сервис-краулер: Telethon (MTProto) читает публичные Telegram-каналы из реестра источников, инкрементально (после `last_post_id`), метрики постов (views/reactions) сохраняются.
|
||||
- Создать классификатор: локальный LLM (Ollama qwen3:8b-nothink) относит пост к направлению (Технологии/Политика/Игры/Электроника/БЯМ/Линукс) и оценивает релевантность/интересность.
|
||||
- Создать бот-публикатор: Telegram Bot API, режим «черновик на подтверждение» (C2-b) — человек подтверждает пост в вебе/личке до публикации в канале; формат поста — карточка в лимит одного поста с картинкой в начале (C3).
|
||||
- Создать минимальный веб-интерфейс: FastAPI + Bootstrap 5.3 + Jinja2 + HTMX, авторизация (один админ), список внешних новостей с метриками, список опубликованных, черновики на подтверждение, базовая метрика интереса.
|
||||
- Первые направления: Линукс, язык ru. Канал-источник: прототип на t.me/linuxklub и других линукс-каналах из списка пользователя.
|
||||
- n8n: НЕ входит в прототип (только RSS/email/сайты на фазе 2). Веб — только локально. WeChat/X — фаза 2+.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `tg-crawler`: Чтение публичных Telegram-каналов через Telethon (MTProto) через SOCKS5-туннель, инкрементальный обход, сбор метрик постов.
|
||||
- `classifier`: Классификация постов по направлениям (Технологии/Политика/Игры/Электроника/БЯМ/Линукс) локальным LLM + словарный быстрый фильтр.
|
||||
- `tg-publisher`: Telegram-бот-публикатор с режимом «черновик на подтверждение», формат карточки поста.
|
||||
- `vesti-web`: Веб-интерфейс управления: списки внешних/своих новостей, метрики, подтверждение черновиков, авторизация.
|
||||
- `news-store`: Банк статей: markdown-бандлы с frontmatter (заголовок, направление, источники, метрики) + media/ рядом; SQLite для прототипа (Postgres — следующий шаг по решению D1).
|
||||
|
||||
### Modified Capabilities
|
||||
- (нет)
|
||||
|
||||
## Impact
|
||||
|
||||
- Новые каталоги/сервисы: /opt/vesti/crawler, /opt/vesti/classifier, /opt/vesti/publisher, /opt/vesti/web, /opt/vesti/bundles.
|
||||
- Зависимости: Telethon (уже в /opt/news), Ollama qwen3:8b-nothink (:11434), python-telegram-bot (Bot API), FastAPI, Bootstrap 5.3 (CDN), SQLite.
|
||||
- Секреты: api_id/api_hash (24276216, из /opt/icq/docker-compose.yml), Telethon-сессия (переиспользуем /opt/news/telegram/), токен бота — в .env.
|
||||
- Порт: веб 127.0.0.1:8400 (локально).
|
||||
- Git: новые репозитории (источник истины gitverse.ru, зеркало gitea bigbox:3000).
|
||||
- Rollback: прототип не трогает существующий /opt/news; удаление — остановка systemd-юнитов/контейнеров и удаление каталогов /opt/vesti (по согласованию).
|
||||
@@ -0,0 +1,33 @@
|
||||
## Purpose
|
||||
|
||||
Классификация собранных постов по направлениям (Технологии, Политика, Игры, Электроника, БЯМ, Линукс) с оценкой релевантности и интереса.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Быстрый словарный фильтр по направлениям
|
||||
Система MUST сначала прогонять пост через словарный фильтр (keywords.py): совпадение по словам направления (например, linux, kernel, distro, gnome, kde для Линукс) → кандидат на направление.
|
||||
|
||||
#### Scenario: Пост про Linux
|
||||
- **WHEN** пост содержит слова «kernel», «gnome», «apt» и т.п.
|
||||
- **THEN** пост помечается кандидатом на направление Линукс без вызова LLM
|
||||
|
||||
### Requirement: LLM-классификация локальным qwen3:8b-nothink
|
||||
Система MUST для кандидатов вызывать Ollama qwen3:8b-nothink (extra_body={"think": false}) с запросом JSON: direction, relevance (critical/high/low), interest (1-5), summary. Если модель недоступна — пост остаётся unclassified.
|
||||
|
||||
#### Scenario: LLM-классификация поста
|
||||
- **WHEN** пост прошёл словарный фильтр и вызывает classifier.classify()
|
||||
- **THEN** возвращается JSON с direction/relevance/interest/summary, запись помечается classified
|
||||
|
||||
### Requirement: Релевантность определяет обработку
|
||||
Посты с relevance=critical/high MUST появляться в веб-кандидатах для подтверждения; low — оставаться в БД, но не показываться как кандидаты по умолчанию.
|
||||
|
||||
#### Scenario: Низкая релевантность
|
||||
- **WHEN** классификатор ставит relevance=low
|
||||
- **THEN** пост виден в вебе только при явном фильтре «все», в кандидатах по умолчанию отсутствует
|
||||
|
||||
### Requirement: Оценка интереса 1-5
|
||||
Классификатор SHOULD выставлять interest (1-5) на основе остроты темы и вовлечённости (реакции/просмотры поста).
|
||||
|
||||
#### Scenario: Хайповый пост
|
||||
- **WHEN** пост имеет много просмотров и реакций
|
||||
- **THEN** классификатор учитывает это и может поднять interest
|
||||
@@ -0,0 +1,33 @@
|
||||
## Purpose
|
||||
|
||||
Банк статей VESTI: markdown-файлы с frontmatter (метаданными) и мультимедиа в каталогах-бандлах.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Markdown-бандлы с frontmatter
|
||||
Каждая статья MUST храниться как markdown-файл с YAML frontmatter: title, date, direction (направление), source (источник), url, views, reactions, interest, status. Путь: bundles/<направление>/<YYYY-MM>/<slug>.md.
|
||||
|
||||
#### Scenario: Создание статьи в банке
|
||||
- **WHEN** пост подтверждён и опубликован
|
||||
- **THEN** в bundles/linux/2026-09/<slug>.md создаётся файл с frontmatter и телом (summary + ссылки на источники)
|
||||
|
||||
### Requirement: Медиа рядом со статьёй
|
||||
Медиа-файлы статьи MUST храниться в подкаталоге media/ рядом с markdown (<bundles>/<direction>/<YYYY-MM>/media/<article-slug>/). Ссылки в frontmatter указывают относительные пути.
|
||||
|
||||
#### Scenario: Статья с картинкой
|
||||
- **WHEN** пост имеет картинку
|
||||
- **THEN** картинка сохраняется в media/<slug>/ и упоминается в frontmatter
|
||||
|
||||
### Requirement: Ссылки на все источники
|
||||
Статья MUST содержать раздел «Источники» с ссылками на все связанные посты/страницы (для атрибуции и защиты от претензий).
|
||||
|
||||
#### Scenario: Несколько источников
|
||||
- **WHEN** новость собрана из 2+ источников
|
||||
- **THEN** каждый источник указан в разделе «Источники» с URL
|
||||
|
||||
### Requirement: Версионирование банка в git
|
||||
Банк статей MUST храниться в отдельном git-репозитории (vesti-bundles) для истории и бэкапов (источник истины gitverse.ru, зеркало gitea).
|
||||
|
||||
#### Scenario: Коммит после публикации
|
||||
- **WHEN** создаётся новая статья
|
||||
- **THEN** репозиторий банка получает коммит (или ставится в очередь авто-коммита)
|
||||
@@ -0,0 +1,66 @@
|
||||
## Purpose
|
||||
|
||||
Чтение публичных Telegram-каналов через Telethon (MTProto) для сбора новостей с метриками популярности.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Чтение публичных каналов через SOCKS5-туннель
|
||||
Система MUST читать публичные Telegram-каналы через Telethon, подключаясь ТОЛЬКО через SOCKS5 127.0.0.1:1080 (telegram-tunnel → VPS01). Прямое подключение из РФ заблокировано.
|
||||
|
||||
#### Scenario: Краулер подключается к каналу
|
||||
- **WHEN** запускается telegram_crawler.py для канала из sources.yaml
|
||||
- **THEN** соединение идёт через socks5://127.0.0.1:1080, и посты канала читаются
|
||||
|
||||
### Requirement: Инкрементальный обход каналов
|
||||
Краулер MUST хранить last_post_id/last_ts на канал (таблица tg_state) и при следующем запуске читать только посты после последнего.
|
||||
|
||||
#### Scenario: Повторный запуск
|
||||
- **WHEN** краулер запускается повторно для того же канала
|
||||
- **THEN** запрашиваются только посты с id > last_post_id; дубли в БД не появляются
|
||||
|
||||
### Requirement: Сбор метрик постов
|
||||
Краулер MUST сохранять для каждого поста: text, ссылки, views (просмотры), реакции (реакции), дату, канал. Метрики хранятся в SQLite vesti.db.
|
||||
|
||||
#### Scenario: Пост с реакциями
|
||||
- **WHEN** пост канала имеет просмотры и реакции
|
||||
- **THEN** views и reactions сохраняются в записи поста и доступны веб-интерфейсу
|
||||
|
||||
### Requirement: Устойчивость к rate-limit
|
||||
Краулер MUST соблюдать лимиты Telegram (flood-wait, 429): не более ~20 постов/канал/запуск, автоматическая пауза при 429 (встроено в Telethon), повторный запуск не ломает состояние.
|
||||
|
||||
#### Scenario: Telegram отвечает 429
|
||||
- **WHEN** Telegram отдаёт flood-wait при чтении канала
|
||||
- **THEN** краулер ждёт необходимое время и продолжает; ошибка не теряет last_post_id
|
||||
|
||||
### Requirement: Обработка форвардов (пересланных постов)
|
||||
Краулер MUST анализировать поле `fwd_from` у каждого поста. Если пост переслан из канала (PeerChannel), определять канал-донор (channel_id) и номер исходного поста (channel_post).
|
||||
|
||||
Политика:
|
||||
- **Донор есть в списке источников** — пост MUST НЕ сохраняться (дубль исходного; исходный придёт от своего источника).
|
||||
- **Донора нет в источниках** — пост MAY сохраняться как «упоминание» с полями `fwd_from_channel_id` / `fwd_from_post_id`; медиа для такого поста MUST НЕ скачиваться (контент принадлежит донору).
|
||||
|
||||
#### Scenario: Канал пересылает из источника
|
||||
- **WHEN** канал B (не источник) пересылает пост канала A (источник)
|
||||
- **THEN** пост НЕ сохраняется в БД; дубликат исходного не создаётся
|
||||
|
||||
#### Scenario: Канал пересылает из не-источника
|
||||
- **WHEN** канал B пересылает пост канала C (не в списке источников)
|
||||
- **THEN** пост сохраняется с fwd_from_channel_id/fwd_from_post_id, media_path=NULL (медиа не скачивается)
|
||||
|
||||
### Requirement: Дедупликация контента
|
||||
Краулер MUST не создавать дубликаты: (1) один и тот же пост канала (url) не сохраняется дважды; (2) посты с одинаковым текстом (sha256) не сохраняются дважды.
|
||||
|
||||
#### Scenario: Повторный краулинг того же поста
|
||||
- **WHEN** пост с тем же url/text уже есть в БД
|
||||
- **THEN** новый экземпляр не создаётся; существующий может дополняться метаданными (content_type, media_path, fwd-поля), но не дублироваться
|
||||
|
||||
### Requirement: Типы контента и медиа
|
||||
Краулер MUST определять тип контента поста (text/photo/video/document/voice/sticker) и для медиа-постов скачивать файл в `media/` (путь `media/{channel}_{post_id}.{ext}`), сохраняя `content_type` и `media_path` в БД. Медиа НЕ должно скачиваться повторно: если файл уже есть на диске, повторное скачивание MUST быть пропущено.
|
||||
|
||||
#### Scenario: Пост с фото
|
||||
- **WHEN** пост содержит фото
|
||||
- **THEN** content_type='photo', media_path='media/{channel}_{post_id}.jpg', файл существует
|
||||
|
||||
#### Scenario: Повторный запуск с уже скачанным медиа
|
||||
- **WHEN** медиа-файл уже существует в media/
|
||||
- **THEN** файл не скачивается заново (экономия трафика/лимитов)
|
||||
@@ -0,0 +1,33 @@
|
||||
## Purpose
|
||||
|
||||
Публикация отобранных новостей в Telegram-канал через Bot API (бот @dedinit_vesti_<направление>_<язык>_bot), с режимом подтверждения человеком.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Режим «черновик на подтверждение»
|
||||
Система MUST NOT публиковать посты автоматически: каждый пост сначала становится черновиком в вебе, публикуется ТОЛЬКО после явного подтверждения человеком.
|
||||
|
||||
#### Scenario: Новый кандидат
|
||||
- **WHEN** кандидат проходит классификацию с relevance=critical/high
|
||||
- **THEN** он появляется в вебе как «черновик на подтверждение» и НЕ публикуется в канал до клика «Опубликовать»
|
||||
|
||||
### Requirement: Формат поста — карточка в лимит одного поста
|
||||
Каждый опубликованный пост MUST укладываться в лимит Telegram-сообщения: картинка/медиа в начале (если есть), затем заголовок, краткое описание (summary), направление, ссылка на источник. Длина текста ≤ 4096 символов.
|
||||
|
||||
#### Scenario: Пост с картинкой
|
||||
- **WHEN** у поста есть медиа (картинка)
|
||||
- **THEN** картинка отправляется как фото (первым сообщением/вложением), затем текст-карточка единым сообщением
|
||||
|
||||
### Requirement: Идентификация канала по направлению/языку
|
||||
Имя бота/канала формируется по шаблону @dedinit_vesti_<направление>_<язык>_bot (например @dedinit_vesti_linux_ru_bot). Параметры направления/языка берутся из конфигурации (.env/config).
|
||||
|
||||
#### Scenario: Публикация в правильный канал
|
||||
- **WHEN** подтверждается пост направления linux, язык ru
|
||||
- **THEN** он публикуется в канал, соответствующий @dedinit_vesti_linux_ru_bot
|
||||
|
||||
### Requirement: Метрики своих постов
|
||||
Бот/веб MUST сохранять для опубликованных постов views (просмотры) через Bot API, чтобы вести метрики популярности своих публикаций.
|
||||
|
||||
#### Scenario: Просмотры своего поста
|
||||
- **WHEN** опубликованный пост получает просмотры
|
||||
- **THEN** веб периодически опрашивает Bot API и сохраняет views для аналитики
|
||||
@@ -0,0 +1,40 @@
|
||||
## Purpose
|
||||
|
||||
Веб-интерфейс управления VESTI: авторизация, списки кандидатов и опубликованных новостей, метрики, подтверждение черновиков.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Локальный запуск с авторизацией
|
||||
Веб MUST запускаться на 127.0.0.1:8400 (только локально, без внешнего домена) и требовать авторизацию (одна учётная запись админа, пароль в .env).
|
||||
|
||||
#### Scenario: Доступ без авторизации
|
||||
- **WHEN** неавторизованный пользователь открывает /
|
||||
- **THEN** он перенаправляется на /login
|
||||
|
||||
### Requirement: Список внешних новостей с метриками
|
||||
Веб MUST показывать список внешних постов (источник, заголовок, направление, views/reactions, дата) с фильтрами по направлению и статусу.
|
||||
|
||||
#### Scenario: Фильтр по направлению
|
||||
- **WHEN** админ выбирает направление «Линукс»
|
||||
- **THEN** отображаются только посты этого направления
|
||||
|
||||
### Requirement: Подтверждение черновиков
|
||||
Веб MUST позволять админу подтверждать («Опубликовать») или отклонять черновики; подтверждение запускает публикацию через tg-publisher.
|
||||
|
||||
#### Scenario: Подтверждение поста
|
||||
- **WHEN** админ нажимает «Опубликовать» на черновике
|
||||
- **THEN** пост отправляется в канал, статус меняется на published, в банк создаётся markdown-файл
|
||||
|
||||
### Requirement: Список опубликованных с метриками
|
||||
Веб MUST показывать опубликованные посты с их метриками (views своих постов из Bot API) и ссылкой на markdown-бандл.
|
||||
|
||||
#### Scenario: Просмотр опубликованного
|
||||
- **WHEN** админ открывает список опубликованных
|
||||
- **THEN** видны views/дата/ссылка на статью в банке
|
||||
|
||||
### Requirement: Быстрый интерфейс на Bootstrap
|
||||
UI MUST строиться на Bootstrap 5.3 (CDN или локальный fallback) + Jinja2-шаблоны + HTMX для обновления списков без полной перезагрузки.
|
||||
|
||||
#### Scenario: Обновление списка кандидатов
|
||||
- **WHEN** админ меняет статус черновика
|
||||
- **THEN** список обновляется через HTMX-запрос без перезагрузки страницы
|
||||
@@ -0,0 +1,71 @@
|
||||
## 1. Каркас проекта и инфраструктура
|
||||
|
||||
- [ ] 1.1 Создать каталоги /opt/vesti/{crawler,classifier,publisher,web,bundles,db,sources,scripts,static}
|
||||
- [ ] 1.2 Создать .venv и установить зависимости (requirements.txt): telethon, httpx, feedparser, fastapi, uvicorn, jinja2, python-dotenv, python-dateutil, python-telegram-bot, aiofiles
|
||||
- [ ] 1.3 Создать /opt/vesti/.env (не в git): TG_API_ID=24276216, TG_API_HASH=..., VESTI_BOT_TOKEN=..., ADMIN_PASSWORD=...
|
||||
- [ ] 1.4 Скопировать/создать sources/sources.yaml с источниками (формат /opt/news), первые направление: linux (linuxklub, linuxos_tg, dotfiles_linux, linux_education, LinuxMastery, linuxcamp_tg, gitgate, krxnotes)
|
||||
- [ ] 1.5 Инициализировать гит в /opt/vesti (отдельно от openspec), .gitignore (.env, db/, media/, __pycache__)
|
||||
- [ ] 1.6 Создать минимальную схему SQLite /opt/vesti/db/vesti.db (посты, каналы, состояния, черновики, опубликованные) — копия/адаптация /opt/news
|
||||
|
||||
Проверка: `ls /opt/vesti/{crawler,classifier,publisher,web}` существуют; `.venv/bin/python -c "import telethon, fastapi"`; `sqlite3 /opt/vesti/db/vesti.db ".tables"` показывает таблицы.
|
||||
|
||||
## 2. Telegram-краулер
|
||||
|
||||
- [x] 2.1 Написать crawler/telegram_crawler.py: Telethon через SOCKS5 :1080, чтение каналов из sources.yaml
|
||||
- [x] 2.2 Инкрементальность: таблица tg_state(last_post_id, last_ts), чтение только новых постов
|
||||
- [x] 2.3 Сбор метрик: text, ссылки (entities), views, reactions, дата, канал → SQLite
|
||||
- [x] 2.4 Обработка 429/flood-wait: пауза, лимит ~20 постов/канал/запуск, сохранение состояния
|
||||
- [x] 2.5 Создана собственная Telethon-сессия /opt/vesti/telegram/vesti.session (не /opt/news; там сессии нет), авторизована, используется краулером
|
||||
- [x] 2.6 Обработка форвардов: анализ fwd_from, пропуск форвардов из своих источников, сохранение «чужих» с fwd_from_channel_id/fwd_from_post_id без скачивания медиа
|
||||
- [x] 2.7 Типы контента (content_type: text/photo/video/document/voice/sticker) + скачивание медиа в media/ + дедуп: пост уже в БД (url/sha256) не дублируется, медиа не качается повторно
|
||||
|
||||
Проверка: ручной прогон `python -m crawler.telegram_crawler --channels linux` без ошибок; в БД появились посты с views/reactions; повторный запуск не дублирует.
|
||||
|
||||
## 3. Классификатор
|
||||
|
||||
- [x] 3.1 Написать classifier/keywords.py: словари направлений (linux: linux, kernel, distro, gnome, kde, apt, systemd, arch, ubuntu, fedora, debian...)
|
||||
- [x] 3.2 Написать classifier/classify.py: вызов Ollama qwen3:8b-nothink (extra_body think:false), JSON: direction, relevance, interest, summary
|
||||
- [x] 3.3 Обработка недоступности LLM: пост остаётся unclassified, не теряется
|
||||
- [x] 3.4 Фолбэк без LLM: если Ollama недоступна, статья проходит словарный фильтр + базовые эвристики
|
||||
|
||||
Проверка: `python -m classifier.classify --direction linux` на тестовом посте возвращает валидный JSON; недоступная модель не роняет скрипт.
|
||||
|
||||
## 4. Бот-публикатор
|
||||
|
||||
- [x] 4.1 Написать publisher/card.py: формат карточки (заголовок, summary, направление, ссылка на источник) ≤ 4096 символов
|
||||
- [x] 4.2 Написать publisher/bot.py: Bot API публикация (фото, если есть + текст-карточка)
|
||||
- [x] 4.3 Конфигурация канала по шаблону: @dedinit_vesti_<направление>_<язык>_bot (для прототипа — linux_ru)
|
||||
- [x] 4.4 Публикация ТОЛЬКО по явному подтверждению (флаг approved в БД); никакого автопостинга (publish() вызывается только из веба по клику)
|
||||
- [x] 4.5 Опрос views опубликованных постов через Bot API → сохранение метрик (get_views)
|
||||
|
||||
Проверка: скрипт публикации с тестовым постом (сухой прогон без отправки: `--dry-run` печатает карточку); после реальной отправки в БД появляется message_id и растут views.
|
||||
|
||||
## 5. Веб-интерфейс
|
||||
|
||||
- [x] 5.1 Написать web/app.py (FastAPI): роуты /, /login, /candidates, /published, /metrics
|
||||
- [x] 5.2 Авторизация: одна учётка, пароль из .env, session-cookie
|
||||
- [x] 5.3 Шаблоны Jinja2 + Bootstrap 5.3 (CDN) + HTMX: base.html, login.html, candidates.html, published.html, metrics.html
|
||||
- [x] 5.4 Кандидаты: список с фильтром по направлению/статусу; кнопки «Опубликовать»/«Отклонить» (HTMX, без перезагрузки)
|
||||
- [x] 5.5 Опубликованные: список со views/датой/ссылкой на бандл (/bundle/{path}); метрики
|
||||
- [ ] 5.6 Uvicorn на 127.0.0.1:8400 (systemd-юнит vesti-web.service — фаза запуска)
|
||||
|
||||
Проверка: `curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8400/login` → 200; без куки `/` → редирект на /login; HTMX-действие «Опубликовать» меняет статус без полной перезагрузки.
|
||||
|
||||
## 6. Банк статей (news-store)
|
||||
|
||||
- [x] 6.1 Написать web/store.py (или отдельный модуль): создание markdown-файла bundles/<direction>/<YYYY-MM>/<slug>.md с frontmatter
|
||||
- [x] 6.2 Сохранение медиа в media/<slug>/ (если есть картинка), относительные пути в frontmatter
|
||||
- [x] 6.3 Раздел «Источники» с ссылками на все URL
|
||||
- [ ] 6.4 Git-инициализация /opt/vesti/bundles (репо vesti-bundles), авто-коммит после публикации (или очередь)
|
||||
- [ ] 6.5 Связка: подтверждение в вебе → публикация в TG → создание бандла
|
||||
|
||||
Проверка: после публикации файл `bundles/linux/2026-09/<slug>.md` существует, содержит frontmatter (direction: linux, url, views), тело с summary и «Источники»; `git -C bundles log --oneline -1` показывает коммит.
|
||||
|
||||
## 7. Запуск и мониторинг
|
||||
|
||||
- [ ] 7.1 systemd-юниты: vesti-crawler.timer (каждые 15 мин), vesti-web.service, vesti-publisher (вызывается вебом)
|
||||
- [ ] 7.2 Watchdog: no_agent cron, молчит если всё живо; шумит при dead↔alive канала/краулера (политика пользователя)
|
||||
- [ ] 7.3 README.md в /opt/vesti с портами, командами, схемой (точность портов — приоритет пользователя)
|
||||
- [ ] 7.4 Тест полного цикла: канал → краулер → классификатор → кандидат в вебе → подтверждение → публикация → бандл
|
||||
|
||||
Проверка: `systemctl --user status vesti-web` (или system) активен; watchdog молчит 3 дня подряд при здоровой системе; полный цикл проходит без ручных вмешательств кроме подтверждения.
|
||||
@@ -0,0 +1,3 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-13
|
||||
skip_specs: true
|
||||
@@ -0,0 +1,51 @@
|
||||
## Design
|
||||
|
||||
### Единый канон направлений
|
||||
|
||||
Создать константу в `classifier/keywords.py` (или отдельный `directions.py`):
|
||||
|
||||
```python
|
||||
# Канонический список направлений (AGENT.MD, веб-форма): linux, tech, politics, games, electronics, llm
|
||||
DIRECTIONS_CANON = ["linux", "tech", "politics", "games", "electronics", "llm"]
|
||||
```
|
||||
|
||||
### classify.py:87
|
||||
|
||||
```python
|
||||
from classifier.keywords import DIRECTIONS_CANON # или импорт по месту
|
||||
...
|
||||
"direction": "одно из: " + ", ".join(sorted(DIRECTIONS_CANON)),
|
||||
```
|
||||
|
||||
(убрать локальный список `['linux','dev','ai','tech','games','electronics','media']`).
|
||||
|
||||
### web/app.py:130
|
||||
|
||||
```python
|
||||
directions=DIRECTIONS_CANON # вместо ['linux','dev','ai','tech','games','electronics','media']
|
||||
```
|
||||
|
||||
(импортировать из classifier.keywords, чтобы список был один).
|
||||
|
||||
### keywords.py DIRECTIONS
|
||||
|
||||
Привести ключи к канону:
|
||||
- оставить: linux, tech, games, electronics
|
||||
- добавить: politics (ключевые слова: политика, президент, выборы, закон, санкции, война, мир, госдума, кремль, etc.)
|
||||
- llm (ключевые слова: llm, gpt, нейросеть, claude, gemini, ollama, qwen, transformer, диффузия, sota, промпт, токен, fine-tune)
|
||||
- dev/media/ai — в каноне их НЕТ: dev-ключевые слова перенести частично в tech (разработка, программирование, код, api, backend) или оставить под tech; отсутствующие направления удалить (или оставить с пустым списком — классификатор их не выберет, т.к. канон в промпте ограничивает).
|
||||
|
||||
### Переклассификация
|
||||
|
||||
```bash
|
||||
cd /opt/vesti
|
||||
CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --db db/vesti.db --limit 1000
|
||||
```
|
||||
(обработает все 466 своих без direction; новые направления — только канонические).
|
||||
|
||||
### Верификация
|
||||
|
||||
- `openspec validate unify-directions` — чисто.
|
||||
- В БД после переклассификации: 0 постов is_own=1 без direction (или минимум),
|
||||
нет направлений вне канона (dev/media/ai остаются только legacy, не вновь).
|
||||
- Веб /candidates: фильтр по направлению показывает только канонические.
|
||||
@@ -0,0 +1,35 @@
|
||||
## Why
|
||||
|
||||
Канонический список направлений проекта: **linux, tech, politics, games, electronics, llm**
|
||||
(AGENT.MD, веб-форма fan-out). Но классификатор и веб используют ДРУГОЙ список:
|
||||
`linux, dev, ai, tech, games, electronics, media` (classify.py:87, web/app.py:130,
|
||||
keywords.py). Из-за этого:
|
||||
|
||||
- LLM получает на выбор dev/ai/media и никогда не предложит politics/llm;
|
||||
- по факту в БД у своих постов появились направления dev (102), media (50), ai (33),
|
||||
которых нет в каноне; при публикации fan-out по ним не сработает (веб-форма их не предлагает);
|
||||
- 466 из 847 своих постов остались БЕЗ направления (не нашлось ни совпадения по словарю
|
||||
под канон, ни LLM-варианта) — классификатору некорректно задавали список.
|
||||
|
||||
Нужно привести все места к единому канону направлений.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Единый список направлений: `["linux", "tech", "politics", "games", "electronics", "llm"]`.
|
||||
- `classifier/classify.py:87` — промпт LLM: использовать канон вместо локального списка.
|
||||
- `web/app.py:130` — фильтр веба: канон.
|
||||
- `classifier/keywords.py` — DIRECTIONS: привести к канону (dev/media/ai → убрать или
|
||||
переименовать в tech/llm; добавить politics), чтобы словарь ставил только канонические.
|
||||
- Переклассифицировать 466 своих постов без направления (limit большой) — LLM теперь
|
||||
ставит politics/llm корректно.
|
||||
- Legacy-значения в БД (dev/media/ai) — не удалять (правило: физически ничего не удаляем),
|
||||
но при публикации они сами собой не выберутся (форма не предложит).
|
||||
|
||||
## Why Not
|
||||
|
||||
- Не удалять физически посты/направления — только корректно классифицировать дальше.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Маппинг старых dev/media/ai → новые? (пользователь сможет вручную поменять direction
|
||||
при approve; авто-маппинг не делаем пока.)
|
||||
@@ -0,0 +1,12 @@
|
||||
# unify-directions
|
||||
|
||||
- [x] Создан OpenSpec change (proposal/design)
|
||||
- [x] keywords.py: DIRECTIONS_CANON + привести DIRECTIONS к канону (add politics, llm; dev→tech, убрать media/ai)
|
||||
- [x] keywords.py: +golang (частый вариант имени Go) в linux и tech (по просьбе пользователя)
|
||||
- [x] classify.py:87: промпт → DIRECTIONS_CANON
|
||||
- [x] classify.py: LLM-fallback при dict-miss (словарь не дал → LLM, проверка канона) — убирает серые посты
|
||||
- [x] web/app.py:130: directions → DIRECTIONS_CANON
|
||||
- [ ] Переклассификация 466 своих без direction (limit 1000)
|
||||
- [ ] Проверка БД: нет новых направлений вне канона
|
||||
- [ ] `openspec validate unify-directions` — чисто
|
||||
- [ ] Бэкап после правки
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-11
|
||||
@@ -0,0 +1,42 @@
|
||||
## Дизайн
|
||||
|
||||
### 1. Фильтр `dt` в web/app.py
|
||||
|
||||
Рядом с `tpl.filters["from_json"]` (строка 29):
|
||||
|
||||
```python
|
||||
from datetime import datetime
|
||||
|
||||
def dt_filter(value) -> str:
|
||||
if not value:
|
||||
return ""
|
||||
try:
|
||||
if isinstance(value, str):
|
||||
value = datetime.fromisoformat(value.replace("Z", "+00:00"))
|
||||
return value.strftime("%H:%M %d.%m.%Y")
|
||||
except (ValueError, TypeError):
|
||||
return str(value)[:16] if value else ""
|
||||
|
||||
tpl.filters["dt"] = dt_filter
|
||||
```
|
||||
|
||||
Примечание: `fromisoformat` в Python 3.11+ понимает `2026-08-15T15:53` без секунд и с
|
||||
`T`-разделителем. Если строка `2026-08-15T15:53:00` — тоже ок.
|
||||
|
||||
### 2. Шаблоны
|
||||
|
||||
| Файл | Строка сейчас | Станет |
|
||||
|---|---|---|
|
||||
| `candidates.html` | `{{ (p.published_at or '')[:16] }}` | `{{ p.published_at \| dt }}` |
|
||||
| `published.html:10` | `{{ (p.published_at or '')[:16] }}` | `{{ p.published_at \| dt }}` |
|
||||
| `metrics.html:23` | `{{ (r.started_at or '')[:16] }}` | `{{ r.started_at \| dt }}` |
|
||||
|
||||
В `candidates.html` уточнить: сейчас строка `{{ (p.published_at or '')[:16] }}` с префиксом
|
||||
`{{ source_name }} · ` — оставить `{{ p.source_name }} · {{ p.published_at | dt }}`.
|
||||
|
||||
### 3. Проверка
|
||||
|
||||
- Строка `2026-08-15T15:53` → вывод `15:53 15.08.2026`.
|
||||
- `None`/пусто → пустая строка (без "None").
|
||||
- В metrics таблице время запуска в том же формате.
|
||||
- `pytest`/curl: страницы рендерятся без 500.
|
||||
@@ -0,0 +1,26 @@
|
||||
## Why
|
||||
|
||||
Даты в веб-UI отображаются как ISO-строка из SQLite: `2026-08-15T15:53` (срез `[:16]`
|
||||
в шаблонах `candidates.html`, `published.html`, `metrics.html`). Пользователь хочет
|
||||
человекочитаемый формат: `20:00 15.08.2026` (время ЧЧ:ММ, дата ДД.ММ.ГГГГ).
|
||||
|
||||
Места:
|
||||
- `web/templates/candidates.html:…` — `{{ (p.published_at or '')[:16] }}`
|
||||
- `web/templates/published.html:10` — `{{ (p.published_at or '')[:16] }}`
|
||||
- `web/templates/metrics.html:23` — `{{ (r.started_at or '')[:16] }}`
|
||||
|
||||
## What Changes
|
||||
|
||||
- Добавить Jinja2-фильтр `dt` (datetime): парсит ISO-строку `2026-08-15T15:53[:00]`,
|
||||
выводит `20:00 15.08.2026`.
|
||||
- Во всех трёх шаблонах заменить `{{ (x or '')[:16] }}` → `{{ x | dt }}`.
|
||||
- Использовать `datetime.fromisoformat` + `strftime("%H:%M %d.%m.%Y")`.
|
||||
- Если строка не парсится (None/мусор) — выводить пустую строку/прочерк (не падать).
|
||||
|
||||
## Impact
|
||||
|
||||
- Файлы: `web/app.py` (фильтр `dt`), шаблоны `candidates.html`, `published.html`,
|
||||
`metrics.html` (замена вызовов).
|
||||
- Новых зависимостей нет (stdlib `datetime`).
|
||||
- Никакого JS: форматирование на сервере.
|
||||
- Rollback: вернуть `[:16]` в трёх шаблонах, убрать фильтр.
|
||||
@@ -0,0 +1,17 @@
|
||||
## 1. Фильтр
|
||||
|
||||
- [x] 1.1 Добавить `dt_filter` в `web/app.py` (datetime.fromisoformat → `%H:%M %d.%m.%Y`, безопасно к None/мусору)
|
||||
- [x] 1.2 Зарегистрировать как `tpl.filters["dt"]`
|
||||
|
||||
## 2. Применение в шаблонах
|
||||
|
||||
- [x] 2.1 `candidates.html`: `{{ (p.published_at or '')[:16] }}` → `{{ p.published_at | dt }}`
|
||||
- [x] 2.2 `published.html:10`: то же для `published_at`
|
||||
- [x] 2.3 `metrics.html:23`: `{{ (r.started_at or '')[:16] }}` → `{{ r.started_at | dt }}`
|
||||
- [x] 2.4 Проверка: `grep -rn "\[:16\]" web/templates/` — пусто
|
||||
|
||||
## 3. Проверка
|
||||
|
||||
- [x] 3.1 Дата в UI: `15:53 15.08.2026` (а не `2026-08-15T15:53`)
|
||||
- [x] 3.2 None → пустая строка, страницы без ошибок
|
||||
- [x] 3.3 Регресс: candidates/published/metrics рендерятся с новым форматом
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-11
|
||||
@@ -0,0 +1,45 @@
|
||||
## Дизайн
|
||||
|
||||
### 1. Текущее поведение (по коду)
|
||||
|
||||
`candidates.html` (примерные строки 30-48):
|
||||
|
||||
```html
|
||||
<form method="get" action="/candidates">
|
||||
<select name="direction" onchange="this.form.submit()">...</select>
|
||||
<select name="status" onchange="this.form.submit()">...</select>
|
||||
...
|
||||
</form>
|
||||
```
|
||||
|
||||
`app.py /candidates` уже фильтрует по GET-params. Проблема не в логике, а в том, что
|
||||
страница тянет unpkg.com/jsdelivr.net.
|
||||
|
||||
### 2. Что делаем
|
||||
|
||||
- `deexternalize-web-assets` убирает внешние CDN и htmx. Здесь:
|
||||
- Проверить `grep -rn "hx-\|unpkg\|cdn\." web/templates/` — после change 1 пусто.
|
||||
- Убедиться, что `<select onchange="this.form.submit()">` без `hx-*` — трогать не нужно.
|
||||
- Добавить кнопку «Применить» (маленькая, `btn-sm`) — явная альтернатива onchange.
|
||||
|
||||
Форма станет:
|
||||
|
||||
```html
|
||||
<form method="get" action="/candidates" class="row gy-2 gx-3">
|
||||
<!-- direction/status/own selects с onchange="this.form.submit()" -->
|
||||
<button class="btn btn-sm btn-outline-secondary" type="submit">Применить</button>
|
||||
</form>
|
||||
```
|
||||
|
||||
### 3. Сервер
|
||||
|
||||
Никаких изменений в `app.py` не требуется: парсинг `direction`, `status`, `own` уже есть.
|
||||
Единственное — если `own` фильтр пустой, `WHERE` без условий; при `own=""` пост остаётся
|
||||
(что и нужно).
|
||||
|
||||
### 4. Проверка
|
||||
|
||||
- Открыть https://vesti.nixg.ru/candidates, отключить в браузере интернет (или сеть) →
|
||||
фильтры работают, страница не висит.
|
||||
- network-панель: 0 запросов на сторонние домены; filter submit → только на свой хост.
|
||||
- Фильтр «direction=linux&status=new» возвращает корректный список (серверный ответ).
|
||||
@@ -0,0 +1,35 @@
|
||||
## Why
|
||||
|
||||
Пользователь: «unpkg.com почему я ожидаю от него ответа, когда фильтрую список?»
|
||||
|
||||
Фильтры в `candidates.html` — это HTML-форма с `<select onchange="this.form.submit()">`.
|
||||
Сам submit идёт на сервер (/candidates?direction=..&status=..), **но** страница
|
||||
одновременно подгружает `unpkg.com` (HTMX) и jsdelivr (Bootstrap). Когда CDN недоступен,
|
||||
браузер блокирует отрисовку/работу, и пользователь «ждёт ответа от unpkg.com» при каждом
|
||||
фильтре. Плюс сам механизм фильтрации — полная перезагрузка страницы.
|
||||
|
||||
Цель: убрать любую зависимость фильтрации от внешних доменов и сделать интерфейс
|
||||
мгновенно отзывчивым даже офлайн.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Убрать подключение HTMX/unpkg (это уже change `deexternalize-web-assets`; здесь —
|
||||
гарантия, что фильтры не требуют JS вообще).
|
||||
- Фильтры в `candidates.html`: остаются GET-формой (сейчас уже GET) с явной кнопкой
|
||||
«Применить» и/или `onchange="this.form.submit()"` — это чистый HTML, без JS-библиотек.
|
||||
Убедиться, что ни один элемент фильтра не обёрнут в hx-* и не вызывает внешние скрипты.
|
||||
- Сервер: `web/app.py` функция `candidates` уже принимает direction/status/own как query
|
||||
params — фильтрация на сервере, без JS. Ничего менять не надо, кроме проверки.
|
||||
- Гарантия: после deexternalize-web-assets в шаблонах нет `<script src="http...">`
|
||||
вовсе; фильтрация — нативная GET-форма + server-side рендер.
|
||||
- Опционально (бонус): добавить `autocomplete="off"` и явную кнопку, чтобы Enter/клик
|
||||
сразу инициировал submit без циклов.
|
||||
|
||||
## Impact
|
||||
|
||||
- Файлы: `web/templates/candidates.html` (убрать любые hx-* на фильтрах, если есть;
|
||||
явная кнопка), проверка `base.html` (нет внешних скриптов).
|
||||
- Нет новых зависимостей, нет JS.
|
||||
- UX: фильтр работает без интернета; перезагрузка страницы при submit остаётся
|
||||
(это уже не «зависание» — страница отвечает мгновенно с сервера).
|
||||
- Rollback: ничего, кроме HTML-атрибутов.
|
||||
@@ -0,0 +1,17 @@
|
||||
## 1. Фильтры без JS/CDN
|
||||
|
||||
- [x] 1.1 Убедиться, что после deexternalize-web-assets в `web/templates/` нет `hx-*` и внешних `<script src>`
|
||||
- [x] 1.2 В `candidates.html` проверить форму фильтров: чистый `<form method="get">` + `onchange="this.form.submit()"`, без hx-атрибутов
|
||||
- [x] 1.3 Добавить кнопку «Применить» (btn-sm) как явный submit
|
||||
- [x] 1.4 Проверка: `grep -rn "unpkg\|cdn\.\|hx-" web/templates/` — пусто
|
||||
|
||||
## 2. Серверная проверка
|
||||
|
||||
- [x] 2.1 `curl "http://127.0.0.1:8400/candidates?direction=linux&status=new"` → 200, корректные посты
|
||||
- [x] 2.2 Никаких обращений к внешним доменам при фильтрации (logs сервера/network)
|
||||
|
||||
## 3. UX-проверка
|
||||
|
||||
- [x] 3.1 Фильтр работает с выключенным интернетом (offline) — мгновенный серверный ответ
|
||||
- [x] 3.2 После фильтра список отображается, страница не «висит» в ожидании CDN
|
||||
- [x] 3.3 Полный регресс: login → candidates → approve/reject → published
|
||||
@@ -0,0 +1,3 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-13
|
||||
skip_specs: true
|
||||
@@ -0,0 +1,60 @@
|
||||
## Design
|
||||
|
||||
### Роут в web/app.py
|
||||
|
||||
После `/bundle/...` (в конце файла) добавить:
|
||||
|
||||
```python
|
||||
from fastapi.responses import FileResponse
|
||||
|
||||
MEDIA_DIRS = [
|
||||
BASE_DIR / "media", # свежие: media/<file>
|
||||
BASE_DIR / "media" / "media" # старые: media/media/<file>
|
||||
]
|
||||
|
||||
@app.get("/media/{filename}")
|
||||
def media(request: Request, filename: str):
|
||||
"""Отдаёт медиа-файл поста (из media/ или media/media/). Авторизация."""
|
||||
_require_auth(request)
|
||||
name = os.path.basename(filename) # защита от path traversal
|
||||
if not name:
|
||||
return HTMLResponse("bad filename", status_code=400)
|
||||
for d in MEDIA_DIRS:
|
||||
f = (d / name).resolve()
|
||||
if f.exists() and f.is_file():
|
||||
# отдаём с корректным MIME по расширению
|
||||
return FileResponse(f)
|
||||
return HTMLResponse("not found", status_code=404)
|
||||
```
|
||||
|
||||
Примечание: `FileResponse` уже есть в fastapi.responses (импортировать).
|
||||
`MEDIA_DIRS` можно вынести в константы рядом с `STATIC_DIR`.
|
||||
|
||||
### Шаблоны
|
||||
|
||||
В `candidates.html` (и `published.html`), заменить блок бейджа:
|
||||
|
||||
```html
|
||||
{% if p.media_path %}
|
||||
<span class="badge bg-light text-dark ms-2">🖼 медиа</span>
|
||||
{# маленькое превью: изображение или видео #}
|
||||
{% set media_src = '/media/' ~ p.media_path.split('/')[-1] %}
|
||||
{% if p.media_path.lower().endswith(('.jpg','.jpeg','.png','.gif','.webp')) %}
|
||||
<img src="{{ media_src }}" class="img-fluid rounded mt-2" style="max-height:180px" alt="медиа">
|
||||
{% elif p.media_path.lower().endswith(('.mp4','.webm','.mov')) %}
|
||||
<video src="{{ media_src }}" controls class="mt-2" style="max-height:180px"></video>
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
```
|
||||
|
||||
В `candidates.html` строка 49: заменить бейдж на блок с превью.
|
||||
В `published.html` — аналогично (там сейчас бейдж медиа? проверить).
|
||||
|
||||
### Верификация
|
||||
|
||||
- `openspec validate web-media-preview` — чисто.
|
||||
- Перезапуск веба: `sudo systemctl restart vesti-web`.
|
||||
- Открыть /candidates — у поста с media_path видно изображение/видео.
|
||||
- `/media/LinuxMastery_1079.jpg` — 200 (файл есть).
|
||||
- Старый пост с media/media/<file> — тоже 200.
|
||||
- Несуществующий файл — 404.
|
||||
@@ -0,0 +1,28 @@
|
||||
## Why
|
||||
|
||||
Пользователь не видит, что за картинка приложена к новости в карточке кандидата:
|
||||
в шаблоне `candidates.html` для постов с `media_path` показывается только бейдж
|
||||
«🖼 медиа», а само изображение не отображается. В `web/app.py` нет роута, который
|
||||
отдаёт медиа-файл (есть только /static для bootstrap), поэтому `<img>` некуда указывать.
|
||||
Аналогично в `published.html` медиа не показывается.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Добавить в `web/app.py` роут `GET /media/{filename}` (с авторизацией, как у других
|
||||
роутов), который отдаёт файл из `/opt/vesti/media/` или `/opt/vesti/media/media/`
|
||||
(исторический баг путей: у старых постов media_path = `media/media/<file>`).
|
||||
Безопасно: только basename (защита от path traversal), отдаём FileResponse.
|
||||
- В `candidates.html` и `published.html` для постов с `media_path` выводить
|
||||
`<img src="/media/{{ basename(media_path) }}" class="img-fluid ...">`
|
||||
(направление на роут; если файла нет — не показывать/плейсхолдер).
|
||||
- Медиа в карточке: фото/видео. Для изображений — `<img>`, для видео — `<video controls>`.
|
||||
|
||||
## Why Not
|
||||
|
||||
- Отдавать медиа через /static нельзя: файлы вне static/ и большие; роут нужен именно
|
||||
для media/.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Путь `media_path` в БД: `media/<file>` или `media/media/<file>` — резолвить через
|
||||
basename (имя файла уникально в каталоге).
|
||||
@@ -0,0 +1,10 @@
|
||||
# web-media-preview
|
||||
|
||||
- [x] Создан OpenSpec change (proposal/design)
|
||||
- [x] web/app.py: роут `/media/{filename}` (FileResponse, защита path traversal) + MEDIA_DIRS
|
||||
- [x] candidates.html: превью медиа (img/video) вместо бейджа
|
||||
- [x] published.html: превью медиа
|
||||
- [x] `openspec validate web-media-preview` — чисто (skip_specs: true, валиден)
|
||||
- [x] Перезапуск веба; /media/LinuxMastery_1079.jpg → 200 image/jpeg; mp4 (старый) → 200 video/mp4; missing → 404
|
||||
- [x] Бэкап после правки (`sudo /opt/vesti/backup.sh`)
|
||||
- [x] Клик по картинке → полноразмер в новой вкладке (`<a target="_blank">` вокруг `<img>`, без JS)
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-11
|
||||
@@ -0,0 +1,61 @@
|
||||
## Дизайн
|
||||
|
||||
### 1. Зависимость
|
||||
|
||||
```bash
|
||||
/opt/vesti/.venv/bin/pip install "Markdown>=3.6"
|
||||
echo "Markdown>=3.6" >> /opt/vesti/requirements.txt
|
||||
```
|
||||
|
||||
### 2. Фильтр в web/app.py
|
||||
|
||||
Рядом с существующим `tpl.filters["from_json"]` (строка 29) добавить:
|
||||
|
||||
```python
|
||||
import markdown as md_lib
|
||||
from markupsafe import Markup
|
||||
|
||||
def md_filter(text: str) -> Markup:
|
||||
if not text:
|
||||
return Markup("")
|
||||
# 1) экранируем HTML (защита от XSS), 2) рендерим markdown, 3) переносы строк
|
||||
import markupsafe
|
||||
safe = markupsafe.escape(text)
|
||||
html = md_lib.markdown(safe, extensions=["nl2br", "sane_lists"])
|
||||
return Markup(html)
|
||||
|
||||
tpl.filters["markdown"] = md_filter
|
||||
```
|
||||
|
||||
(В Jinja2 по умолчанию `Markup` не экранируется повторно; `markupsafe` уже идёт с Jinja2.)
|
||||
|
||||
### 3. Шаблон candidates.html
|
||||
|
||||
Заменить строку 41:
|
||||
|
||||
```jinja
|
||||
<div class="post-text mt-2">{{ (p.text or '')[:500] }}</div>
|
||||
```
|
||||
|
||||
на:
|
||||
|
||||
```jinja
|
||||
<div class="post-text mt-2">{{ (p.text or '')[:2000] | markdown }}</div>
|
||||
```
|
||||
|
||||
И в `base.html` для `.post-text` оставить `white-space: pre-wrap` (после nl2br переносы
|
||||
строк уже есть, но pre-wrap не помешает) — или сменить на `line-height: 1.5`.
|
||||
|
||||
### 4. Безопасность
|
||||
|
||||
- `markupsafe.escape` до markdown-парсера — ссылки `[x](javascript:...)` должны быть
|
||||
заблокированы. Python-Markdown сам экранирует опасные протоколы в ссылках, но
|
||||
предварительное экранирование — обязательный слой.
|
||||
- Не использовать `|safe` без `Markup`.
|
||||
|
||||
### 5. Проверка
|
||||
|
||||
- Пост с текстом `**жирный** [ссылка](https://x) - пункт` рендерится жирным/ссылкой/списком.
|
||||
- В HTML нет сырых `**`, `[`, `](` символов разметки (кроме намеренных).
|
||||
- Ввод `<script>alert(1)</script>` отображается как текст, не исполняется.
|
||||
- `published.html` — если там есть `p.text`/`p.summary`, применить тот же фильтр (grep).
|
||||
@@ -0,0 +1,34 @@
|
||||
## Why
|
||||
|
||||
В списке кандидатов (`web/templates/candidates.html:41`) текст поста выводится как есть:
|
||||
|
||||
```html
|
||||
<div class="post-text mt-2">{{ (p.text or '')[:500] }}</div>
|
||||
```
|
||||
|
||||
Jinja2 экранирует HTML-сущности (`{{ }}` — автоэскейп), но **не парсит markdown**: жирный
|
||||
текст, ссылки, списки, заголовки в исходных постах (телеграм-посты с markdown-разметкой)
|
||||
отображаются сырыми символами `**`, `[text](url)`, `- item`. Пользователь видит «сырой
|
||||
markdown, а не красивый».
|
||||
|
||||
## What Changes
|
||||
|
||||
- Рендерить текст поста из markdown в HTML перед выводом в списке кандидатов.
|
||||
- Добавить Jinja2-фильтр `markdown` (или `md`): `{{ (p.text or '')[:2000] | markdown }}`.
|
||||
- Использовать локальную Python-библиотеку (не JS/CDN!): `markdown` (Python-Markdown) —
|
||||
уже покрывает жирный/курсив/ссылки/списки/заголовки. Безопасный вывод: экранирование
|
||||
HTML-тегов в исходном тексте (вход — непроверенный текст из TG), `nl2br`/`pre`-обёртка
|
||||
для переносов строк.
|
||||
- Только серверный рендер, без внешних JS-библиотек (в духе deexternalize-web-assets).
|
||||
- Превратить `.post-text` в блок с классом `post-text` и `white-space` нормальным
|
||||
(не `pre-wrap` над сырым md) или оставить, но уже с HTML.
|
||||
|
||||
## Impact
|
||||
|
||||
- Файлы: `web/app.py` (зарегистрировать фильтр), `web/templates/candidates.html`
|
||||
(заменить вывод), возможно `published.html` (если там тоже текст).
|
||||
- Зависимость: добавить `Markdown>=3.6` в `requirements.txt` (pip, локально).
|
||||
- Безопасность: важно экранировать HTML до передачи в markdown-парсер (иначе XSS из
|
||||
telegram-постов).
|
||||
- Минимальная правка; поведение страниц не меняется, кроме вида текста.
|
||||
- Rollback: вернуть `{{ (p.text or '')[:500] }}`, убрать фильтр.
|
||||
@@ -0,0 +1,17 @@
|
||||
## 1. Зависимость и фильтр
|
||||
|
||||
- [x] 1.1 `pip install Markdown` в .venv, добавить в requirements.txt
|
||||
- [x] 1.2 Добавить Jinja2-фильтр `markdown` в `web/app.py` (экранирование HTML + nl2br + sane_lists)
|
||||
- [x] 1.3 Проверка: `python -c "from web.app import tpl; print(tpl.filters['markdown']('**b**'))"` — фильтр есть
|
||||
|
||||
## 2. Шаблоны
|
||||
|
||||
- [x] 2.1 `candidates.html`: заменить `{{ (p.text or '')[:500] }}` на `{{ (p.text or '')[:2000] | markdown }}`
|
||||
- [x] 2.2 Проверить `published.html`/`metrics.html` — применить фильтр к тексту/анонсам при наличии
|
||||
- [x] 2.3 Проверка: пост с `**жирный**` и ссылкой отображается разметкой, а не сырым md
|
||||
|
||||
## 3. Безопасность и регресс
|
||||
|
||||
- [x] 3.1 Тест XSS: `<script>` в тексте поста не исполняется (отображается как текст)
|
||||
- [x] 3.2 Тест регресса: список кандидатов и published рендерятся без ошибок
|
||||
- [x] 3.3 `grep -rn "p.text\|\.text" web/templates/` — все места обработаны
|
||||
@@ -0,0 +1,26 @@
|
||||
schema: spec-driven
|
||||
|
||||
context: |
|
||||
Проект VESTI — новостной агрегатор с веб-интерфейсом (эволюция /opt/news).
|
||||
Домен: медиа-конвейер: краулинг (RSS, email, сайты, Telegram, WeChat, X) → дедуп + слияние источников в одну статью → факт-чек → категоризация (Технологии, Политика, Игры, Электроника, БЯМ, Линукс) → банк статей (markdown-бандлы с frontmatter) → дайджесты по направлениям (для еженедельных видео) + ленты ботов (Telegram, VK, fediverse).
|
||||
Окружение: Hermes-агент на bigbox (10.8.0.2, home server), сервисы в /opt/<service>/; Docker (docker compose), systemd; рестарт сервисов — только извне (SSH sudo systemctl restart).
|
||||
Ключевые сервисы: telegram-tunnel (SOCKS5 127.0.0.1:1080 → VPS01), ollama (:11434), qdrant (:6333), redis (:6379), gitea (:3000, зеркало), gitverse.ru (источник истины), gotosocial (fediverse, :8082), garage (S3).
|
||||
LLM: локально qwen3:8b-nothink (классификация, категоризация, быстрые задачи); qwen3-vl:8b (vision); облако (deepseek, текущий провайдер) — факт-чек, слияние, дайджесты, отдельный API/ключ для учёта затрат (решение E2).
|
||||
Telegram: доступ только через SOCKS5 127.0.0.1:1080; api_id=24276216, api_hash из /opt/icq/docker-compose.yml; Telethon-сессия /opt/news/telegram/ переиспользуется; боты-публикаторы — через Bot API (свой токен).
|
||||
Направления: Технологии, Политика, Игры, Электроника, БЯМ, Линукс. Языки ботов: ru, en, zh, ko. Именование ботов: @dedinit_vesti_<направление>_<язык>_bot.
|
||||
Соглашения: отдельный каталог /opt/vesti/ на сервис; секреты в .env; порты фиксируются в README.md; апдейты через git (источник истины gitverse.ru); статьи — markdown-бандлы: bundles/<направление>/<YYYY-MM>/<slug>.md + media/ рядом; веб — локально (пока без внешнего домена).
|
||||
Прототип (итерация 1): TG-краулер (Telethon) + классификатор (локальный qwen) + TG-бот-публикатор (режим «черновик на подтверждение») + минимальный веб (FastAPI + Bootstrap 5.3 + Jinja2 + HTMX) с авторизацией.
|
||||
Метрики: для внешних TG-постов — views/reactions; для своих постов — views через Bot API; сайты/RSS — только свои переходы (UTM).
|
||||
|
||||
rules:
|
||||
proposal:
|
||||
- Указывать затронутые сервисы и порты
|
||||
- Включать план отката (rollback)
|
||||
specs:
|
||||
- Требования в формате MUST/SHOULD/MAY
|
||||
- Сценарии проверки: GIVEN/WHEN/THEN с конкретными командами верификации (systemctl status, curl, docker ps, python -c ...)
|
||||
design:
|
||||
- Указывать конкретные файлы конфигов и юнитов
|
||||
- Включать команды применения и проверки
|
||||
tasks:
|
||||
- Каждая задача — проверяемый шаг с командой верификации
|
||||
@@ -0,0 +1,104 @@
|
||||
# Публикация карточек в Telegram через Bot API.
|
||||
# Бот: @dedinit_vesti_<direction>_<lang>_bot (шаблон из конфига .env).
|
||||
# Режим подтверждения: веб вызывает publish() только после явного клика.
|
||||
# Метрики: getChatMemberCount / getMessage (views) для опубликованных.
|
||||
|
||||
import os
|
||||
from pathlib import Path
|
||||
|
||||
import httpx
|
||||
|
||||
BASE_DIR = Path(__file__).resolve().parent.parent
|
||||
BOT_TOKEN = os.getenv("VESTI_BOT_TOKEN", "")
|
||||
API = "https://api.telegram.org"
|
||||
TIMEOUT = 20.0
|
||||
|
||||
|
||||
def _bot_url(method: str) -> str:
|
||||
if not BOT_TOKEN:
|
||||
raise RuntimeError("VESTI_BOT_TOKEN не задан (dry-run недоступен для сети)")
|
||||
return f"{API}/bot{BOT_TOKEN}/{method}"
|
||||
|
||||
|
||||
def channel_username(direction: str, lang: str) -> str:
|
||||
"""@dedinit_vesti_<direction>_<lang>_bot — по спеке; канал — тот же без _bot."""
|
||||
return f"@dedinit_vesti_{direction}_{lang}_bot"
|
||||
|
||||
|
||||
def _upload_photo(chat_id: str, photo_path: str, caption: str = "") -> int:
|
||||
"""Отправляет фото (медиа первым). Возвращает message_id."""
|
||||
with open(photo_path, "rb") as f:
|
||||
r = httpx.post(
|
||||
_bot_url("sendPhoto"),
|
||||
data={"chat_id": chat_id, "caption": caption[:1024]},
|
||||
files={"photo": f},
|
||||
timeout=TIMEOUT,
|
||||
)
|
||||
r.raise_for_status()
|
||||
return r.json()["result"]["message_id"]
|
||||
|
||||
|
||||
def _send_message(chat_id: str, text: str, parse_mode: str = "HTML") -> int:
|
||||
r = httpx.post(
|
||||
_bot_url("sendMessage"),
|
||||
json={"chat_id": chat_id, "text": text, "parse_mode": parse_mode},
|
||||
timeout=TIMEOUT,
|
||||
)
|
||||
r.raise_for_status()
|
||||
return r.json()["result"]["message_id"]
|
||||
|
||||
|
||||
def publish_card(card: dict, direction: str = "linux", lang: str = "ru", chat_id: str | None = None) -> dict:
|
||||
"""Публикует карточку {media, text} в канал. Возвращает {message_id, media_message_id}.
|
||||
|
||||
dry-run: если VESTI_BOT_TOKEN не задан — возвращает плейсхолдер (не отправляет).
|
||||
"""
|
||||
if not BOT_TOKEN:
|
||||
return {"message_id": 0, "media_message_id": 0, "dry_run": True}
|
||||
|
||||
chat = chat_id or channel_username(direction, lang)
|
||||
media_msg = None
|
||||
if card.get("media"):
|
||||
media_msg = _upload_photo(chat, card["media"], caption=card["text"][:1024])
|
||||
msg = _send_message(chat, card["text"])
|
||||
return {"message_id": msg, "media_message_id": media_msg, "dry_run": False}
|
||||
|
||||
|
||||
def publish_multi(card: dict, directions: list[str], lang: str = "ru") -> dict:
|
||||
"""Публикует карточку во ВСЕ каналы направлений. Возвращает {direction: {message_id, media_message_id, dry_run}}.
|
||||
|
||||
directions: список направлений (напр. ['linux', 'ai']).
|
||||
При пустом списке — публикация в направление по умолчанию (card['direction']).
|
||||
"""
|
||||
if not directions:
|
||||
directions = [card.get("direction") or "linux"]
|
||||
out = {}
|
||||
for d in directions:
|
||||
out[d] = publish_card(card, direction=d, lang=lang)
|
||||
return out
|
||||
|
||||
|
||||
def get_views(chat_id: str, message_id: int) -> int:
|
||||
"""Возвращает просмотры опубликованного сообщения через Bot API (getMessage → views)."""
|
||||
if not BOT_TOKEN:
|
||||
return 0
|
||||
try:
|
||||
r = httpx.get(_bot_url("getMessage"), params={"chat_id": chat_id, "message_id": message_id}, timeout=TIMEOUT)
|
||||
r.raise_for_status()
|
||||
m = r.json()["result"]
|
||||
return int(m.get("views") or m.get("forwards") or 0)
|
||||
except Exception as e:
|
||||
print(f" ! get_views failed {chat_id}/{message_id}: {e}")
|
||||
return 0
|
||||
|
||||
|
||||
def get_views_multi(directions: list[str], message_ids: dict, lang: str = "ru") -> dict:
|
||||
"""Собирает просмотры по каждому направлению. Возвращает {direction: views}."""
|
||||
out = {}
|
||||
for d in directions:
|
||||
mid = (message_ids.get(d) or {}).get("message_id") or 0
|
||||
if mid:
|
||||
out[d] = get_views(channel_username(d, lang), mid)
|
||||
else:
|
||||
out[d] = 0
|
||||
return out
|
||||
@@ -0,0 +1,81 @@
|
||||
# Форматирование карточки поста для Telegram (MUST: ≤4096 символов).
|
||||
# «Богатый репост»: [комментарий модератора] + полный текст поста + ссылка на оригинал.
|
||||
# Без служебной информации (направление/источник/просмотры) — она в вебе и бандле.
|
||||
# Текст — plain (не HTML): исходный текст поста не перекодируем, ссылки Telegram
|
||||
# распознаёт сам; предпросмотр ссылки отключается на уровне sendMessage.
|
||||
|
||||
import re
|
||||
|
||||
MAX_TEXT = 4096
|
||||
|
||||
# фото/видео, поддерживаемые Bot API sendPhoto/sendVideo
|
||||
MEDIA_EXTS = (".jpg", ".jpeg", ".png", ".gif", ".webp", ".mp4", ".mov", ".avi", ".mkv")
|
||||
|
||||
|
||||
def make_card(post: dict, comment: str | None = None) -> dict:
|
||||
"""Собирает карточку «богатого репоста». Возвращает {"media": path|None, "text": str}.
|
||||
|
||||
post: dict из БД (id, text, url, media_path, is_own, tg_channel, tg_post_id, ...).
|
||||
Формат текста:
|
||||
[комментарий модератора] — если задан, первым блоком
|
||||
[полный текст исходного поста] — без сниппета/суммари
|
||||
[ссылка на оригинал] — последней строкой (атрибуция для своих)
|
||||
|
||||
Текст НЕ содержит служебки (📁 направление/язык, 📰 источник, 👁 просмотры) —
|
||||
это был «агрегаторный» вид карточки.
|
||||
"""
|
||||
comment = (comment or "").strip()
|
||||
body = (post.get("text") or "").strip()
|
||||
|
||||
# ссылка на оригинал / атрибуция своего контента
|
||||
is_own = int(post.get("is_own") or 0) == 1
|
||||
orig = None
|
||||
if post.get("tg_channel") == "dedinit" and post.get("tg_post_id"):
|
||||
orig = f"https://t.me/dedinit/{post['tg_post_id']}"
|
||||
elif post.get("url"):
|
||||
orig = post.get("url")
|
||||
if is_own:
|
||||
tail = "✍️ Дед в АйТи (@dedinit)" + (f" · {orig}" if orig else "")
|
||||
elif orig:
|
||||
tail = f"🔗 Оригинал: {orig}"
|
||||
else:
|
||||
tail = None
|
||||
|
||||
parts = []
|
||||
if comment:
|
||||
parts.append(comment)
|
||||
if body:
|
||||
parts.append(body)
|
||||
if tail:
|
||||
parts.append(tail)
|
||||
if not parts:
|
||||
parts = ["(пост без текста)"]
|
||||
|
||||
text = "\n\n".join(parts)
|
||||
|
||||
if len(text) > MAX_TEXT:
|
||||
# обрезаем полный текст, но сохраняем ссылку/атрибуцию в конце
|
||||
tail_block = ("\n\n" + tail) if tail else ""
|
||||
budget = MAX_TEXT - len(tail_block) - 3
|
||||
body_cut = text[:budget].rstrip() + "…"
|
||||
text = body_cut + tail_block
|
||||
if len(text) > MAX_TEXT:
|
||||
text = text[: MAX_TEXT - 3] + "…"
|
||||
|
||||
# медиа: фото И видео (раньше отбрасывалось всё кроме картинок)
|
||||
media = post.get("media_path") or post.get("media_local") or None
|
||||
if media and not str(media).lower().endswith(MEDIA_EXTS):
|
||||
media = None
|
||||
if media:
|
||||
# нормализация пути: media_path в БД = 'media/<file>', но старые файлы
|
||||
# физически лежат в media/media/<file> (баг краулера до 2026-09-12).
|
||||
# Пробуем оба варианта, отдаём тот, что существует.
|
||||
import os as _os
|
||||
cands = [
|
||||
str(media),
|
||||
str(_os.path.join("media", str(media).replace("media/", "", 1)))
|
||||
if str(media).startswith("media/") else None,
|
||||
]
|
||||
found = next((c for c in cands if c and _os.path.exists(c)), None)
|
||||
media = found or media # если ни один не найден — оставляем как есть (publisher retry)
|
||||
return {"media": media, "text": text}
|
||||
@@ -0,0 +1,14 @@
|
||||
telethon>=1.36
|
||||
httpx>=0.27
|
||||
feedparser>=6.0
|
||||
fastapi>=0.115
|
||||
uvicorn[standard]>=0.30
|
||||
jinja2>=3.1
|
||||
python-dotenv>=1.0
|
||||
python-dateutil>=2.9
|
||||
python-telegram-bot>=21.6
|
||||
aiofiles>=23.2
|
||||
aiosqlite>=0.20
|
||||
PySocks>=1.7
|
||||
PyYAML>=6.0
|
||||
Markdown>=3.6
|
||||
Executable
+20
@@ -0,0 +1,20 @@
|
||||
#!/usr/bin/env bash
|
||||
# VESTI — cron-запуск краулера по всем включённым telegram-источникам.
|
||||
# Тихий: при успехе stdout пуст (ничего не шлёт); при ошибке — 1 строка на stderr.
|
||||
# Логи пишутся в /opt/vesti/logs/crawler-cron.log.
|
||||
set -u
|
||||
cd /opt/vesti || exit 1
|
||||
mkdir -p logs
|
||||
LOG=logs/crawler-cron.log
|
||||
|
||||
out=$(.venv/bin/python -m crawler.telegram_crawler --all 2>&1)
|
||||
rc=$?
|
||||
if [ $rc -ne 0 ]; then
|
||||
echo "VESTI crawler FAILED (rc=$rc): ${out##*$'\n'}" >&2
|
||||
echo "$(date '+%Y-%m-%d %H:%M:%S') rc=$rc: $out" >> "$LOG"
|
||||
exit 1
|
||||
fi
|
||||
# подсчёт новых постов из вывода
|
||||
new=$(echo "$out" | grep -c 'new=' || true)
|
||||
echo "$(date '+%Y-%m-%d %H:%M:%S') ok: new_posts=$new" >> "$LOG"
|
||||
exit 0
|
||||
Executable
+140
@@ -0,0 +1,140 @@
|
||||
#!/bin/bash
|
||||
# VESTI — textfile-коллектор для node-exporter (bigbox).
|
||||
# Пишет /var/lib/node_exporter/textfile_collector/vesti.prom (Prometheus-формат).
|
||||
# Метрики:
|
||||
# vesti_web_up 1 = веб :8400 отвечает 200
|
||||
# vesti_publisher_health 1 = publisher :8410 /healthz ок, 0 = нет
|
||||
# vesti_publisher_bot 1 = publisher отвечает, объект bot задан
|
||||
# vesti_publisher_proxy 1 = publisher отвечает, proxy задан
|
||||
# vesti_publisher_channels N = число каналов из healthz
|
||||
# vesti_telegram_tunnel 1 = SOCKS5-туннель :1080 слушает
|
||||
# vesti_publisher_docker 1 = контейнер vesti-publisher running
|
||||
# vesti_web_systemd 1 = юнит vesti-web.active
|
||||
# vesti_db_ok 1 = БД vesti.db открывается
|
||||
# vesti_db_posts_total N = постов в БД
|
||||
# vesti_db_new_total N = постов со статусом 'new'
|
||||
# vesti_db_published_total N = постов 'published'
|
||||
# vesti_db_last_run_ts unix-ts последнего run (0, если нет)
|
||||
#
|
||||
# Помечено label'ом component="vesti". Скрипт тихий: всегда успех, файл пишется
|
||||
# атомарно (tmp+mv). Периодичность — systemd timer (vesti-metrics.timer) каждые 30с.
|
||||
set -u
|
||||
|
||||
OUT=/var/lib/node_exporter/textfile_collector/vesti.prom
|
||||
TMP="${OUT}.tmp"
|
||||
|
||||
# --- безопасные подстановки: число или 0, строка без кавычек/переводов ---
|
||||
clean() { tr -cd '0-9' <<<"$1"; }
|
||||
cleanstr() { tr -d '\n\r"' <<<"$1"; }
|
||||
|
||||
web_up=0; pub_health=0; pub_bot=0; pub_proxy=0; pub_channels=0
|
||||
tunnel=0; pub_docker=0; web_sys=0; db_ok=0
|
||||
posts=0; new=0; published=0; last_run=0
|
||||
|
||||
# 1) веб :8400 — достаточно login-страницы (200)
|
||||
if curl -sf --max-time 5 -o /dev/null http://127.0.0.1:8400/login; then
|
||||
web_up=1
|
||||
fi
|
||||
|
||||
# 2) publisher :8410 /healthz — JSON
|
||||
HEALTH=$(curl -sf --max-time 5 http://127.0.0.1:8410/healthz 2>/dev/null) && pub_health=1
|
||||
if [ -n "$HEALTH" ]; then
|
||||
# {"status":"ok","bot":"...","token_set":true,"proxy":"...","channels":[...]}
|
||||
case "$HEALTH" in
|
||||
*'"bot"'*'"'*) pub_bot=1 ;;
|
||||
esac
|
||||
case "$HEALTH" in
|
||||
*'"proxy"'*'"'*) pub_proxy=1 ;;
|
||||
esac
|
||||
# число каналов
|
||||
CH=$(grep -o '\[[^]]*\]' <<<"$HEALTH" | head -1 | tr -cd ',"@0-9a-zA-Z_.-' | grep -o '@' | wc -l)
|
||||
# если нет массива — нет каналов
|
||||
pub_channels=$(clean "$CH")
|
||||
fi
|
||||
|
||||
# 3) SOCKS5-туннель :1080 (tcp connect)
|
||||
if timeout 5 bash -c 'exec 3<>/dev/tcp/127.0.0.1/1080' 2>/dev/null; then
|
||||
tunnel=1
|
||||
fi
|
||||
|
||||
# 4) контейнер vesti-publisher
|
||||
if docker ps --filter name=^vesti-publisher$ --filter status=running --format '{{.Names}}' 2>/dev/null | grep -q vesti-publisher; then
|
||||
pub_docker=1
|
||||
fi
|
||||
|
||||
# 5) systemd vesti-web
|
||||
if systemctl is-active --quiet vesti-web; then
|
||||
web_sys=1
|
||||
fi
|
||||
|
||||
# 6) БД vesti.db
|
||||
if DB=$(/opt/vesti/.venv/bin/python - <<'PY' 2>/dev/null
|
||||
import sqlite3
|
||||
c = sqlite3.connect('/opt/vesti/db/vesti.db', timeout=5)
|
||||
def one(q):
|
||||
try:
|
||||
return c.execute(q).fetchone()[0]
|
||||
except Exception:
|
||||
return None
|
||||
posts = one('SELECT count(*) FROM posts') or 0
|
||||
new = one("SELECT count(*) FROM posts WHERE status='new'") or 0
|
||||
pub = one("SELECT count(*) FROM posts WHERE status='published'") or 0
|
||||
run = one('SELECT max(started_at) FROM runs')
|
||||
import datetime as dt
|
||||
ts = 0
|
||||
if run:
|
||||
try:
|
||||
ts = int(dt.datetime.fromisoformat(run).timestamp())
|
||||
except Exception:
|
||||
ts = 0
|
||||
print(posts, new, pub, ts)
|
||||
PY
|
||||
); then
|
||||
db_ok=1
|
||||
set -- $DB
|
||||
posts=$(clean "${1:-0}"); new=$(clean "${2:-0}"); published=$(clean "${3:-0}"); last_run=$(clean "${4:-0}")
|
||||
fi
|
||||
|
||||
# --- запись (атомарно) ---
|
||||
{
|
||||
echo '# HELP vesti_web_up VESTI web :8400 responds'
|
||||
echo '# TYPE vesti_web_up gauge'
|
||||
echo "vesti_web_up{component=\"vesti\"} $web_up"
|
||||
echo '# HELP vesti_publisher_health VESTI publisher :8410 /healthz ok'
|
||||
echo '# TYPE vesti_publisher_health gauge'
|
||||
echo "vesti_publisher_health{component=\"vesti\"} $pub_health"
|
||||
echo '# HELP vesti_publisher_bot publisher reports bot identity'
|
||||
echo '# TYPE vesti_publisher_bot gauge'
|
||||
echo "vesti_publisher_bot{component=\"vesti\"} $pub_bot"
|
||||
echo '# HELP vesti_publisher_proxy publisher reports SOCKS5 proxy'
|
||||
echo '# TYPE vesti_publisher_proxy gauge'
|
||||
echo "vesti_publisher_proxy{component=\"vesti\"} $pub_proxy"
|
||||
echo '# HELP vesti_publisher_channels number of channels in publisher healthz'
|
||||
echo '# TYPE vesti_publisher_channels gauge'
|
||||
echo "vesti_publisher_channels{component=\"vesti\"} $pub_channels"
|
||||
echo '# HELP vesti_telegram_tunnel SOCKS5 tunnel :1080 listening'
|
||||
echo '# TYPE vesti_telegram_tunnel gauge'
|
||||
echo "vesti_telegram_tunnel{component=\"vesti\"} $tunnel"
|
||||
echo '# HELP vesti_publisher_docker vesti-publisher container running'
|
||||
echo '# TYPE vesti_publisher_docker gauge'
|
||||
echo "vesti_publisher_docker{component=\"vesti\"} $pub_docker"
|
||||
echo '# HELP vesti_web_systemd vesti-web systemd unit active'
|
||||
echo '# TYPE vesti_web_systemd gauge'
|
||||
echo "vesti_web_systemd{component=\"vesti\"} $web_sys"
|
||||
echo '# HELP vesti_db_ok vesti.db accessible'
|
||||
echo '# TYPE vesti_db_ok gauge'
|
||||
echo "vesti_db_ok{component=\"vesti\"} $db_ok"
|
||||
echo '# HELP vesti_db_posts_total posts in DB'
|
||||
echo '# TYPE vesti_db_posts_total gauge'
|
||||
echo "vesti_db_posts_total{component=\"vesti\"} $posts"
|
||||
echo '# HELP vesti_db_new_total posts with status=new'
|
||||
echo '# TYPE vesti_db_new_total gauge'
|
||||
echo "vesti_db_new_total{component=\"vesti\"} $new"
|
||||
echo '# HELP vesti_db_published_total posts with status=published'
|
||||
echo '# TYPE vesti_db_published_total gauge'
|
||||
echo "vesti_db_published_total{component=\"vesti\"} $published"
|
||||
echo '# HELP vesti_db_last_run_ts unix ts of last crawler run'
|
||||
echo '# TYPE vesti_db_last_run_ts gauge'
|
||||
echo "vesti_db_last_run_ts{component=\"vesti\"} $last_run"
|
||||
} > "$TMP" && chown prometheus:prometheus "$TMP" && chmod 644 "$TMP" && mv -f "$TMP" "$OUT"
|
||||
exit 0
|
||||
Executable
+40
@@ -0,0 +1,40 @@
|
||||
#!/bin/bash
|
||||
# VESTI — тихий watchdog: publisher, веб :8400, туннель :1080, БД, диск.
|
||||
# no_agent cron: непустой stdout доставляется дословно; ПУСТОЙ = тишина.
|
||||
# Шумит ТОЛЬКО при реальной проблеме.
|
||||
WEB_URL=${WEB_URL:-"http://127.0.0.1:8400/login"}
|
||||
|
||||
issues=()
|
||||
|
||||
# 1) publisher-service (Docker) — healthz
|
||||
if ! curl -sf --max-time 5 http://127.0.0.1:8410/healthz >/dev/null 2>&1; then
|
||||
issues+=("publisher-service :8410 НЕ отвечает (healthz)")
|
||||
fi
|
||||
|
||||
# 2) веб :8400
|
||||
if ! curl -sf --max-time 5 -o /dev/null "$WEB_URL" 2>/dev/null; then
|
||||
issues+=("веб :8400 НЕ отвечает ($WEB_URL)")
|
||||
fi
|
||||
|
||||
# 3) туннель SOCKS5 :1080
|
||||
if ! timeout 5 bash -c 'exec 3<>/dev/tcp/127.0.0.1/1080' 2>/dev/null; then
|
||||
issues+=("telegram-tunnel SOCKS5 :1080 не слушает")
|
||||
fi
|
||||
|
||||
# 4) publisher-контейнер Docker жив (основной способ: compose, restart=unless-stopped)
|
||||
if ! docker ps --filter name=^vesti-publisher$ --filter status=running --format '{{.Names}}' | grep -q vesti-publisher; then
|
||||
issues+=("контейнер vesti-publisher (Docker :8410) не запущен")
|
||||
fi
|
||||
|
||||
# 5) БД доступна (не залочена, не битая) — через python (sqlite3 CLI может отсутствовать)
|
||||
if ! /opt/vesti/.venv/bin/python -c 'import sqlite3;c=sqlite3.connect("/opt/vesti/db/vesti.db");c.execute("SELECT 1");c.close()' >/dev/null 2>&1; then
|
||||
issues+=("БД /opt/vesti/db/vesti.db недоступна")
|
||||
fi
|
||||
|
||||
# --- шумим только при проблемах ---
|
||||
if [ ${#issues[@]} -gt 0 ]; then
|
||||
echo "⚠️ VESTI: обнаружены проблемы:"
|
||||
printf ' - %s\n' "${issues[@]}"
|
||||
echo "Логи: /opt/vesti/logs/, publisher: journalctl --user -u vesti-publisher -n 50"
|
||||
fi
|
||||
exit 0
|
||||
@@ -0,0 +1,9 @@
|
||||
# publisher-service — пример .env (скопируйте в /opt/vesti/.env, НЕ коммитить)
|
||||
# Токен бота-контроллера @dedinit_controller_bot (от @BotFather)
|
||||
VESTI_BOT_TOKEN=
|
||||
# Прокси до Telegram (из РФ заблокирован) — SOCKS5 туннель до VPS01
|
||||
TG_PROXY=socks5://127.0.0.1:1080
|
||||
# Список каналов публикации (через запятую). На старте один @dedinit_vesti.
|
||||
VESTI_BOT_CHANNELS=@dedinit_vesti
|
||||
# Порт сервиса
|
||||
PUBLISHER_PORT=8410
|
||||
@@ -0,0 +1,19 @@
|
||||
FROM python:3.12-slim
|
||||
|
||||
WORKDIR /srv/publisher
|
||||
|
||||
# Non-root, read-only fs (правило безопасности)
|
||||
RUN useradd -m -u 10001 appuser && mkdir -p /data && chown appuser:appuser /data
|
||||
|
||||
COPY requirements.txt .
|
||||
RUN pip install --no-cache-dir -r requirements.txt
|
||||
|
||||
COPY app ./app
|
||||
|
||||
USER appuser
|
||||
EXPOSE 8410
|
||||
|
||||
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s \
|
||||
CMD python -c "import urllib.request;urllib.request.urlopen('http://127.0.0.1:8410/healthz',timeout=4)" || exit 1
|
||||
|
||||
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8410"]
|
||||
@@ -0,0 +1,12 @@
|
||||
# Разбор списка каналов из конфигурации.
|
||||
from .config import settings
|
||||
|
||||
|
||||
def resolve_channels(channels: list[str] | None) -> list[str]:
|
||||
"""Итоговый список каналов для публикации.
|
||||
|
||||
channels из запроса (MAY переопределять) -> иначе VESTI_BOT_CHANNELS (конфиг).
|
||||
"""
|
||||
if channels:
|
||||
return list(dict.fromkeys([c.strip() for c in channels if c.strip()]))
|
||||
return list(settings.channels)
|
||||
@@ -0,0 +1,44 @@
|
||||
# Конфигурация publisher-service. Все секреты/настройки из env (.env).
|
||||
# Правило: секреты НЕ в коде, только в .env (не коммитить).
|
||||
import os
|
||||
from pathlib import Path
|
||||
|
||||
from dotenv import load_dotenv
|
||||
|
||||
BASE = Path(__file__).resolve().parents[3] # /opt/vesti (корень проекта)
|
||||
# override=False: env-переменные, уже заданные окружением (Docker: compose environment/env_file),
|
||||
# имеют приоритет над .env; на хосте (пустой env) значения подхватываются из .env.
|
||||
load_dotenv(BASE / ".env")
|
||||
|
||||
DEFAULT_CHANNELS = "@dedinit_vesti"
|
||||
|
||||
|
||||
from dataclasses import dataclass
|
||||
|
||||
|
||||
def _channels_list(raw: str | None) -> list[str]:
|
||||
"""Разбирает VESTI_BOT_CHANNELS: '@a,@b' -> ['@a','@b']. Пустые отбрасывает."""
|
||||
if not raw:
|
||||
return [DEFAULT_CHANNELS]
|
||||
return [c.strip() for c in raw.split(",") if c.strip()]
|
||||
|
||||
|
||||
@dataclass
|
||||
class Settings:
|
||||
"""Читает env ПРИ СОЗДАНИИ (после load_dotenv). Секреты — только из env/.env."""
|
||||
|
||||
bot_token: str = ""
|
||||
tg_proxy: str = "" # пусто → читаем из env (TG_PROXY); дефолт SOCKS5 127.0.0.1:1080
|
||||
channels: list[str] = None # type: ignore
|
||||
port: int = 8410
|
||||
api_base: str = "https://api.telegram.org"
|
||||
|
||||
def __post_init__(self):
|
||||
if self.channels is None:
|
||||
self.channels = _channels_list(os.getenv("VESTI_BOT_CHANNELS", ""))
|
||||
self.bot_token = self.bot_token or os.getenv("VESTI_BOT_TOKEN", "")
|
||||
self.tg_proxy = self.tg_proxy or os.getenv("TG_PROXY", "socks5://127.0.0.1:1080")
|
||||
self.port = self.port or int(os.getenv("PUBLISHER_PORT", "8410"))
|
||||
|
||||
|
||||
settings = Settings()
|
||||
@@ -0,0 +1,119 @@
|
||||
# publisher-service — изолированный FastAPI-микросервис публикации в Telegram.
|
||||
# POST /api/v1/publish — публикация карточки в канал(ы). GET /healthz — статус.
|
||||
# Единственная точка, знающая токен бота, прокси и каналы.
|
||||
import os
|
||||
from pathlib import Path
|
||||
|
||||
from fastapi import FastAPI, HTTPException
|
||||
from pydantic import BaseModel, Field
|
||||
|
||||
from .channels import resolve_channels
|
||||
from .config import settings
|
||||
from . import telegram
|
||||
|
||||
app = FastAPI(title="VESTI Publisher Service", version="0.1.0")
|
||||
|
||||
# путь к .env для test/curl (вне контейнера) — читаем через config (load_dotenv уже там)
|
||||
BASE = Path(__file__).resolve().parent.parent.parent
|
||||
|
||||
|
||||
class Card(BaseModel):
|
||||
text: str = Field(..., min_length=1, max_length=4096)
|
||||
media: str | None = None # путь к локальному файлу (если есть)
|
||||
direction: str = "linux"
|
||||
lang: str = "ru"
|
||||
|
||||
|
||||
class PublishRequest(BaseModel):
|
||||
card: Card
|
||||
channels: list[str] | None = None # MAY переопределять конфиг
|
||||
dry_run: bool = False # тестовый режим: не уходит в Telegram
|
||||
|
||||
|
||||
class ChannelResult(BaseModel):
|
||||
message_id: int = 0
|
||||
media_message_id: int | None = None
|
||||
views: int = 0
|
||||
error: str | None = None
|
||||
|
||||
|
||||
class PublishResponse(BaseModel):
|
||||
ok: bool
|
||||
results: dict[str, ChannelResult]
|
||||
dry_run: bool = False
|
||||
|
||||
|
||||
@app.get("/healthz")
|
||||
def healthz():
|
||||
"""Статус сервиса: бот, прокси, каналы, токен."""
|
||||
me_name = ""
|
||||
try:
|
||||
me = telegram.get_me()
|
||||
me_name = me.get("username", "")
|
||||
except Exception:
|
||||
me_name = ""
|
||||
return {
|
||||
"status": "ok",
|
||||
"bot": me_name or ("не проверен" if settings.bot_token else "нет токена"),
|
||||
"token_set": bool(settings.bot_token),
|
||||
"proxy": settings.tg_proxy,
|
||||
"channels": settings.channels,
|
||||
}
|
||||
|
||||
|
||||
@app.post("/api/v1/publish", response_model=PublishResponse)
|
||||
def publish(req: PublishRequest):
|
||||
"""Публикует «богатый репост» в каналы. Возвращает message_id по каждому каналу.
|
||||
|
||||
Порядок: медиа первым (sendPhoto/sendVideo) → текст вторым (sendMessage с
|
||||
link_preview_options disabled, чтобы не было предпросмотра ссылки).
|
||||
"""
|
||||
channels = resolve_channels(req.channels)
|
||||
if not channels:
|
||||
raise HTTPException(status_code=400, detail="Нет каналов для публикации")
|
||||
|
||||
# dry_run — тестовый режим: НЕ уходит в Telegram, возвращает эмуляцию результата
|
||||
if req.dry_run:
|
||||
results: dict[str, ChannelResult] = {
|
||||
ch: ChannelResult() for ch in channels
|
||||
}
|
||||
return PublishResponse(ok=True, results=results, dry_run=True)
|
||||
|
||||
results: dict[str, ChannelResult] = {}
|
||||
all_ok = True
|
||||
for ch in channels:
|
||||
res = ChannelResult()
|
||||
try:
|
||||
if req.card.media and Path(req.card.media).exists():
|
||||
# медиа первым (caption короткий: первые 1000 символов, т.к. лимит 1024)
|
||||
media_msg = telegram.send_media(ch, req.card.media, caption=req.card.text[:1000])
|
||||
res.media_message_id = media_msg
|
||||
# ПОЛНЫЙ текст отдельным сообщением (без предпросмотра ссылки)
|
||||
msg = telegram.send_message(ch, req.card.text)
|
||||
res.message_id = msg
|
||||
else:
|
||||
# без медиа: текст вторым; предпросмотр ссылки отключён (богатый репост)
|
||||
msg = telegram.send_message(ch, req.card.text)
|
||||
res.message_id = msg
|
||||
res.views = telegram.get_views(ch, res.message_id)
|
||||
except telegram.TelegramError as e:
|
||||
res.error = e.message
|
||||
all_ok = False
|
||||
results[ch] = res
|
||||
|
||||
if not all_ok:
|
||||
# одна ошибка не роняет остальные; статус 502 если все упали
|
||||
if all(r.error for r in results.values()):
|
||||
raise HTTPException(status_code=502, detail={ch: r.error for ch, r in results.items()})
|
||||
return PublishResponse(ok=all_ok, results=results)
|
||||
|
||||
|
||||
@app.get("/api/v1/views/{channel}/{message_id}")
|
||||
def views(channel: str, message_id: int):
|
||||
"""Views по каналу/сообщению (метрики)."""
|
||||
return {"channel": channel, "message_id": message_id, "views": telegram.get_views(channel, message_id)}
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
import uvicorn
|
||||
uvicorn.run("services.publisher.app.main:app", host="127.0.0.1", port=settings.port)
|
||||
@@ -0,0 +1,161 @@
|
||||
# Telegram Bot API клиент: httpx + SOCKS5-прокси.
|
||||
# TG из РФ заблокирован -> все запросы через TG_PROXY (socks5://127.0.0.1:1080).
|
||||
import httpx
|
||||
|
||||
from .config import settings
|
||||
|
||||
API = settings.api_base
|
||||
TIMEOUT = 20.0
|
||||
|
||||
|
||||
class TelegramError(Exception):
|
||||
"""Ошибка Bot API / сети. Код для HTTP-ответа сервиса."""
|
||||
|
||||
def __init__(self, message: str, http_code: int = 502, detail: str = ""):
|
||||
super().__init__(message)
|
||||
self.message = message
|
||||
self.http_code = http_code # какой HTTP-статус вернуть вызывающему
|
||||
self.detail = detail
|
||||
|
||||
|
||||
def _client() -> httpx.Client:
|
||||
if not settings.bot_token:
|
||||
raise TelegramError("VESTI_BOT_TOKEN не задан", http_code=500, detail="missing token")
|
||||
return httpx.Client(proxy=settings.tg_proxy, timeout=TIMEOUT)
|
||||
|
||||
|
||||
def _url(method: str) -> str:
|
||||
return f"{API}/bot{settings.bot_token}/{method}"
|
||||
|
||||
|
||||
def _call(method: str, **params) -> dict:
|
||||
"""Выполняет метод Bot API. Возвращает result. Ошибки -> TelegramError."""
|
||||
try:
|
||||
with _client() as c:
|
||||
r = c.post(_url(method), json=params, timeout=TIMEOUT)
|
||||
except Exception as e:
|
||||
raise TelegramError(f"Сеть/прокси до Bot API: {e}", http_code=502) from e
|
||||
|
||||
if r.status_code != 200:
|
||||
# 401 bad token, 403 forbidden (бот не админ) и т.п.
|
||||
try:
|
||||
body = r.json()
|
||||
desc = body.get("description", "")
|
||||
except Exception:
|
||||
desc = r.text[:200]
|
||||
raise TelegramError(
|
||||
f"Bot API {method}: HTTP {r.status_code} {desc}",
|
||||
http_code=403 if r.status_code == 403 else 502,
|
||||
detail=desc,
|
||||
)
|
||||
data = r.json()
|
||||
if not data.get("ok"):
|
||||
desc = data.get("description", "")
|
||||
raise TelegramError(f"Bot API {method}: {desc}", http_code=502, detail=desc)
|
||||
return data.get("result", {})
|
||||
|
||||
|
||||
def send_message(chat_id: str, text: str, parse_mode: str | None = None) -> int:
|
||||
"""Отправляет текст. По умолчанию — plain (карточка репоста: исходный текст поста
|
||||
с сырыми символами <,>,&; ссылки Telegram распознаёт сам).
|
||||
link_preview_options={is_disabled:True} — НЕ показывать предпросмотр ссылки
|
||||
(чтобы канал не выглядел как агрегатор ссылок с превью)."""
|
||||
params = {
|
||||
"chat_id": chat_id,
|
||||
"text": text,
|
||||
"link_preview_options": {"is_disabled": True},
|
||||
}
|
||||
if parse_mode:
|
||||
params["parse_mode"] = parse_mode
|
||||
return _call("sendMessage", **params)["message_id"]
|
||||
|
||||
|
||||
def send_photo(chat_id: str, photo_path: str, caption: str = "") -> int:
|
||||
"""Отправляет фото (медиа первым). Возвращает message_id."""
|
||||
if not photo_path:
|
||||
raise TelegramError("photo_path пуст", http_code=400)
|
||||
try:
|
||||
with _client() as c, open(photo_path, "rb") as f:
|
||||
r = c.post(
|
||||
_url("sendPhoto"),
|
||||
data={"chat_id": chat_id, "caption": caption[:1024]},
|
||||
files={"photo": f},
|
||||
timeout=TIMEOUT,
|
||||
)
|
||||
except TelegramError:
|
||||
raise
|
||||
except Exception as e:
|
||||
raise TelegramError(f"sendPhoto сеть: {e}", http_code=502) from e
|
||||
|
||||
if r.status_code != 200:
|
||||
try:
|
||||
desc = r.json().get("description", "")
|
||||
except Exception:
|
||||
desc = r.text[:200]
|
||||
raise TelegramError(f"sendPhoto: HTTP {r.status_code} {desc}", http_code=403 if r.status_code == 403 else 502)
|
||||
data = r.json()
|
||||
if not data.get("ok"):
|
||||
raise TelegramError(f"sendPhoto: {data.get('description','')}", http_code=502)
|
||||
return data["result"]["message_id"]
|
||||
|
||||
|
||||
def send_video(chat_id: str, video_path: str, caption: str = "") -> int:
|
||||
"""Отправляет видео (медиа первым). Возвращает message_id."""
|
||||
if not video_path:
|
||||
raise TelegramError("video_path пуст", http_code=400)
|
||||
try:
|
||||
with _client() as c, open(video_path, "rb") as f:
|
||||
r = c.post(
|
||||
_url("sendVideo"),
|
||||
data={"chat_id": chat_id, "caption": caption[:1024]},
|
||||
files={"video": f},
|
||||
timeout=TIMEOUT,
|
||||
)
|
||||
except TelegramError:
|
||||
raise
|
||||
except Exception as e:
|
||||
raise TelegramError(f"sendVideo сеть: {e}", http_code=502) from e
|
||||
|
||||
if r.status_code != 200:
|
||||
try:
|
||||
desc = r.json().get("description", "")
|
||||
except Exception:
|
||||
desc = r.text[:200]
|
||||
raise TelegramError(f"sendVideo: HTTP {r.status_code} {desc}", http_code=403 if r.status_code == 403 else 502)
|
||||
data = r.json()
|
||||
if not data.get("ok"):
|
||||
raise TelegramError(f"sendVideo: {data.get('description','')}", http_code=502)
|
||||
return data["result"]["message_id"]
|
||||
|
||||
|
||||
def send_media(chat_id: str, media_path: str, caption: str = "") -> int:
|
||||
"""Отправляет медиа по расширению: фото или видео. Возвращает message_id."""
|
||||
if str(media_path).lower().endswith((".mp4", ".mov", ".avi", ".mkv")):
|
||||
return send_video(chat_id, media_path, caption)
|
||||
return send_photo(chat_id, media_path, caption)
|
||||
|
||||
|
||||
def get_views(chat_id: str, message_id: int) -> int:
|
||||
"""Просмотры опубликованного сообщения (getMessage → views)."""
|
||||
try:
|
||||
r = _call("getMessage", chat_id=chat_id, message_id=message_id)
|
||||
return int(r.get("views") or r.get("forwards") or 0)
|
||||
except TelegramError:
|
||||
return 0
|
||||
|
||||
|
||||
def get_me() -> dict:
|
||||
return _call("getMe")
|
||||
|
||||
|
||||
def delete_message(chat_id: str, message_id: int) -> bool:
|
||||
"""Удаляет сообщение из канала. True если успешно."""
|
||||
try:
|
||||
_call("deleteMessage", chat_id=chat_id, message_id=message_id)
|
||||
return True
|
||||
except TelegramError:
|
||||
return False
|
||||
|
||||
|
||||
def get_chat(chat_id: str) -> dict:
|
||||
return _call("getChat", chat_id=chat_id)
|
||||
@@ -0,0 +1,26 @@
|
||||
services:
|
||||
publisher:
|
||||
build: .
|
||||
container_name: vesti-publisher
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- "127.0.0.1:8410:8410" # только локально (внутри bigbox)
|
||||
env_file:
|
||||
- ../../.env # VESTI_BOT_TOKEN, TG_PROXY, VESTI_BOT_CHANNELS (корень /opt/vesti)
|
||||
environment:
|
||||
- PUBLISHER_PORT=8410
|
||||
# в контейнере 127.0.0.1 — это сам контейнер; туннель SOCKS5 живёт на хосте
|
||||
- TG_PROXY=socks5://host.docker.internal:1080
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
volumes:
|
||||
# медиа для карточек: веб шлёт media/<file> (media_path из БД).
|
||||
# Физически файлы лежат в /opt/vesti/media/media/ (вложенный каталог, см. download_media в краулере).
|
||||
# Монтируем именно внутренний каталог, чтобы Path('media/<file>') в контейнере (от WORKDIR /srv/publisher) попал в файл.
|
||||
- ../../media/media:/srv/publisher/media:ro
|
||||
healthcheck:
|
||||
test: ["CMD", "python", "-c", "import urllib.request;urllib.request.urlopen('http://127.0.0.1:8410/healthz',timeout=4)"]
|
||||
interval: 30s
|
||||
timeout: 5s
|
||||
retries: 3
|
||||
start_period: 10s
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user