DataTalksClub / DataTalksClub/dataops

Ship approved Typefully saved-draft creation

Open
#127 27 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

assistant backend data enhancement human infra P1 testing work-engine
Dominant language
TypeScript
Stars
2
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Ship approved Typefully saved-draft creation

Status: blocked overall — source/reviews and the normal-CI all-off deployment are complete; no direct implementation remains, private readiness may be decided now, and the one controlled Typefully effect waits for #166/#182 cleanup and #128's staged HUMAN rollout
Tags: enhancement, assistant, work-engine, backend, infra, testing, data, P1, human
Parent: #122 (M6)
Depends on: #126 shared coordinator/outbox source is satisfied; #124 approval/worker and #125 z.ai source are integrated/default-off deployed; #128 owns all live evidence; #166 A/B/C → #182 final Cards preflight → D → cleanup and one ordinary all-off deployment precede enablement
Satisfied dependencies: accepted source 92706b37abb47616fd071606193066a7b3b735a3 is on main and included in successful normal dark deployments; #129/#130/#131 and #136/#140/#143 are complete
Blocks: no source implementation — #128 cross-posts #127's live evidence, then PM closes #127; #122 closes last
Next owner: a privately authorized Typefully owner may complete Stage A decisions now; after #166 cleanup, the #128 HUMAN rollout owner and On-Call execute Stages B-D
Resume condition: #166/#182 complete the reviewed production sequence, canonical writers reopen, temporary phase machinery is removed, ordinary OIDC deployment is restored, and one normal main run succeeds with the exact six conversational controls dark
Architecture: docs/CONVERSATIONAL_AGENT_PLUGIN_ARCHITECTURE.md (accepted architecture commit 4e5402c)
Current evidence: Assistant Engineer PASS, Tester PASS, PM acceptance, normal dark deployment 31545689094, and dark reconfirmation 31711997388

Product outcome

After a verified private-Telegram operator explicitly confirms typed text as public social source, the conversational runtime may prepare and revise one complete Typefully proposal. Only a current exact approval may queue one durable worker attempt that creates one saved draft in one permitted logical account.

The effect is deliberately narrow:

plugin: typefully
action: propose_draft
operation: create
account: alexey | datatalksclub
platforms: x | linkedin | both
delivery: operator_reconciliation_only
result: one saved draft, unscheduled, unpublished, and unshared

There is no update, delete, schedule, publish, next-free-slot, preferred time, public share, media, analytics, webhook, comment, account administration, bulk/multi-draft effect, or direct /social write.

The accepted child source remains the detailed implementation authority. This lifecycle reconciliation does not reopen its schema, prompt/context, transaction, executor, retention, or IAM design.

Completed source and default-off evidence

Accepted source commit 92706b37abb47616fd071606193066a7b3b735a3 passed specialist, Tester, and PM review and is an ancestor of deployed SHA 794076354048f6ff3417d55d13d334caf4237cea.

Normal OIDC run 31545689094 successfully deployed the integrated conversational graph, reached UPDATE_COMPLETE, seeded, and passed deployed smoke. Run 31711997388 reconfirmed that path. Both used the strict dark rollout with:

Telegram ingress=false
execution=false
plugins=none
Typefully external=false
voice=false
photo=false

The execution worker, shared approval/recovery/result-delivery resources, exact configuration references, and default-off controls are therefore published. This is not evidence that a real Typefully token/mapping was read, z.ai or Typefully was called, a saved draft exists, an alarm fired, or rollback from an enabled state passed.

No new #127 source implementation or separate deployment is required. #128 is the sole owner of all live flag changes and provider evidence.

Permanent product contract

Public-source and proposal boundary
  • Only current typed operator text can be confirmed for this Typefully journey. Voice/photo-derived text, files, fetched URLs, ordinary private conversation, summaries, todo context, organization/user-private/restricted references, and credentials-adjacent material are excluded.
  • Public-source confirmation occurs before a Typefully z.ai turn. The model cannot assert or downgrade classification, grant permission, select hidden numeric account mappings, or execute.
  • The strict create-only candidate binds one logical account, selected platforms, every ordered post, optional title/scratchpad, current trusted public-source proofs, actor/conversation/revision, permission/config/policy/build/schema digests, and the exact rendered preview.
  • Overflow, unknown fields, schedule/publish/share/media semantics, invalid/stale grants, and permission/config drift fail before queue/provider work. Content is never silently truncated, reordered, merged, or dropped.
  • Request changes creates a complete new immutable version and revokes old controls. Cancel/discard/expiry/detached text/stale controls produce no effect.
