Co.PropertyTeam wikiCo.Property20 October 2026
Press slash to search. Arrow keys select a result.
Internal knowledge
Browse the wiki

Workflows

LINE boundaries

In progress

LINE employee operations bot, Hermes adapter, and company Official Account are separate identities. A message flow only becomes operational evidence when the right record and acceptance boundary are confirmed.

Download page Markdown
Interactive mapSelect a node to read its explanation. Use Work on this beside the section to prepare a change.
LINE boundaries: separate identities, accepted records, clear limits diagramThe company Official Account, employee operations bot, and Hermes adapter are distinct. A reviewed record boundary determines whether an interaction can support an operational outcome.Company OA — LINE boundaries: separate identities, accepted records, clear limitsCompany OAEmployee ops bot — LINE boundaries: separate identities, accepted records, clear limitsEmployee ops botHermes adapter — Hermes: an adapter boundary, not a company identityHermes adapterReviewed record — LINE boundaries: separate identities, accepted records, clear limitsReviewed recordAccepted outcome — LINE boundaries: separate identities, accepted records, clear limitsAccepted outcome
Separate identities connect through a reviewed record boundary.Solid · information flow
Read the diagram as text

The company Official Account, employee operations bot, and Hermes adapter are distinct. A reviewed record boundary determines whether an interaction can support an operational outcome.

  • Company OA → LINE boundaries: separate identities, accepted records, clear limits
  • Employee ops bot → LINE boundaries: separate identities, accepted records, clear limits
  • Hermes adapter → Hermes: an adapter boundary, not a company identity
  • Reviewed record → LINE boundaries: separate identities, accepted records, clear limits
  • Accepted outcome → LINE boundaries: separate identities, accepted records, clear limits
What it does

Keep messaging concepts useful while preventing unconfirmed end-to-end acceptance or identity ownership from being represented as finished.

Responsibility

The company Official Account represents the company-facing identity.

Next step

Name the intended identity before designing or investigating a message flow.

Separate identities prevent a message from gaining accidental authority

In progress

The employee operations bot, Hermes adapter, and company Official Account are different identities.

Read the details

The employee operations bot, Hermes adapter, and company Official Account are different identities. Their names may appear near one another in a system diagram, but that does not grant them the same role, audience, permissions, or acceptance authority.

Before a messaging workflow is changed, identify which identity is intended to speak, which record will carry the result, and who can authorise the next step. Avoid using an adapter or console login as evidence that this boundary is settled.

Current
In progress — final ownership and end-to-end acceptance are explicitly not confirmed.
Proposed next state
Document approved identity, authorised operator, record linkage, and handoff conditions after an owner verifies them.
Expected outcome
A message workflow can be assessed without conflating technical connectivity with organisational authority.
Checks to include when changing this section
  • Check all three identities are separately named in the diagram and text equivalent.
  • Check no exported prompt includes a credential request or suggests sending a test message automatically.

A conversation is not evidence until its record boundary is accepted

In progress

A message can provide context, but an operational result needs an approved record link, known identity, and a reviewer who can accept the stated outcome.

Read the details

A message can provide context, but an operational result needs an approved record link, known identity, and a reviewer who can accept the stated outcome. This is particularly important when a message could affect a guest, owner, or task state.

Use a safe placeholder in documentation. Do not place private message text, phone numbers, tokens, or screenshots of live conversations into the wiki, llms.txt, or contextual work draft.

Current
In progress — company-owned LINE access and an approved conversation linked to a record remain an open rollout item.
Proposed next state
Verify a controlled, approved conversation with the intended record and review boundary before marking this path checked.
Expected outcome
The team can distinguish useful message context from a confirmed operational record.
Checks to include when changing this section
  • Search generated exports for token-like or message-payload content; none should be present.
  • Check a selected context section contains only its own prose and source pointers.

Mark acceptance pending until a real, authorised case closes

In progress

The available information does not confirm end-to-end LINE acceptance or final ownership.

Read the details

The available information does not confirm end-to-end LINE acceptance or final ownership. The safe status is pending, not “nearly done” or “live”. A future accepted case should describe its actor, approved identity, record, decision, evidence, and exception path.

The wiki can help someone prepare a careful investigation or plan. It cannot send a test, alter an Official Account, change credentials, or claim the result.

Current
In progress — no final acceptance is asserted.
Proposed next state
Close only when an approved owner verifies a real case and records the acceptance evidence and exceptions.
Expected outcome
Open uncertainty stays visible to the people responsible for resolving it.
Checks to include when changing this section
  • Check “acceptance pending” is present in the page, Markdown export, and context export.
  • Check Open Codex draft disables rather than truncates a long complete prompt.

Apply with care

A concrete safe example

Example, responsibilities & checklist

A safe message-to-record question

Instead of copying a conversation into a general note, ask whether the company Official Account, employee operations bot, or Hermes adapter is the approved identity for this step; then link only the approved record reference after acceptance is confirmed.

Responsibilities

  • The company Official Account represents the company-facing identity.
  • The employee operations bot is a separate operational identity.
  • Hermes is an adapter boundary, not a substitute for company identity or approval.
  • A responsible reviewer confirms what conversation, record, and outcome can be accepted.

Checklist

  1. Name the intended identity before designing or investigating a message flow.
  2. Keep message payloads, customer details, and tokens out of the wiki and prompt exports.
  3. Do not treat an available console or adapter as proof of end-to-end acceptance.
  4. Link an approved conversation to the relevant record only after authority and outcome are confirmed.
Expected outcome

A team member knows which identity and record boundary needs confirmation before relying on a message in operations.

Traceability without sensitive material

Source pointers and exports

This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.

Documentation references
  • Handoff / START-HERE.html
  • Handoff / pages/workflows.html
  • Handoff / pages/infrastructure.html
Page MarkdownPage context JSON