Approval and worker boundary
  • Core owns proposal/presentation transitions and exact approval. One transaction consumes the presentation, claims the proposal, and queues one deterministic attempt; the webhook never calls Typefully inline.
  • The capability-scoped worker rechecks current actor, identity/channel, permission/account scope, proposal hashes, config digests, execution control, secret/mapping readiness, and lease before recording dispatch intent.
  • Only the execution worker may resolve the exact Typefully secret and numeric social-set mapping. Backend, Telegram, model/plugin, result dispatcher, public status, proposal, and receipt paths have no token/numeric mapping or general Typefully client.
  • After one persisted dispatch intent, the worker makes at most one exact create request. Success requires the returned ordered content/account and saved-draft state to match the approval, with no schedule/publication/share fields.
  • The actor-private edit URL is delivered only through the owner/channel-bound result path and expires under the accepted 30-day private-payload policy. The one-year receipt contains safe identifiers/digests only.
Uncertainty and rollback

The delivery mode is permanently operator_reconciliation_only:

  • a documented definitive pre-effect/rejection case may be failed_safe;
  • transport loss, timeout, 5xx/unclassified response, malformed/contradictory success, or crash after dispatch intent becomes outcome_unknown;
  • outcome_unknown is never automatically retried, replayed, re-approved, or converted into a guessed result;
  • a current authorized admin may record found or not_found only after following the privately accepted account-search runbook; neither resolution writes to Typefully;
  • not_found requires a new current proposal and approval if the operator still wants a draft.

Do not manufacture an ambiguous provider outcome for acceptance. If one occurs naturally during the single authorized effect, stop, preserve uncertainty, reconcile without retry, and cross-post sanitized evidence. If no ambiguity occurs, accepted automated uncertainty coverage plus private runbook readiness satisfies the release boundary; a second provider call is not required.

Rollback turns Typefully external execution off, then removes Typefully from the plugin allowlist in #128's reverse sequence. It preserves proposal/attempt/result truth, private TTLs, safe receipts, and any external draft. It cannot delete, schedule, publish, or retry a provider effect and never revives a legacy writer.

No migration or legacy-write work

#127 is permanent product behavior, not a data migration. It does not import old assistant/social drafts, provider history, tokens, account mappings, conversation state, or source-repository data.

The old social assistant, assistant-job Typefully write path, /social mutation, and legacy flags cannot reach a model/provider write. Do not add a compatibility writer, dual path, backfill/checkpoint/resume/orphan/rollback API, importer, or ongoing migration suite.

#166/#182 is deployment sequencing for the canonical Card/Task baseline, not a Typefully migration. Its protected phase commits must not acquire Typefully variables, secrets, account mappings, proposals, provider calls, canaries, or #127 source changes.

Remaining HUMAN stages through #128

Stage A — private authority and configuration decision (eligible now)

Owner: authorized Typefully product/account owner. No provider/AWS call is required.

Privately record:

  • whether the controlled effect targets logical account alexey or datatalksclub;
  • the intended operator and allowed account scope;
  • the expected secret/config revision and logical-to-numeric mapping ownership;
  • the typed-public-source decision, exact one-effect limit, evidence/test window, and rollback owner;
  • acceptance of the operator_reconciliation_only runbook and private edit-link handling.

Do not publish token/secret references, numeric mappings, account/provider output, approved social copy, source text, private edit URL, runbook, Telegram identity, or operational links.

Stage B — dark readiness and preview-only behavior

Owner: #128 rollout owner after #166/#182 cleanup.

  1. Reconfirm one ordinary all-off OIDC deployment from the final steady-state SHA.
  2. Verify privately that the worker has the reviewed exact configuration/permission references and disabled Typefully performs no secret read/provider call.
  3. Enable ingress/execution with plugin allowlist todo,typefully while Typefully external remains false.
  4. From newly typed confirmed-public input, propose, clarify, revise, and cancel/discard one Typefully preview. Prove all approved content/account/platform/source/effect semantics are visible and there is no active approve/queue/provider path.
  5. Leave no queued or dispatchable Typefully proposal from this preview-only stage.
Stage C — exactly one controlled saved-draft effect

Owner: authorized operator with On-Call.

  1. Recreate a fresh current typed-public proposal for the one Stage A logical account and inspect the complete immutable preview.
  2. Enable Typefully external execution only through #128's reviewed ordinary main OIDC update.
  3. Approve exactly once. Prove duplicate callback/worker delivery converges on the same attempt and at most one Typefully create occurs.
  4. Verify privately that the stored result has the exact approved ordered content in the intended account and is saved, unscheduled, unpublished, and unshared. Verify the owner receives the private edit link while shared status/public evidence does not expose it.
  5. A denied/unpermitted-account check may exercise only the pre-dispatch authorization boundary and must make zero provider calls. Do not create a draft in every configured account; one controlled provider effect is sufficient.
  6. If natural uncertainty occurs, follow the no-retry rule above. Otherwise do not create uncertainty or a second effect solely to test reconciliation.
Stage D — observation, rollback, and closeout
  • Cross-post sanitized counts/states and pass/fail results to #127 from #128; include the final ordinary deployment and child-stage links, but no private provider material.
  • Turn Typefully external off and remove Typefully from the allowlist in #128's reverse rollback. Prove no new approval/dispatch path and truthful retained result/attempt state.
  • PM checks every #127 criterion, including exactly one provider effect, private-source exclusion, no scheduling/publication/sharing, private-result boundary, and conditional uncertainty handling.

#127 may close after its Stage A-D evidence passes even if unrelated #128 media/alarm stages are still being finalized. #128 and #122 retain their own full-matrix closure gates.

Acceptance criteria

  • The static Typefully plugin, typed-public-source gate, strict non-lossy schema, complete immutable preview, request-changes flow, exact approval, worker-only credential/capability, one-request serializer, validated saved-draft result, privacy/retention, uncertainty, and legacy-write removal passed Assistant Engineer, Tester, and PM acceptance.
  • Accepted source 92706b3 is on main and included in successful normal OIDC all-off deployments with seed and smoke green.
  • Final rollout controls keep Typefully visibility in the strict plugin allowlist and external dispatch behind the separate Typefully external control; both are dark by default.
  • No source implementation, migration/import, provider-data backfill, or separate #127 deployment remains.
  • [HUMAN] Stage A privately records one intended account/operator scope, reviewed config ownership, one-effect limit, and accepted uncertainty/edit-link/rollback runbook.
  • #166/#182 complete, temporary cutover machinery is removed, and one following ordinary all-off deployment succeeds before Typefully enablement.
  • [HUMAN via #128] Stage B proves final dark readiness and complete Typefully propose/revise/cancel behavior with external execution off, zero approve/queue/provider path, and no dispatchable residue.
  • [HUMAN via #128] Stage C creates exactly one approved typed-public-source saved draft in one permitted account with exact ordered content and unscheduled/unpublished/unshared state; denied scope and duplicates create zero additional effects.
  • [HUMAN if naturally needed] Any natural outcome_unknown is reconciled through the accepted private runbook without retry; absence of natural ambiguity does not require manufacturing one.
  • [HUMAN via #128] Stage D restores Typefully external/allowlist controls in reverse order, preserves truthful evidence/private TTL behavior, and cross-posts sanitized acceptance links.
  • PM accepts the cross-posted evidence and closes #127; #128/#122 retain their separate remaining gates.

Out of scope

Provider update/delete/schedule/publish/share/media/analytics; multiple provider drafts for acceptance; deliberate ambiguity/failure injection against the real provider; voice/photo/file/URL/private source; web approval; dynamic plugins; generic provider framework; source-repository edits; raw provider/account/credential/runbook evidence in public; manual Lambda/app deployment; queue/data cleanup; migration/import/export/restore; and any #166 phase modification.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with docs/CONVERSATIONAL_AGENT_PLUGIN_ARCHITECTURE.md and the accepted source commit referenced in the issue. Read #128 for the live rollout evidence and #166/#182 for the deployment prerequisites. Done means the authorized staged rollout, one controlled saved-draft effect, rollback, and sanitized closeout evidence are complete; the issue states that no direct source implementation remains.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, github-actions, typescript
Domain
backend, devops, infrastructure, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.