feat: review Gustavo and Marcos submitted skills
This commit is contained in:
Marcos Silva
@@ -0,0 +1,229 @@
|
||||
h2. Overview
|
||||
|
||||
Which level to use for a log line in GFiber services.
|
||||
|
||||
Graylog storage is shared, so every INFO line written on a healthy run is paid for in retention days: the more a service logs, the shorter the window for grepping an incident that already happened. A service that logs too little is untriageable. This page is the line between the two.
|
||||
|
||||
Applies to all GFiber services. The 13 Go services log through {{mano.netcracker.com/go-logging/v3}}; the Java services follow the same levels with different API names.
|
||||
|
||||
Three things to know before choosing a level:
|
||||
|
||||
* {{LOG_LEVEL}} is {{INFO}} in every shipped Helm chart. Treat DEBUG as *not present in production*.
|
||||
* Support starts from one identifier, usually an alarm id or a ticket id, and searches Graylog full text. A decision that never printed that identifier cannot be found.
|
||||
* Batch sizes are not capped upstream. A line inside a loop scales with ONT or item count, not with request count.
|
||||
|
||||
h2. Levels
|
||||
|
||||
|| Level || Use for || Volume on a healthy run ||
|
||||
| ERROR | Work was lost and a human must look. Carries the identifiers of the lost work. | rare, each one actionable |
|
||||
| WARN | An item was dropped or degraded and the service continues. Carries identifiers when no result line will be written. | rare |
|
||||
| INFO | Work received, work finished, one result per work item. | O(1) per request or batch, plus one line per item |
|
||||
| DEBUG | Everything else: intermediate collections, per-object detail, payloads, filter internals. | unbounded |
|
||||
| FATAL | Cannot start and serve. Terminates the process. | startup only |
|
||||
|
||||
h2. How to choose
|
||||
|
||||
Stop at the first yes.
|
||||
|
||||
# Work was lost and someone has to look at it. → *ERROR*
|
||||
# An item was dropped or degraded, and the service keeps going. → *WARN*
|
||||
# It is one of these four: work received, work finished, the result of one item, or a decision that ends an item and is not already in that item's result message. → *INFO*
|
||||
# It fires more than once per item, or prints a collection, a struct or a body. → *DEBUG*
|
||||
# Anything else. → *DEBUG*
|
||||
|
||||
{tip}
|
||||
Unsure between two levels? Take the lower one. A line at DEBUG can be recovered with on-demand troubleshooting or promoted next release. Retention days spent on a line nobody reads cannot.
|
||||
{tip}
|
||||
|
||||
h3. WARN or ERROR
|
||||
|
||||
The boundary that gets argued about most.
|
||||
|
||||
* *ERROR* means the service could not do what it was asked and no automatic mechanism will fix it. A human has to look.
|
||||
* *WARN* means the service did not do something, but that outcome is defined and expected in operation: input was unusable, capacity was full, a business rule dropped the item.
|
||||
|
||||
The test: *if this fires two hundred times tonight, does someone need to be paged?* Yes is ERROR. No is WARN.
|
||||
|
||||
Two consequences worth stating, because both are commonly got wrong:
|
||||
|
||||
* A call that failed but *will be retried automatically* is not an ERROR on the attempt. The attempt is DEBUG. It becomes ERROR when the retries are exhausted and the work is actually lost.
|
||||
* A validation rejection is never an ERROR, however loud it looks. The client sent something unusable and the service behaved correctly. That is WARN.
|
||||
|
||||
h3. FATAL
|
||||
|
||||
Startup only, and only when the process cannot serve at all: unreadable configuration, no database, a required dependency that will never appear. {{LogFatal}} terminates the process, so calling it on a request path turns one bad request into an outage. There is no case for FATAL after the service reports ready.
|
||||
|
||||
h2. Cases
|
||||
|
||||
h3. Work intake and results
|
||||
|
||||
|| Case || Level || Note ||
|
||||
| Request, batch or message arrived | INFO | counts and the values that identify the scope, such as alarm names, severities, OLT, HUT; no payload and no id list |
|
||||
| Batch finished | INFO if ok, ERROR otherwise | one summary line with in, out, duration and status, written from a defer registered before any recover so a panic still produces it |
|
||||
| Result of one work item | INFO | one per item, with its identifier and outcome; this is the line support greps for, and the one line that must never be demoted |
|
||||
| Payload of the work item | DEBUG | or behind on-demand troubleshooting |
|
||||
| Decision that ends the item | INFO | only when it is not already visible in that item's result message |
|
||||
| Intermediate lookup or filter result | DEBUG | log the count at INFO if it matters, the members at DEBUG |
|
||||
| Anything inside a loop over domain objects | DEBUG | plus one count after the loop |
|
||||
|
||||
h3. Rejections and failures
|
||||
|
||||
|| Case || Level || Note ||
|
||||
| Input malformed, null or failed validation | WARN | carry the identifiers that survived parsing, and the body size |
|
||||
| Rejected for capacity or backpressure | WARN | one line per rejected request, never per item |
|
||||
| No handler or policy matched the work | WARN | carry the identifiers, because no result line will be written |
|
||||
| Upstream call failed, will be retried | DEBUG | the attempt is not yet a failure |
|
||||
| Upstream call failed after retries | ERROR | carry the identifiers and the step that stopped |
|
||||
| Some items succeeded, some failed | ERROR | on the summary line, with the split |
|
||||
| Panic recovered | ERROR | log the recovered value and the stack, and keep serving |
|
||||
|
||||
h3. Service lifecycle
|
||||
|
||||
|| Case || Level || Note ||
|
||||
| Started, listeners bound, dependencies resolved | INFO | a handful of lines, once per process |
|
||||
| Effective configuration | DEBUG | never secrets, tokens or credentials |
|
||||
| Graceful shutdown | INFO | |
|
||||
| Cannot start at all | FATAL | the only place FATAL is allowed |
|
||||
| Database connection established | INFO | once at startup; per query is DEBUG |
|
||||
|
||||
h3. Background work
|
||||
|
||||
|| Case || Level || Note ||
|
||||
| Scheduled tick that found nothing to do | DEBUG | a tick every few seconds at INFO is one of the cheapest ways to burn retention |
|
||||
| Scheduled tick that did work | INFO | one line with counts, not one per item |
|
||||
| Kafka batch consumed | INFO | one summary per batch, same shape as an HTTP batch |
|
||||
| One Kafka message processed | DEBUG | the per-item result line already covers what support needs |
|
||||
| Message that cannot be parsed | ERROR | carry the message key and raise a metric; it will never parse, so it is lost work |
|
||||
| Consumer rebalance or lag | none | leave it to the client library and to metrics |
|
||||
|
||||
h3. Keep out
|
||||
|
||||
|| Case || Level || Note ||
|
||||
| Health, liveness and readiness probes | none on success | probe traffic is constant; log only a failing probe |
|
||||
| Every outbound HTTP request and response | DEBUG | rates and durations belong in metrics |
|
||||
| Upstream returned an empty result | DEBUG | unless it changes the outcome, and then it belongs in the item's result message |
|
||||
| Third-party library output | set it explicitly | do not let a dependency inherit DEBUG in production |
|
||||
| Secrets, tokens, passwords | never | at any level |
|
||||
| ONT serial, account id, hostname | not at INFO | on high-volume paths; fine in a bounded projection or at DEBUG |
|
||||
|
||||
If a line has to be INFO and is still too frequent, *sample it*: log one in N with the count of what was skipped. Demoting it to DEBUG removes it from production entirely, which is usually not the intent.
|
||||
|
||||
h2. Rules
|
||||
|
||||
# No unbounded collection at INFO. The count belongs at INFO, the collection behind it at DEBUG.
|
||||
# No INFO inside a loop over domain objects.
|
||||
# Cap identifier lists at 50 entries followed by {{+N more}}.
|
||||
# Always use the {{Ctx}} variant. {{LogInfo}} without {{Ctx}} drops {{request_id}} and every business identifier from the MDC, which makes the line impossible to attach to anything.
|
||||
# Never log a full request or response body at INFO.
|
||||
# Mint correlation ids at ingress, not deeper. An id created inside the handler that already needed it cannot join the lines written before that point.
|
||||
# No secrets, tokens or customer PII at any level.
|
||||
|
||||
These double as the review checklist. Ask them on any MR that adds or moves a log line.
|
||||
|
||||
h2. Field format
|
||||
|
||||
{{key=value}} pairs, snake_case keys, prefixed by the subject of the line. Quote with {{%q}} only when the value can be empty or contain spaces.
|
||||
|
||||
{code:go}
|
||||
logging.LogInfoCtx(ctx, "policy batch received: batch_id=%s policy=%q alarms=%d alarm_names=%s",
|
||||
batchID, request.Policy, len(request.Alarms), distinctAlarmNames(request.Alarms))
|
||||
{code}
|
||||
|
||||
The runtime already adds a prefix, so do not repeat any of it in the message:
|
||||
|
||||
{noformat}
|
||||
[2026-09-02T11:52:06.222] [INFO] [request_id=-] [tenant_id=-] [thread=-] [class=policies:executor.go:68] <your message>
|
||||
{noformat}
|
||||
|
||||
|| Key || Source || Present on ||
|
||||
| request_id | MDC, from the cloud-core context propagation middleware | every line, automatically |
|
||||
| batch_id | minted once at ingress, carried in the context | every line handling that batch |
|
||||
| alarm_id, ticket_id, order_id | the domain object | every line naming a single work item |
|
||||
| alarm_ids | capped list | lines describing a set |
|
||||
|
||||
{note}
|
||||
This is not structured logging. The logger emits a text message behind a fixed prefix, so Graylog does not extract these keys into searchable fields. They are found by full text search, which is exactly why identifiers have to appear literally in the message.
|
||||
{note}
|
||||
|
||||
h2. Anti-patterns
|
||||
|
||||
All of these shipped and passed review.
|
||||
|
||||
h3. Printing a pointer instead of the data
|
||||
|
||||
{code:go}
|
||||
logging.LogInfoCtx(ctx, "Valid alarms: %+v", validAlarms) // map[string]*Alarm
|
||||
{code}
|
||||
|
||||
Go's {{fmt}} does not dereference pointers held inside a map or a slice, so what reaches Graylog is a map key and a heap address:
|
||||
|
||||
{noformat}
|
||||
Valid alarms: map[7c0e-1:0x7cabe66aa060]
|
||||
{noformat}
|
||||
|
||||
Print the identifiers, or a count.
|
||||
|
||||
h3. A verb that is not a verb
|
||||
|
||||
{code:go}
|
||||
logging.LogDebug("... for alarm %s+", alarm) // *Alarm
|
||||
{code}
|
||||
|
||||
{{%s+}} is {{%s}} followed by a literal plus. On a struct with non-string fields {{%s}} emits error markers:
|
||||
|
||||
{noformat}
|
||||
&{7c0e-1 %!s(int=3) %!s(bool=false) 2026-09-02 11:52:06 ...}+
|
||||
{noformat}
|
||||
|
||||
h3. INFO inside a per-object loop
|
||||
|
||||
{code:go}
|
||||
for _, target := range targets {
|
||||
...
|
||||
logging.LogInfo("ONT target %s is not eligible for this ticket: %+v", ontId, target)
|
||||
}
|
||||
{code}
|
||||
|
||||
One INFO line per monitoring target, dumping the whole struct, where the logged branch is the *normal* outcome and not an exception. This scales with ONT count, not with request count. Log the members at DEBUG and one count after the loop.
|
||||
|
||||
h3. A rejection that returns in silence
|
||||
|
||||
A request rejected for capacity, for an unmatched handler or for a malformed body, returning a status code with no log line and no metric. Every identifier in that request is then absent from Graylog, and the request counter and the result counter diverge with nothing to explain the gap.
|
||||
|
||||
h3. Losing the panic value
|
||||
|
||||
{code:go}
|
||||
logging.LogErrorCtx(ctx, "Unexpected panic: %v", reasonConstant, stackTrace)
|
||||
{code}
|
||||
|
||||
One verb, two arguments. The recovered value is never printed and the stack trace arrives as {{%!(EXTRA string=...)}}.
|
||||
|
||||
h2. On-demand extended logging
|
||||
|
||||
How a service gets full detail in production without raising {{LOG_LEVEL}} and without paying for it on every healthy run. Every service handling a high-volume work item should implement it. {{gfiber-policy-executor}} is the reference:
|
||||
|
||||
{noformat}
|
||||
PUT /troubleshooting/{entityKey}?minutes=1440
|
||||
DELETE /troubleshooting/{entityKey}
|
||||
GET /troubleshooting/{entityKey}
|
||||
{noformat}
|
||||
|
||||
In code it is a guard around the verbose block, so the cost when off is one cached lookup:
|
||||
|
||||
{code:go}
|
||||
logging.LogInfoCtx(ctx, "Handling Full Pon Loss for alarm: %+v", alarm.toShortString())
|
||||
if m.IsAlarmTroubleshootingActive(ctx, alarm) {
|
||||
logging.LogInfoCtx(ctx, "Alarm (full): %+v", alarm.toFullString())
|
||||
}
|
||||
{code}
|
||||
|
||||
The default line carries a bounded projection; the full payload is behind the guard. Setup and the supported entity keys: [How to enable troubleshooting logs [gfiber-policy-executor]|https://bass.netcracker.com/pages/viewpage.action?pageId=2466165241].
|
||||
|
||||
h2. Logs are not the only channel
|
||||
|
||||
Choosing the right channel is most of the volume problem. A line that belongs in a metric should not be a log.
|
||||
|
||||
|| Channel || Answers || Cannot ||
|
||||
| Service log (Graylog) | what happened to this specific id | show trends, and it costs shared retention |
|
||||
| Prometheus metric | how often, how slow, alerting | carry an identifier; label cardinality forbids it |
|
||||
| BLM policy_actions_log | what we did to this item, on the record | be found from the SA Graylog streams |
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: gfiber-logging
|
||||
description: >-
|
||||
Decides the level of a log line in GFiber services and keeps INFO volume bounded.
|
||||
Use when writing or reviewing logging code, choosing between DEBUG, INFO, WARN and
|
||||
ERROR, adding observability to a service, judging whether a line belongs in a log or
|
||||
a metric, or auditing a service for log volume before a merge request.
|
||||
---
|
||||
|
||||
# GFiber Logging
|
||||
|
||||
Level policy and field conventions for log lines in GFiber services.
|
||||
|
||||
Canonical source: [How To: What logs belong at INFO, DEBUG, WARN and ERROR in GFiber services](https://bass.netcracker.com/display/GF/How+To%3A++What+logs+belongs+at+INFO%2C+DEBUG%2C+WARN+and+ERROR+in+GFiber+services). When this skill and the BASS page disagree, the page wins and this skill gets updated.
|
||||
|
||||
References: [references/levels.md](references/levels.md), [references/cases.md](references/cases.md), [references/anti-patterns.md](references/anti-patterns.md), [references/audit.md](references/audit.md).
|
||||
|
||||
## Hard rules
|
||||
|
||||
- **INFO is capped** — work received, work finished, one result per work item. Nothing else.
|
||||
- **No unbounded collection at INFO** — the count is INFO, the collection behind it is DEBUG.
|
||||
- **No INFO inside a loop** over alarms, ONTs, targets, services, tickets or messages. The per-item result line is the one legitimate exception.
|
||||
- **Cap identifier lists** at 50 entries followed by `+N more`.
|
||||
- **Always the `Ctx` variant** — `LogInfoCtx`, never `LogInfo`. The plain call drops `request_id` and every business identifier.
|
||||
- **Never a full request or response body at INFO** — log a projection; bodies go to DEBUG or behind on-demand troubleshooting.
|
||||
- **Mint correlation ids at ingress**, not deeper. An id created inside the handler cannot join the lines written before it.
|
||||
- **No secrets, tokens or customer PII** at any level.
|
||||
- **DEBUG is not present in production** — `LOG_LEVEL` is `INFO` in every shipped chart. A decision that must be explainable in production cannot live at DEBUG.
|
||||
|
||||
## Workflow: one log line
|
||||
|
||||
1. Walk the decision list in [references/levels.md](references/levels.md) and stop at the first yes.
|
||||
2. If the answer was INFO, confirm the line matches one of the four INFO cases. If it does not, it is DEBUG.
|
||||
3. Look the situation up in [references/cases.md](references/cases.md). Startup, scheduled ticks, Kafka, health probes and upstream calls all have a fixed answer there.
|
||||
4. Apply the field format from [references/levels.md](references/levels.md): `key=value`, snake_case, subject prefix, `%q` only for values that can be empty or contain spaces.
|
||||
5. Confirm the identifiers. On WARN and ERROR, add them only where no per-item result line will run for that work.
|
||||
|
||||
## Workflow: adding logging to a service
|
||||
|
||||
1. Read [references/cases.md](references/cases.md) and pick the reference implementation closest to the service shape (request handler, batch policy, scheduler, Kafka consumer).
|
||||
2. Run the static audit in [references/audit.md](references/audit.md) to record the starting numbers.
|
||||
3. Add the three INFO lines the policy expects, in this order, because each one is useless without the previous: work received, per-item result, batch summary.
|
||||
4. Add WARN on every branch that rejects or drops work, with a fixed reason vocabulary and a counter.
|
||||
5. Add ERROR on every branch that loses work after retries, carrying the identifiers and the step that stopped.
|
||||
6. Demote or delete what the audit flagged: collection dumps, per-object INFO, ticks that fire on a timer, lines whose whole content is already in the runtime prefix.
|
||||
7. Re-run the audit and report before and after.
|
||||
|
||||
## Workflow: reviewing a merge request
|
||||
|
||||
1. Apply the checklist in [references/audit.md](references/audit.md).
|
||||
2. Check the level of each added line against [references/cases.md](references/cases.md), not against how important the code feels.
|
||||
3. Scan for the known anti-patterns in [references/anti-patterns.md](references/anti-patterns.md). Pointer maps, bad verbs and silent rejections are the three that recur.
|
||||
4. If the change touches a high-volume path, require the volume gate table in the merge request description.
|
||||
|
||||
## Workflow: auditing a service for volume
|
||||
|
||||
1. Run the static audit script from [references/audit.md](references/audit.md) at the service checkout root.
|
||||
2. Exclude lines already behind an on-demand troubleshooting guard; the ungated count is the one that matters.
|
||||
3. Rank by `dump` and `loop` rather than by raw INFO count: a service with few INFO lines that all print collections is worse than one with many bounded lines.
|
||||
4. Measure the real numbers on a reference scenario per the volume gate, not only the static count.
|
||||
|
||||
## Choosing the channel
|
||||
|
||||
Most of the volume problem is picking the wrong channel. Full table in [references/levels.md](references/levels.md).
|
||||
|
||||
- "How often" or "how slow" is a **metric**, and it cannot carry an identifier.
|
||||
- "What happened to this specific id" is a **log**, and it costs shared retention.
|
||||
- "What did we do to this item, on the record" is a **BLM action log**, and it is not reachable from the SA Graylog streams.
|
||||
|
||||
## Safety
|
||||
|
||||
- **Read-only** — this skill reasons about code and proposes changes. It runs no mutation of its own.
|
||||
- Source trees under `sources/product/` are read-only; propose changes, never edit.
|
||||
- Sync sources with `gfiber-sources` before auditing a service.
|
||||
|
||||
## Related skills
|
||||
|
||||
| Skill | Role |
|
||||
|-------|------|
|
||||
| `gfiber-sources` | Clone or checkout the service before auditing it |
|
||||
| `gfiber-sa-troubleshooting` | Consumer of these logs; its Graylog searches are why identifiers must be literal |
|
||||
| `gfiber-svt-analysis` | Registered SVT cases used as the reference scenario for the volume gate |
|
||||
| `skills/_shared/code-reviewer` | General review pass; this skill covers the logging dimension only |
|
||||
@@ -0,0 +1,88 @@
|
||||
# Anti-patterns
|
||||
|
||||
Every example below shipped and passed review in a GFiber service. Check for these first when auditing.
|
||||
|
||||
## Printing a pointer instead of the data
|
||||
|
||||
```go
|
||||
logging.LogInfoCtx(ctx, "Valid alarms: %+v", validAlarms) // map[string]*Alarm
|
||||
logging.LogInfoCtx(ctx, "Alarm results: %+v", alarmResults) // map[string]*AlarmResult
|
||||
```
|
||||
|
||||
Go's `fmt` does not dereference pointers held inside a map or a slice, so what reaches Graylog is a map key and a heap address:
|
||||
|
||||
```
|
||||
Valid alarms: map[7c0e-1:0x7cabe66aa060]
|
||||
Alarm results: map[7c0e-1:0x7cabe66b4000]
|
||||
```
|
||||
|
||||
Print the identifiers, or a count. A struct or map of values prints fine; a map or slice of pointers does not.
|
||||
|
||||
## A verb that is not a verb
|
||||
|
||||
```go
|
||||
logging.LogDebug("... for alarm %s+", alarm) // *Alarm
|
||||
```
|
||||
|
||||
`%s+` is `%s` followed by a literal plus. On a struct with non-string fields `%s` emits error markers:
|
||||
|
||||
```
|
||||
&{7c0e-1 %!s(int=3) %!s(bool=false) 2026-09-02 11:52:06 ...}+
|
||||
```
|
||||
|
||||
Use `%+v`, or a short projection method such as `toShortString()`.
|
||||
|
||||
## INFO inside a per-object loop
|
||||
|
||||
```go
|
||||
for _, target := range targets {
|
||||
...
|
||||
logging.LogInfo("ONT target %s is not eligible for this ticket: %+v", ontId, target)
|
||||
}
|
||||
```
|
||||
|
||||
One INFO line per monitoring target, dumping the whole struct, where the logged branch is the normal outcome and not an exception. This scales with ONT count, not with request count. Log the members at DEBUG and one count after the loop.
|
||||
|
||||
## A tick that logs whether or not there is work
|
||||
|
||||
```go
|
||||
logging.LogInfoCtx(ctx, "Schedule ticket updates at %v", time.Now())
|
||||
```
|
||||
|
||||
Fired on every scheduler tick. With a five second interval that is roughly 17k INFO lines per day per pod with no work behind them. The tick belongs at DEBUG; the INFO line belongs after the batch, with counts.
|
||||
|
||||
## A rejection that returns in silence
|
||||
|
||||
A request rejected for capacity, for an unmatched handler or for a malformed body, returning a status code with no log line and no metric. Every identifier in that request is then absent from Graylog, and the request counter and the result counter diverge with nothing to explain the gap.
|
||||
|
||||
## A result line that never runs
|
||||
|
||||
An early return on a failure path that skips the per-item result loop. The batch is lost and leaves one line with no identifier in it. Populate the results on every exit path, or carry the identifiers on the ERROR.
|
||||
|
||||
Watch the status code when fixing this: in `gfiber-policy-executor` filling the results made a fully failed batch fall through the handler condition and answer HTTP 200, and the caller only inspects the status code, so it would have marked the work completed.
|
||||
|
||||
## Losing the panic value
|
||||
|
||||
```go
|
||||
logging.LogErrorCtx(ctx, "Unexpected panic: %v", reasonConstant, stackTrace)
|
||||
```
|
||||
|
||||
One verb, two arguments. The recovered value is never printed and the stack trace arrives as `%!(EXTRA string=...)`.
|
||||
|
||||
## A line whose whole content is already in the prefix
|
||||
|
||||
```go
|
||||
logging.LogInfoCtx(ctx, "x-request-id=%s", requestId)
|
||||
```
|
||||
|
||||
The runtime prefix already carries `request_id`. The line names no work item, so it costs volume and answers nothing. Replace it with a work-received line that names the ticket or alarm.
|
||||
|
||||
## Retry semantics inverted
|
||||
|
||||
Logging every retry attempt at WARN while the exhaustion, the moment the work actually moves to a backlog, is silent. The attempt is DEBUG, the exhaustion is ERROR with the identifier.
|
||||
|
||||
## Non-context logging
|
||||
|
||||
`logging.LogInfo` and friends without `Ctx` drop `request_id` and every business identifier from the MDC, which makes the line impossible to attach to anything.
|
||||
|
||||
If the enclosing function has no `ctx` and it is a pure helper, do not thread `ctx` through several signatures only to log. Either move the line to the caller, which has the context, or drop it: a DEBUG line that cannot be correlated is close to useless when two work items are in flight.
|
||||
@@ -0,0 +1,77 @@
|
||||
# Auditing a service and the volume gate
|
||||
|
||||
## Static audit
|
||||
|
||||
Run from the checkout root of any Go service under `sources/project/`. Heuristic, not a linter: it flags short projection methods such as `toShortString()` as dumps, and it does not know about on-demand troubleshooting guards. Read what it prints; do not treat the counts as a gate on their own.
|
||||
|
||||
```python
|
||||
import re, glob
|
||||
|
||||
files = [f for f in glob.glob('**/*.go', recursive=True)
|
||||
if not f.endswith('_test.go') and '/vendor/' not in f]
|
||||
info = dump = loop = noctx = 0
|
||||
for path in files:
|
||||
depth, loops = 0, []
|
||||
for i, line in enumerate(open(path, errors='ignore'), 1):
|
||||
stripped = line.strip()
|
||||
if re.search(r'\bfor .*\{\s*$', stripped):
|
||||
loops.append(depth)
|
||||
depth += line.count('{') - line.count('}')
|
||||
loops = [d for d in loops if d < depth]
|
||||
if re.search(r'logging\.Log(Info|Debug|Warning|Error|Fatal)\(', line):
|
||||
noctx += 1
|
||||
print(f'noCtx {path}:{i}: {stripped[:100]}')
|
||||
if re.search(r'logging\.LogInfo(Ctx)?\(', line):
|
||||
info += 1
|
||||
if '%+v' in line and not re.search(r'%\+v[^"]*"\s*,\s*len\(', line):
|
||||
dump += 1
|
||||
print(f'dump {path}:{i}: {stripped[:100]}')
|
||||
if loops:
|
||||
loop += 1
|
||||
print(f'loop {path}:{i}: {stripped[:100]}')
|
||||
print(f'INFO={info} dump={dump} loop={loop} noCtx={noctx}')
|
||||
```
|
||||
|
||||
To exclude lines already behind an on-demand troubleshooting guard, track the brace depth of the block opened by `IsAlarmTroubleshootingActive(` and skip lines while inside it. In `gfiber-policy-executor` that moved the count from 77 INFO sites to 34 ungated ones, which is the number that matters.
|
||||
|
||||
### How to read the output
|
||||
|
||||
| Signal | Meaning |
|
||||
|--------|---------|
|
||||
| high `dump` against low `INFO` | the few INFO lines the service has are the expensive kind |
|
||||
| any `loop` | a line scaling with item count rather than request count; the per-item result line is the one legitimate case |
|
||||
| `noCtx` | lines that cannot be attached to a work item |
|
||||
|
||||
## Volume gate
|
||||
|
||||
Any change to logging on a high-volume path states its volume impact in the merge request. Measure the same scenario before and after, in the same namespace and window, using the `graylog-search` entry in [scripts/data/index.yaml](../../../scripts/data/index.yaml) with `--scope containers` and a container plus level filter, per [scripts/data/graylog-search.example.md](../../../scripts/data/graylog-search.example.md).
|
||||
|
||||
Repeat for INFO, DEBUG, WARN and ERROR, then rerun on the branch build.
|
||||
|
||||
| Metric | Before | After | Delta |
|
||||
|--------|--------|-------|-------|
|
||||
| INFO messages per run | | | |
|
||||
| INFO bytes per run | | | |
|
||||
| DEBUG messages per run | | | |
|
||||
| WARN and ERROR per run | | | |
|
||||
| Longest single INFO line, bytes | | | |
|
||||
|
||||
Acceptance: INFO message count and INFO bytes must not increase. DEBUG is allowed to grow, since it is off in production.
|
||||
|
||||
For SA services use the registered SVT cases from [skills/gfiber-svt-analysis/cases/index.yaml](../../gfiber-svt-analysis/cases/index.yaml). Services without an SVT case need a reference scenario agreed with the reviewer before the gate means anything.
|
||||
|
||||
On the same run, confirm that a sample identifier from it is still findable at `LOG_LEVEL: INFO` with the SA alarm template from [queries/graylog/index.yaml](../../../queries/graylog/index.yaml). That is the regression the policy exists to prevent, and it is satisfied by the per-item result line rather than by anything new.
|
||||
|
||||
## Merge request checklist
|
||||
|
||||
The hard rules in [levels.md](levels.md) double as the review checklist. In addition:
|
||||
|
||||
- Every new INFO line matches one of the four INFO cases.
|
||||
- No new INFO line prints a collection, a struct or a body.
|
||||
- No new INFO line sits inside a loop over domain objects.
|
||||
- Every identifier list is capped.
|
||||
- Every call is the `Ctx` variant.
|
||||
- WARN and ERROR on failure paths carry the identifiers of the work they lost.
|
||||
- The summary line is written from a `defer` that survives a panic.
|
||||
- New metric labels come from a fixed vocabulary, with no identifiers in them.
|
||||
- `go vet` is clean and no line prints a pointer address or a `%!s` marker.
|
||||
@@ -0,0 +1,73 @@
|
||||
# Case catalogue
|
||||
|
||||
The cases that come up in GFiber services and the level each one takes. If a case is not here, run the decision list in [levels.md](levels.md) and add a row.
|
||||
|
||||
## Work intake and results
|
||||
|
||||
| Case | Level | Note |
|
||||
|------|-------|------|
|
||||
| Request, batch or message arrived | INFO | counts and the values that identify the scope, such as alarm names, severities, OLT, HUT; no payload and no id list |
|
||||
| Batch finished | INFO if ok, ERROR otherwise | one summary line with in, out, duration and status, written from a defer registered before any recover so a panic still produces it |
|
||||
| Result of one work item | INFO | one per item, with its identifier and outcome; this is the line support greps for, and the one line that must never be demoted |
|
||||
| Payload of the work item | DEBUG | or behind on-demand troubleshooting |
|
||||
| Decision that ends the item | INFO | only when it is not already visible in that item's result message |
|
||||
| Intermediate lookup or filter result | DEBUG | log the count at INFO if it matters, the members at DEBUG |
|
||||
| Anything inside a loop over domain objects | DEBUG | plus one count after the loop |
|
||||
|
||||
## Rejections and failures
|
||||
|
||||
| Case | Level | Note |
|
||||
|------|-------|------|
|
||||
| Input malformed, null or failed validation | WARN | carry the identifiers that survived parsing, and the body size |
|
||||
| Rejected for capacity or backpressure | WARN | one line per rejected request, never per item |
|
||||
| No handler or policy matched the work | WARN | carry the identifiers, because no result line will be written |
|
||||
| Upstream call failed, will be retried | DEBUG | the attempt is not yet a failure |
|
||||
| Upstream call failed after retries | ERROR | carry the identifiers and the step that stopped |
|
||||
| Some items succeeded, some failed | ERROR | on the summary line, with the split |
|
||||
| Panic recovered | ERROR | log the recovered value and the stack, and keep serving |
|
||||
|
||||
## Service lifecycle
|
||||
|
||||
| Case | Level | Note |
|
||||
|------|-------|------|
|
||||
| Started, listeners bound, dependencies resolved | INFO | a handful of lines, once per process |
|
||||
| Effective configuration | DEBUG | never secrets, tokens or credentials |
|
||||
| Graceful shutdown | INFO | |
|
||||
| Cannot start at all | FATAL | the only place FATAL is allowed |
|
||||
| Database connection established | INFO | once at startup; per query is DEBUG |
|
||||
|
||||
## Background work
|
||||
|
||||
| Case | Level | Note |
|
||||
|------|-------|------|
|
||||
| Scheduled tick that found nothing to do | DEBUG | a tick every few seconds at INFO is one of the cheapest ways to burn retention |
|
||||
| Scheduled tick that did work | INFO | one line with counts, not one per item |
|
||||
| Kafka batch consumed | INFO | one summary per batch, same shape as an HTTP batch |
|
||||
| One Kafka message processed | DEBUG | the per-item result line already covers what support needs |
|
||||
| Message that cannot be parsed | ERROR | carry the message key and raise a metric; it will never parse, so it is lost work |
|
||||
| Consumer rebalance or lag | none | leave it to the client library and to metrics |
|
||||
|
||||
## Keep out
|
||||
|
||||
| Case | Level | Note |
|
||||
|------|-------|------|
|
||||
| Health, liveness and readiness probes | none on success | probe traffic is constant; log only a failing probe |
|
||||
| Every outbound HTTP request and response | DEBUG | rates and durations belong in metrics |
|
||||
| Upstream returned an empty result | DEBUG | unless it changes the outcome, and then it belongs in the item's result message |
|
||||
| Third-party library output | set it explicitly | do not let a dependency inherit DEBUG in production |
|
||||
| Secrets, tokens, passwords | never | at any level |
|
||||
| ONT serial, account id, hostname | not at INFO | on high-volume paths; fine in a bounded projection or at DEBUG |
|
||||
|
||||
If a line has to be INFO and is still too frequent, sample it: log one in N with the count of what was skipped. Demoting it to DEBUG removes it from production entirely, which is usually not the intent.
|
||||
|
||||
## Reference implementations
|
||||
|
||||
Read these before writing a new one; both were reviewed against this policy.
|
||||
|
||||
| What | Where |
|
||||
|------|-------|
|
||||
| Per-batch summary line, `key=value`, INFO on ok and ERROR otherwise | `gfiber-policy-executor`, `pkg/faultstatus/stats.go` |
|
||||
| Per-alarm result line, the one support greps for | `gfiber-policy-executor`, `pkg/policies/executor.go` |
|
||||
| Ingress line with counts, ids on a DEBUG companion | `gfiber-policy-executor`, `pkg/policies/executor.go` |
|
||||
| Per-item result line from a defer, covering every failure path | `gfiber-ticketing-proxy`, `pkg/ticket/executor.go` |
|
||||
| Rejection lines with a fixed reason vocabulary plus a counter | `gfiber-ticketing-proxy`, `pkg/ticket/routes.go` |
|
||||
@@ -0,0 +1,112 @@
|
||||
# Levels and the decision list
|
||||
|
||||
Canonical source: [How To: What logs belong at INFO, DEBUG, WARN and ERROR in GFiber services](https://bass.netcracker.com/display/GF/How+To%3A++What+logs+belongs+at+INFO%2C+DEBUG%2C+WARN+and+ERROR+in+GFiber+services). This file is the working copy for agents; when the two disagree, the BASS page wins.
|
||||
|
||||
## Why there is a ceiling on INFO
|
||||
|
||||
Graylog storage is shared across the platform. Every INFO line written on a healthy run is paid for in retention days, so the more a service logs, the shorter the window for grepping an incident that already happened. A service that logs too little is untriageable. The policy is the line between the two.
|
||||
|
||||
Three facts that drive every rule below:
|
||||
|
||||
- `LOG_LEVEL` is `INFO` in every shipped Helm chart. Treat DEBUG as not present in production.
|
||||
- Support starts from one identifier, usually an alarm id or a ticket id, and searches Graylog full text. A decision that never printed that identifier cannot be found.
|
||||
- Batch sizes are not capped upstream. A line inside a loop scales with item count, not with request count.
|
||||
|
||||
## Levels
|
||||
|
||||
| Level | Use for | Volume on a healthy run |
|
||||
|-------|---------|-------------------------|
|
||||
| ERROR | Work was lost and a human must look. Carries the identifiers of the lost work. | rare, each one actionable |
|
||||
| WARN | An item was dropped or degraded and the service continues. Carries identifiers when no result line will be written. | rare |
|
||||
| INFO | Work received, work finished, one result per work item. | O(1) per request or batch, plus one line per item |
|
||||
| DEBUG | Everything else: intermediate collections, per-object detail, payloads, filter internals. | unbounded |
|
||||
| FATAL | Cannot start and serve. Terminates the process. | startup only |
|
||||
|
||||
`mano.netcracker.com/go-logging/v3` exposes `LogDebug`, `LogInfo`, `LogWarning`, `LogError`, `LogFatal` and a `Ctx` variant of each. There is no TRACE.
|
||||
|
||||
## Decision list
|
||||
|
||||
Walk in order, stop at the first yes.
|
||||
|
||||
1. Work was lost and someone has to look at it. Use ERROR.
|
||||
2. An item was dropped or degraded, and the service keeps going. Use WARN.
|
||||
3. It is one of these four: work received, work finished, the result of one item, or a decision that ends an item and is not already in that item's result message. Use INFO.
|
||||
4. It fires more than once per item, or prints a collection, a struct or a body. Use DEBUG.
|
||||
5. Anything else. Use DEBUG.
|
||||
|
||||
When two levels look defensible, take the lower one. A line at DEBUG can be recovered with on-demand troubleshooting or promoted next release. Retention days spent on a line nobody reads cannot.
|
||||
|
||||
## WARN or ERROR
|
||||
|
||||
The boundary that gets argued about most.
|
||||
|
||||
- ERROR means the service could not do what it was asked and no automatic mechanism will fix it. A human has to look.
|
||||
- WARN means the service did not do something, but that outcome is defined and expected in operation: input was unusable, capacity was full, a business rule dropped the item.
|
||||
|
||||
The test: if this fires two hundred times tonight, does someone need to be paged? Yes is ERROR. No is WARN.
|
||||
|
||||
Two consequences, both commonly got wrong:
|
||||
|
||||
- A call that failed but will be retried automatically is not an ERROR on the attempt. The attempt is DEBUG. It becomes ERROR when the retries are exhausted and the work is actually lost.
|
||||
- A validation rejection is never an ERROR, however loud it looks. The client sent something unusable and the service behaved correctly. That is WARN.
|
||||
|
||||
## FATAL
|
||||
|
||||
Startup only, and only when the process cannot serve at all: unreadable configuration, no database, a required dependency that will never appear. `LogFatal` terminates the process, so calling it on a request path turns one bad request into an outage. There is no case for FATAL after the service reports ready.
|
||||
|
||||
## Field format
|
||||
|
||||
`key=value` pairs, snake_case keys, prefixed by the subject of the line. Quote with `%q` only when the value can be empty or contain spaces.
|
||||
|
||||
```go
|
||||
logging.LogInfoCtx(ctx, "policy batch received: batch_id=%s policy=%q alarms=%d alarm_names=%s",
|
||||
batchID, request.Policy, len(request.Alarms), distinctAlarmNames(request.Alarms))
|
||||
```
|
||||
|
||||
The runtime already adds a prefix, so do not repeat any of it in the message:
|
||||
|
||||
```
|
||||
[2026-09-02T11:52:06.222] [INFO] [request_id=-] [tenant_id=-] [thread=-] [class=policies:executor.go:68] <your message>
|
||||
```
|
||||
|
||||
### Correlation keys
|
||||
|
||||
| Key | Source | Present on |
|
||||
|-----|--------|-----------|
|
||||
| `request_id` | MDC, from the cloud-core context propagation middleware | every line, automatically |
|
||||
| `batch_id` | minted once at ingress, carried in the context | every line handling that batch |
|
||||
| `alarm_id`, `ticket_id`, `order_id` | the domain object | every line naming a single work item |
|
||||
| `alarm_ids` | capped list | lines describing a set |
|
||||
|
||||
This is not structured logging. The logger emits a text message behind a fixed prefix, so Graylog does not extract these keys into searchable fields. They are found by full text search, which is exactly why identifiers have to appear literally in the message.
|
||||
|
||||
## On-demand extended logging
|
||||
|
||||
How a service gets full detail in production without raising `LOG_LEVEL` and without paying for it on every healthy run. Every service handling a high-volume work item should implement it. `gfiber-policy-executor` is the reference:
|
||||
|
||||
```
|
||||
PUT /troubleshooting/{entityKey}?minutes=1440
|
||||
DELETE /troubleshooting/{entityKey}
|
||||
GET /troubleshooting/{entityKey}
|
||||
```
|
||||
|
||||
In code it is a guard around the verbose block, so the cost when off is one cached lookup:
|
||||
|
||||
```go
|
||||
logging.LogInfoCtx(ctx, "Handling Full Pon Loss for alarm: %+v", alarm.toShortString())
|
||||
if m.IsAlarmTroubleshootingActive(ctx, alarm) {
|
||||
logging.LogInfoCtx(ctx, "Alarm (full): %+v", alarm.toFullString())
|
||||
}
|
||||
```
|
||||
|
||||
The default line carries a bounded projection; the full payload is behind the guard. Setup and supported entity keys: [How to enable troubleshooting logs (gfiber-policy-executor)](https://bass.netcracker.com/pages/viewpage.action?pageId=2466165241).
|
||||
|
||||
## Logs are not the only channel
|
||||
|
||||
Choosing the right channel is most of the volume problem.
|
||||
|
||||
| Channel | Answers | Cannot |
|
||||
|---------|---------|--------|
|
||||
| Service log (Graylog) | what happened to this specific id | show trends, and it costs shared retention |
|
||||
| Prometheus metric | how often, how slow, alerting | carry an identifier; label cardinality forbids it |
|
||||
| BLM `policy_actions_log` | what we did to this item, on the record | be found from the SA Graylog streams |
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: marcos-silva-skills
|
||||
description: Index for Marcos Silva's submitted Confluence + documentation skill set.
|
||||
type: index
|
||||
---
|
||||
|
||||
# Marcos Silva — Submitted Skills
|
||||
|
||||
Tooling for creating, reviewing, and publishing Confluence pages in the Netcracker
|
||||
BASS / AVP spaces, focused on `mcp-atlassian`, PlantUML diagrams, and pre-post
|
||||
review.
|
||||
|
||||
## Skills
|
||||
|
||||
| Skill | Job | When to invoke |
|
||||
|-------|-----|----------------|
|
||||
| [confluence-page](skills/confluence-page/SKILL.md) | Create or update a Confluence page from a local storage-format draft via mcp-atlassian | Drafting a page, scaffolding from a template, mirroring content into a space |
|
||||
| [page-reviewer](skills/page-reviewer/SKILL.md) | Audit a Confluence-ready body before it is posted | Just before `confluence_create_page_from_file` or `confluence_update_page_from_file` |
|
||||
| [unslop](skills/unslop/SKILL.md) | Strip AI slop from prose before posting | After drafting, before review |
|
||||
| [diagram-plantuml](skills/diagram-plantuml/SKILL.md) | Embed PlantUML correctly inside a Confluence page | Page needs a sequence, component, class, state, or activity diagram |
|
||||
|
||||
## Scripts
|
||||
|
||||
| Script | Purpose |
|
||||
|--------|---------|
|
||||
| [scripts/check-mcp-atlassian.sh](scripts/check-mcp-atlassian.sh) | Detect whether `mcp-atlassian` is wired up; print install hint if not |
|
||||
| [scripts/new-page.sh](scripts/new-page.sh) | Scaffold a new page from a template into a draft folder |
|
||||
| [scripts/dry-run-publish.sh](scripts/dry-run-publish.sh) | Pre-flight the page body (lint, slop-check, lint diagrams) without posting |
|
||||
|
||||
## Templates
|
||||
|
||||
See [templates/](templates/) for ready-to-fill body templates:
|
||||
|
||||
- `hub-page.md` — overview / landing pages
|
||||
- `how-to.md` — step-by-step runbook
|
||||
- `rfc.md` — request for comment
|
||||
- `postmortem.md` — incident write-up
|
||||
|
||||
## Conventions
|
||||
|
||||
Mirrors in `~/Netcracker/Projects/NDO/knowledge/confluence/<SPACE>/` are
|
||||
read-only local copies. Edit upstream, then re-pull — never patch the mirror
|
||||
body in place. Skill bodies in this folder are the working copy for agents;
|
||||
when a skill and the upstream page disagree, the upstream page wins and the
|
||||
skill gets updated.
|
||||
|
||||
## References
|
||||
|
||||
- BASS Confluence — https://bass.netcracker.com
|
||||
- mcp-atlassian upstream — https://github.com/sooperset/mcp-atlassian
|
||||
- NDO knowledge base — `~/Netcracker/Projects/NDO/knowledge/`
|
||||
- Cursor MCP approval status (governance) — see `BASS/cursor-mcps-approval-status.md`
|
||||
@@ -0,0 +1,111 @@
|
||||
#!/usr/bin/env bash
|
||||
# check-mcp-atlassian.sh
|
||||
# Detect whether mcp-atlassian is wired into the active Claude / Cursor client.
|
||||
# Prints PASS / MISSING with the install path that fits the current client.
|
||||
#
|
||||
# Usage: bash scripts/check-mcp-atlassian.sh
|
||||
# Exit: 0 if installed, 1 if missing, 2 if check was inconclusive.
|
||||
|
||||
set -u
|
||||
|
||||
FOUND=0
|
||||
DETAILS=""
|
||||
|
||||
# 1. The MCP server name shows up in the running client's config.
|
||||
CANDIDATE_CONFIGS=(
|
||||
"$HOME/.claude/settings.json"
|
||||
"$HOME/.cursor/mcp.json"
|
||||
"$HOME/.codex/config.yaml"
|
||||
"$HOME/.claude.json"
|
||||
"$(pwd)/.mcp.json"
|
||||
)
|
||||
|
||||
for cfg in "${CANDIDATE_CONFIGS[@]}"; do
|
||||
if [[ -f "$cfg" ]]; then
|
||||
if grep -qiE "mcp-atlassian|sooperset/mcp-atlassian" "$cfg" 2>/dev/null; then
|
||||
FOUND=1
|
||||
DETAILS="$cfg"
|
||||
break
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
# 2. Active client processes. If the MCP is loaded we usually see a node / uv
|
||||
# process with the server's name in argv.
|
||||
if [[ $FOUND -eq 0 ]]; then
|
||||
if command -v ps >/dev/null 2>&1; then
|
||||
if ps -ef 2>/dev/null | grep -qiE "mcp-atlassian|sooperset.*atlassian"; then
|
||||
FOUND=1
|
||||
DETAILS="(running process)"
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
# 3. npx cache. If installed globally, it lands here.
|
||||
if [[ $FOUND -eq 0 ]]; then
|
||||
if [[ -d "$HOME/.npm/_npx" ]] && find "$HOME/.npm/_npx" -type d -name "*atlassian*" 2>/dev/null | grep -q .; then
|
||||
FOUND=1
|
||||
DETAILS="(npx cache)"
|
||||
fi
|
||||
fi
|
||||
|
||||
if [[ $FOUND -eq 1 ]]; then
|
||||
echo "PASS: mcp-atlassian detected in ${DETAILS:-unknown location}"
|
||||
echo
|
||||
echo "Verify the active client can see it:"
|
||||
echo " - Claude Code : restart the session, then list /mcp"
|
||||
echo " - Cursor : Cursor > Settings > MCP, look for 'mcp-atlassian'"
|
||||
echo " - Codex CLI : /mcp list"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
cat <<'EOF'
|
||||
MISSING: mcp-atlassian is not wired into the active Claude / Cursor client.
|
||||
|
||||
The Confluence + Jira tools you need are exposed by this MCP server:
|
||||
https://github.com/sooperset/mcp-atlassian
|
||||
|
||||
Install path depends on the client in use:
|
||||
|
||||
Claude Code
|
||||
claude mcp add atlassian \
|
||||
-e CONFLUENCE_URL=https://bass.netcracker.com \
|
||||
-e CONFLUENCE_USERNAME=<your-username> \
|
||||
-e CONFLUENCE_API_TOKEN=<your-token> \
|
||||
-- npx -y mcp-atlassian
|
||||
# Add JIRA_* envs for Jira access too.
|
||||
|
||||
Cursor (project-level .mcp.json)
|
||||
{
|
||||
"mcpServers": {
|
||||
"atlassian": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "mcp-atlassian"],
|
||||
"env": {
|
||||
"CONFLUENCE_URL": "https://bass.netcracker.com",
|
||||
"CONFLUENCE_USERNAME": "<your-username>",
|
||||
"CONFLUENCE_API_TOKEN": "<your-token>"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Codex CLI
|
||||
Add to ~/.codex/config.yaml:
|
||||
mcp_servers:
|
||||
atlassian:
|
||||
command: npx
|
||||
args: ["-y", "mcp-atlassian"]
|
||||
env:
|
||||
CONFLUENCE_URL: https://bass.netcracker.com
|
||||
CONFLUENCE_USERNAME: <your-username>
|
||||
CONFLUENCE_API_TOKEN: <your-token>
|
||||
|
||||
Approval note: the BASS "Cursor MCPs approval status" page lists mcp-atlassian
|
||||
as "Not approved" by default. Check the current row before relying on it for
|
||||
governed spaces; if governance has not approved it yet, your post will land
|
||||
but the space admin may revert the page.
|
||||
|
||||
After install: restart the client, then re-run this script.
|
||||
EOF
|
||||
exit 1
|
||||
+151
@@ -0,0 +1,151 @@
|
||||
#!/usr/bin/env bash
|
||||
# dry-run-publish.sh
|
||||
# Pre-flight a Confluence storage body before posting. Runs:
|
||||
# - format sanity (storage XHTML, no wiki markup, no markdown fences)
|
||||
# - secret / PII grep (BLOCKER)
|
||||
# - macro sanity (every {code} / {plantuml} / panel is in storage form)
|
||||
# - PlantUML parse (if plantuml on $PATH)
|
||||
# - size sanity (over 300 lines needs justification header)
|
||||
#
|
||||
# Usage:
|
||||
# bash scripts/dry-run-publish.sh <draft.xml>
|
||||
#
|
||||
# Exit codes:
|
||||
# 0 = ready to post
|
||||
# 1 = REVISE (MAJOR or MINOR issues found)
|
||||
# 2 = BLOCK (BLOCKER issues found)
|
||||
|
||||
set -u
|
||||
|
||||
if [[ $# -lt 1 ]]; then
|
||||
echo "Usage: $0 <draft.xml>" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
DRAFT="$1"
|
||||
|
||||
if [[ ! -f "$DRAFT" ]]; then
|
||||
echo "Draft not found: $DRAFT" >&2
|
||||
exit 2
|
||||
fi
|
||||
|
||||
BLOCK=0
|
||||
MAJOR=0
|
||||
MINOR=0
|
||||
|
||||
note_block() { echo " [BLOCK] $1"; BLOCK=1; }
|
||||
note_major() { echo " [MAJOR] $1"; MAJOR=1; }
|
||||
note_minor() { echo " [MINOR] $1"; MINOR=1; }
|
||||
|
||||
echo "Pre-flight: $DRAFT"
|
||||
echo "------------------------------------"
|
||||
|
||||
# 1. Format sanity
|
||||
if head -3 "$DRAFT" | grep -q '^---$'; then
|
||||
note_block "Markdown front-matter detected -- storage body must not contain --- fences."
|
||||
fi
|
||||
|
||||
if grep -qE '\{code:' "$DRAFT"; then
|
||||
note_major "Wiki code-block syntax detected. Use <ac:structured-macro ac:name=\"code\">."
|
||||
fi
|
||||
if grep -qE '\{info:' "$DRAFT" || grep -qE '\{note:' "$DRAFT" || grep -qE '\{warning:' "$DRAFT"; then
|
||||
note_major "Wiki panel syntax detected. Use <ac:structured-macro ac:name=\"info|note|warning\">."
|
||||
fi
|
||||
if grep -qE '\{plantuml' "$DRAFT"; then
|
||||
if ! grep -qE '<ac:structured-macro ac:name="plantuml"' "$DRAFT"; then
|
||||
note_major "{plantuml} found but not wrapped in <ac:structured-macro ac:name=\"plantuml\">."
|
||||
fi
|
||||
fi
|
||||
|
||||
if grep -qE '^#{1,6} ' "$DRAFT"; then
|
||||
note_major "Markdown heading detected (# / ## / ###). Use <h1> / <h2> / <h3>."
|
||||
fi
|
||||
if grep -qE '^[[:space:]]*```' "$DRAFT"; then
|
||||
note_major "Markdown code fence (\`\`\`) detected. Use <ac:structured-macro ac:name=\"code\">."
|
||||
fi
|
||||
|
||||
# 2. Secrets / PII
|
||||
SECRET_PATTERNS=(
|
||||
'AKIA[0-9A-Z]{16}'
|
||||
'ghp_[A-Za-z0-9]{30,}'
|
||||
'glpat-[A-Za-z0-9_-]{20,}'
|
||||
'xox[baprs]-[A-Za-z0-9-]{10,}'
|
||||
'sk-[A-Za-z0-9]{40,}'
|
||||
'ATATT[A-Za-z0-9]{30,}'
|
||||
'-----BEGIN [A-Z ]+PRIVATE KEY-----'
|
||||
)
|
||||
|
||||
for pat in "${SECRET_PATTERNS[@]}"; do
|
||||
if grep -qE "$pat" "$DRAFT" 2>/dev/null; then
|
||||
note_block "Secret pattern matched: $pat -- scrub before posting."
|
||||
fi
|
||||
done
|
||||
|
||||
if grep -qE "Netcracker/Projects/NDO/knowledge" "$DRAFT"; then
|
||||
note_block "Body references the local mirror path. Use the public BASS URL."
|
||||
fi
|
||||
|
||||
# 3. Macro sanity
|
||||
PLANTUML_COUNT=$(grep -cE '<ac:structured-macro ac:name="plantuml"' "$DRAFT" || true)
|
||||
PLANTUML_COUNT=$(printf '%d' "${PLANTUML_COUNT:-0}" 2>/dev/null || echo 0)
|
||||
CODE_COUNT=$(grep -cE '<ac:structured-macro ac:name="code"' "$DRAFT" || true)
|
||||
CODE_COUNT=$(printf '%d' "${CODE_COUNT:-0}" 2>/dev/null || echo 0)
|
||||
|
||||
if [[ $PLANTUML_COUNT -gt 0 ]]; then
|
||||
if grep -B2 'ac:name="plantuml"' "$DRAFT" | grep -qE '<ac:structured-macro ac:name="(info|note|warning|tip|code)"'; then
|
||||
note_major "PlantUML macro appears inside a panel or code block. Move to body root."
|
||||
fi
|
||||
fi
|
||||
|
||||
if [[ $CODE_COUNT -gt 0 ]]; then
|
||||
if ! grep -q 'ac:parameter ac:name="language"' "$DRAFT"; then
|
||||
note_major "{code} block has no language parameter."
|
||||
fi
|
||||
fi
|
||||
|
||||
if [[ $PLANTUML_COUNT -gt 0 ]] && command -v plantuml >/dev/null 2>&1; then
|
||||
TMPDIR_PRE=$(mktemp -d)
|
||||
awk '
|
||||
/<ac:structured-macro ac:name="plantuml"/{flag=1; next}
|
||||
/<\/ac:structured-macro>/{flag=0}
|
||||
flag && /<ac:plain-text-body><!\[CDATA\[/{capture=1; next}
|
||||
flag && capture && /\]\]><\/ac:plain-text-body>/{capture=0; next}
|
||||
flag && capture{print}
|
||||
' "$DRAFT" > "$TMPDIR_PRE/all.puml"
|
||||
if [[ -s "$TMPDIR_PRE/all.puml" ]]; then
|
||||
if ! plantuml -tpng -checkonly -failfast2 "$TMPDIR_PRE/all.puml" >/dev/null 2>&1; then
|
||||
note_major "PlantUML syntax check failed. Run plantuml -tpng locally on the extracted body."
|
||||
fi
|
||||
fi
|
||||
rm -rf "$TMPDIR_PRE"
|
||||
fi
|
||||
|
||||
# 4. Size
|
||||
LINES=$(wc -l < "$DRAFT")
|
||||
if [[ $LINES -gt 300 ]]; then
|
||||
if ! head -5 "$DRAFT" | grep -qiE 'justify|long|expanded'; then
|
||||
note_major "Body is $LINES lines (>300) and no justification header is present."
|
||||
fi
|
||||
fi
|
||||
|
||||
# 5. Image alt text
|
||||
if grep -qE '<ac:image' "$DRAFT"; then
|
||||
if ! grep -q 'ac:alt' "$DRAFT"; then
|
||||
note_major "<ac:image> without ac:alt."
|
||||
fi
|
||||
fi
|
||||
|
||||
echo "------------------------------------"
|
||||
if [[ $BLOCK -eq 1 ]]; then
|
||||
echo "BLOCK -- secret, format, or path issue. Fix and re-run."
|
||||
exit 2
|
||||
elif [[ $MAJOR -eq 1 ]]; then
|
||||
echo "REVISE -- major issues found. Fix and re-run."
|
||||
exit 1
|
||||
elif [[ $MINOR -eq 1 ]]; then
|
||||
echo "PASS (with minor notes) -- ready to post."
|
||||
exit 0
|
||||
else
|
||||
echo "PASS -- ready to post."
|
||||
exit 0
|
||||
fi
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
#!/usr/bin/env bash
|
||||
# new-page.sh
|
||||
# Scaffold a new Confluence page draft from a template into the local drafts
|
||||
# folder. The draft is storage-format XHTML, ready to fill and post.
|
||||
#
|
||||
# Usage:
|
||||
# bash scripts/new-page.sh <space> <title> [template]
|
||||
# space : AVP, BASS, etc. (see confluence-page/references/space-keys.md)
|
||||
# title : Page title; spaces become + in the storage path
|
||||
# template : hub | how-to | rfc | postmortem (default: hub)
|
||||
#
|
||||
# Writes to:
|
||||
# ~/Netcracker/Projects/NDO/knowledge/confluence/drafts/<SPACE>/<slug>.xml
|
||||
#
|
||||
# Exit: 0 on success, 1 on bad args, 2 on missing template.
|
||||
|
||||
set -eu
|
||||
|
||||
if [[ $# -lt 2 ]]; then
|
||||
echo "Usage: $0 <space> <title> [template]" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
SPACE="$(echo "$1" | tr '[:lower:]' '[:upper:]')"
|
||||
TITLE="$2"
|
||||
TEMPLATE="${3:-hub}"
|
||||
|
||||
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
|
||||
ROOT="$(dirname "$SCRIPT_DIR")"
|
||||
TEMPLATE_FILE="$ROOT/templates/${TEMPLATE}.md"
|
||||
|
||||
if [[ ! -f "$TEMPLATE_FILE" ]]; then
|
||||
echo "Template not found: $TEMPLATE_FILE" >&2
|
||||
echo "Available templates:" >&2
|
||||
ls "$ROOT/templates" 2>/dev/null | sed 's/\.md$//' | sed 's/^/ - /' >&2
|
||||
exit 2
|
||||
fi
|
||||
|
||||
DRAFT_ROOT="${DRAFT_ROOT:-$HOME/Netcracker/Projects/NDO/knowledge/confluence/drafts}"
|
||||
DRAFT_DIR="$DRAFT_ROOT/$SPACE"
|
||||
mkdir -p "$DRAFT_DIR"
|
||||
|
||||
SLUG="$(echo "$TITLE" | tr '[:upper:]' '[:lower:]' | tr ' /' '--' | tr -cd 'a-z0-9-_')"
|
||||
DRAFT_FILE="$DRAFT_DIR/${SLUG}.xml"
|
||||
|
||||
{
|
||||
echo '<?xml version="1.0" encoding="UTF-8"?>'
|
||||
echo "<page xmlns:ac=\"http://atlassian.com/content\" xmlns:ri=\"http://atlassian.com/resource/identifier\">"
|
||||
echo " <title>$TITLE</title>"
|
||||
echo " <space>$SPACE</space>"
|
||||
echo " <body>"
|
||||
echo " <h1>$TITLE</h1>"
|
||||
echo " <p><em>Drafted $(date -u +%Y-%m-%d). Edit the body below this line; the title and space are set above.</em></p>"
|
||||
echo ""
|
||||
echo "<!--"
|
||||
cat "$TEMPLATE_FILE"
|
||||
echo ""
|
||||
echo "-->"
|
||||
echo ""
|
||||
echo " <p>Body starts here.</p>"
|
||||
echo ""
|
||||
echo " </body>"
|
||||
echo "</page>"
|
||||
} > "$DRAFT_FILE"
|
||||
|
||||
echo "Draft created: $DRAFT_FILE"
|
||||
echo "Space: $SPACE"
|
||||
echo "Title: $TITLE"
|
||||
echo "Template: $TEMPLATE"
|
||||
echo
|
||||
echo "Next:"
|
||||
echo " 1. Fill the body between <body> and </body> using storage XHTML."
|
||||
echo " 2. Run bash $SCRIPT_DIR/dry-run-publish.sh \"$DRAFT_FILE\""
|
||||
echo " 3. Post via mcp-atlassian: confluence_create_page_from_file."
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
name: confluence-page
|
||||
description: Create or update a Confluence page on BASS from a local storage-format draft, using mcp-atlassian. Use when scaffolding a new page in AVP or BASS, mirroring a doc into a space, or updating an existing page by id or by space+title.
|
||||
---
|
||||
|
||||
# Confluence Page
|
||||
|
||||
Draft a page in storage format locally, lint it, then post or update it via
|
||||
`mcp-atlassian`. The skill never edits a page in place without a draft file on
|
||||
disk and a pre-flight pass.
|
||||
|
||||
Canonical source: [BASS Confluence](https://bass.netcracker.com). When the
|
||||
skill and a BASS page disagree, BASS wins and this skill gets updated.
|
||||
|
||||
## Hard rules
|
||||
|
||||
- **Storage format, not wiki markdown.** Confluence Cloud expects the
|
||||
`body.storage` representation. Wiki markup only renders correctly when the
|
||||
page's renderer is configured for it; do not assume.
|
||||
- **No secrets, tokens, customer PII, or session cookies** in any body.
|
||||
`references/secrets.md` lists the patterns to scrub.
|
||||
- **Title is unique within the parent** — verify with `confluence_search` or
|
||||
`confluence_get_page(spaceKey, title)` before creating.
|
||||
- **PlantUML goes through the `{plantuml}` macro** at body root, never inside
|
||||
an info panel or a code block — see `diagram-plantuml` skill.
|
||||
- **Attachments go through the attachments API**, not as base64 in the body.
|
||||
See `references/attachments.md`.
|
||||
- **One page per draft file.** Don't stuff multiple pages into one storage file;
|
||||
split before posting.
|
||||
|
||||
## Workflow: new page
|
||||
|
||||
1. Pick a template from `templates/` and copy it to a scratch file under
|
||||
`~/Netcracker/Projects/NDO/knowledge/confluence/drafts/<SPACE>/<slug>.xml`
|
||||
(`<SPACE>` is the space key, e.g. `AVP`, `BASS`).
|
||||
2. Decide the parent. Default parent is the space home for top-level pages.
|
||||
Use `confluence_search` to find the parent id when nesting.
|
||||
3. Fill the body. Storage format uses standard XHTML; the only macros that
|
||||
survive the round trip are listed in `references/macros.md`.
|
||||
4. Run `scripts/dry-run-publish.sh <draft>` — it lints the body, runs the
|
||||
`unslop` pass, and verifies every `{plantuml}` block parses.
|
||||
5. `mcp__atlassian.confluence_create_page(spaceKey, title, storageFilePath,
|
||||
parentId?)` to post. The MCP tool reads the file directly; never paste the
|
||||
body into the call.
|
||||
6. Capture the new page id in `~/Netcracker/Projects/NDO/knowledge/confluence/_index.md`
|
||||
so it appears in the local mirror index.
|
||||
|
||||
## Workflow: update existing page
|
||||
|
||||
1. Resolve the page id. `confluence_get_page(spaceKey, title)` if you know the
|
||||
title, otherwise `confluence_search(cql="title=\"…\"")`.
|
||||
2. Fetch the current storage body with `confluence_get_page_content(pageId)`
|
||||
and save it next to your draft under
|
||||
`confluence/drafts/<SPACE>/<slug>.from-server.xml`. This is your safety net.
|
||||
3. Diff your draft against the server copy. If a section was renamed upstream
|
||||
but is still wanted locally, carry the change forward; if it was deleted,
|
||||
drop it.
|
||||
4. Run `scripts/dry-run-publish.sh <draft>`.
|
||||
5. `mcp__atlassian.confluence_update_page_from_file(pageId, storageFilePath,
|
||||
title?, minorEdit=true, versionMessage="…")`. Default `minorEdit` to true;
|
||||
only set false for content rewrites.
|
||||
6. If the diff touched more than the section you set out to change, stop and
|
||||
re-pull the page before posting.
|
||||
|
||||
## Workflow: mirror a markdown file into Confluence
|
||||
|
||||
1. Run the page-reviewer skill first. Mirrors must not introduce slop into a
|
||||
governed space.
|
||||
2. Convert headings from `#`/`## `###` to `h1`/`h2`/`h3`. Strip any leading
|
||||
front-matter — the storage body must not contain `---` fences.
|
||||
3. Strip any path that leaks the local mirror root
|
||||
(`/home/masi1023/Netcracker/Projects/NDO/knowledge/...`). Use the public
|
||||
BASS URL instead.
|
||||
4. Convert `[[wikilinks]]` to plain text or proper Confluence links; the wiki
|
||||
linker only resolves inside BASS.
|
||||
5. Convert fenced code blocks to `<ac:structured-macro
|
||||
ac:name="code"><ac:parameter ac:name="language">…</ac:parameter><ac:plain-text-body><![CDATA[ … ]]></ac:plain-text-body></ac:structured-macro>`.
|
||||
6. Run the dry-run script.
|
||||
|
||||
## Body format cheatsheet
|
||||
|
||||
The MCP server expects a UTF-8 file containing a fragment of storage XHTML.
|
||||
Common elements:
|
||||
|
||||
| You want | Storage format |
|
||||
|----------|----------------|
|
||||
| Heading | `<h2>…</h2>` |
|
||||
| Paragraph | `<p>…</p>` |
|
||||
| Bold / italic | `<strong>…</strong>` / `<em>…</em>` |
|
||||
| List | `<ul><li>…</li></ul>` / `<ol><li>…</li></ol>` |
|
||||
| Table | `<table><tbody><tr><th>…</th><td>…</td></tr></tbody></table>` |
|
||||
| Info panel | `<ac:structured-macro ac:name="info"><ac:rich-text-body>…</ac:rich-text-body></ac:structured-macro>` |
|
||||
| Code block | `<ac:structured-macro ac:name="code" ac:name="language">…</ac:structured-macro>` |
|
||||
| PlantUML | `<ac:structured-macro ac:name="plantuml"><ac:plain-text-body><![CDATA[@startuml … @enduml]]></ac:plain-text-body></ac:structured-macro>` |
|
||||
| Link | `<a href="https://…">label</a>` |
|
||||
| Page link | `<ac:link><ri:page ri:content-title="…"/></ac:link>` |
|
||||
|
||||
Full macro catalog: [references/macros.md](references/macros.md).
|
||||
|
||||
## Picking the parent page
|
||||
|
||||
- Top-level page under the space home: omit `parentId` (MCP defaults to the
|
||||
space home) or pass the space home id explicitly.
|
||||
- Nested under a hub or domain page: find the parent id with
|
||||
`confluence_search(cql="space=AVP AND title~\"Hub\"")` and pick by hand.
|
||||
- Moving a page later is a separate API call; do not "fix" the parent by
|
||||
deleting and recreating — that loses history, watchers, and reactions.
|
||||
|
||||
## Picking the space
|
||||
|
||||
| Content kind | Space |
|
||||
|--------------|-------|
|
||||
| NDO product docs | `AVP` |
|
||||
| Internal team / governance / how-to | `BASS` |
|
||||
| Customer-facing release notes | check with the page owner |
|
||||
| Personal scratch | do **not** post to BASS / AVP; keep in `~/Netcracker/Projects/NDO/knowledge/` |
|
||||
|
||||
If unsure, ask before posting.
|
||||
|
||||
## MCP availability
|
||||
|
||||
`mcp-atlassian` is listed in the
|
||||
[BASS Cursor MCPs approval page](https://bass.netcracker.com/display/~seby0316/Cursor+-+MCPs+approval+status)
|
||||
as *Not approved* by default — that page was last synced 2026-06-11; check the
|
||||
current status before relying on it. The skill assumes the MCP server is wired
|
||||
into the active Claude / Cursor client. Run `scripts/check-mcp-atlassian.sh`
|
||||
to detect it and get an install hint if missing.
|
||||
|
||||
## Safety
|
||||
|
||||
- **Read-only on `~/Netcracker/Projects/NDO/knowledge/confluence/<SPACE>/`.**
|
||||
Mirrors are snapshots. Never edit them in place — re-pull instead.
|
||||
- **Drafts live under `confluence/drafts/`** and are the only files this
|
||||
skill writes to by default.
|
||||
- **No page deletion** through this skill. Deletes are not undoable and lose
|
||||
history. If a page must go, ask in the page's comments first.
|
||||
- **Never paste body content into the API call** — pass a file path so the
|
||||
body stays reviewable in git.
|
||||
|
||||
## Related
|
||||
|
||||
| Skill | Role |
|
||||
|-------|------|
|
||||
| `page-reviewer` | Mandatory pre-post gate; runs before any create/update |
|
||||
| `unslop` | Removes AI phrasing so the page reads as Netcracker voice |
|
||||
| `diagram-plantuml` | Owns the `{plantuml}` macro and the diagram macro catalog |
|
||||
| `confluence-to-slides` (existing) | Pulls a finished page into a slide deck |
|
||||
@@ -0,0 +1,68 @@
|
||||
# Attachments
|
||||
|
||||
Attachments live on a page and are referenced by filename. They survive page
|
||||
moves and template changes, but they do not survive page deletion.
|
||||
|
||||
## Upload via mcp-atlassian
|
||||
|
||||
```python
|
||||
mcp__atlassian.confluence_upload_attachment(
|
||||
pageId=…,
|
||||
filePath="path/to/file.png",
|
||||
comment="optional version note",
|
||||
)
|
||||
```
|
||||
|
||||
Returns a metadata object including the download URL. Use that URL inside the
|
||||
page body, not a local file path.
|
||||
|
||||
## Reference in the body
|
||||
|
||||
By attachment filename:
|
||||
|
||||
```xml
|
||||
<ac:link>
|
||||
<ri:attachment ri:filename="diagram.png" />
|
||||
<ac:plain-text-link-body><![CDATA[diagram]]></ac:plain-text-link-body>
|
||||
</ac:link>
|
||||
```
|
||||
|
||||
As an inline image:
|
||||
|
||||
```xml
|
||||
<ac:image ac:width="600">
|
||||
<ri:attachment ri:filename="diagram.png" />
|
||||
</ac:image>
|
||||
```
|
||||
|
||||
Always set `ac:alt` for accessibility:
|
||||
|
||||
```xml
|
||||
<ac:image ac:width="600">
|
||||
<ri:attachment ri:filename="diagram.png" />
|
||||
<ac:alt>Sequence diagram of the order → inventory → shipment flow.</ac:alt>
|
||||
</ac:image>
|
||||
```
|
||||
|
||||
## What NOT to do
|
||||
|
||||
- Don't paste base64 PNG into the body. The page editor can't replace it
|
||||
without re-rendering the whole page; it bloats the storage body; the page
|
||||
cannot be reviewed by lint.
|
||||
- Don't link to a public CDN. BASS pages are private; CDN URLs leak and break
|
||||
on access-controlled spaces.
|
||||
- Don't re-upload the same file under a new name. Confluence deduplicates by
|
||||
hash within a page, but the editor doesn't surface duplicates well.
|
||||
|
||||
## Versioning
|
||||
|
||||
Attach with a version suffix (`diagram-v2.png`) when updating. Confluence
|
||||
keeps the old version in the attachments list and the page body continues to
|
||||
reference the filename; change the filename in the body to point at the new
|
||||
version.
|
||||
|
||||
## Cleanup
|
||||
|
||||
Pages with stale attachments show up in the space's attachment report. When
|
||||
removing a diagram, also remove the attachment (do not leave orphaned files
|
||||
on the page).
|
||||
@@ -0,0 +1,112 @@
|
||||
# Confluence Storage Macros
|
||||
|
||||
Confluence Cloud storage format accepts a fixed set of macros. Anything not in
|
||||
this catalog either renders as plain text or fails silently. Before adding a
|
||||
new macro to a draft, check the name here.
|
||||
|
||||
## Inline
|
||||
|
||||
| Macro | When |
|
||||
|-------|------|
|
||||
| `{code}` | Fenced code with optional language |
|
||||
| `{plantuml}` | Diagrams — see `diagram-plantuml` skill |
|
||||
| `{info}` | Info panel |
|
||||
| `{note}` | Note panel |
|
||||
| `{warning}` | Warning panel |
|
||||
| `{tip}` | Tip panel |
|
||||
| `{excerpt}` | Reusable fragment; also `excerpt-include` |
|
||||
| `{anchor}` | Inline anchor for `{pageref}` |
|
||||
| `{pageref}` | Cross-page reference by anchor |
|
||||
| `{children}` | Lists child pages |
|
||||
| `{include}` | Includes another page (full or excerpt) |
|
||||
| `{table-of-content}` | Outline from heading hierarchy |
|
||||
| `{expand}` | Collapsible section |
|
||||
| `{status}` | Coloured status pill |
|
||||
| `{cheese}` | Image gallery — prefer `image` element instead |
|
||||
| `{noformat}` | Plain monospace, no language hint |
|
||||
|
||||
## Panels
|
||||
|
||||
Panels take rich-text bodies. PlantUML inside a panel does not render — put
|
||||
diagrams at body root.
|
||||
|
||||
```xml
|
||||
<ac:structured-macro ac:name="info">
|
||||
<ac:rich-text-body>
|
||||
<p>Body goes here.</p>
|
||||
</ac:rich-text-body>
|
||||
</ac:structured-macro>
|
||||
```
|
||||
|
||||
Available panel macros: `info`, `note`, `warning`, `tip`, `success`,
|
||||
`error`, `panel` (generic).
|
||||
|
||||
## Code block
|
||||
|
||||
```xml
|
||||
<ac:structured-macro ac:name="code">
|
||||
<ac:parameter ac:name="language">python</ac:parameter>
|
||||
<ac:parameter ac:name="title">example.py</ac:parameter>
|
||||
<ac:parameter ac:name="linenumbers">true</ac:parameter>
|
||||
<ac:plain-text-body><![CDATA[def hello():
|
||||
pass]]></ac:plain-text-body>
|
||||
</ac:structured-macro>
|
||||
```
|
||||
|
||||
`language` accepts the short names from Confluence's language list (`python`,
|
||||
`java`, `javascript`, `typescript`, `go`, `bash`, `sql`, `json`, `yaml`,
|
||||
`xml`, `markdown`). Anything outside the list falls back to plain monospace.
|
||||
|
||||
## Tables
|
||||
|
||||
Standard XHTML tables. Confluence does not need the `<ac:structured-macro
|
||||
ac:name="table">` wrapper for plain tables.
|
||||
|
||||
```xml
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Column A</th>
|
||||
<th>Column B</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>cell</td>
|
||||
<td>cell</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
```
|
||||
|
||||
For sortable or filterable tables, use the `table-plus` macro — but only
|
||||
when the table is genuinely worth the overhead.
|
||||
|
||||
## Links
|
||||
|
||||
- External: `<a href="https://…">label</a>`
|
||||
- Page by title: `<ac:link><ri:page ri:content-title="Hub"/></ac:link>`
|
||||
- Page by id: `<ac:link><ri:page ri:content-id="12345"/></ac:link>`
|
||||
- Attachment: `<ac:link><ri:attachment ri:filename="diagram.png"/></ac:link>`
|
||||
- User mention: `<ac:link><ri:user ri:username="marcos"/></ac:link>`
|
||||
|
||||
## Attachments
|
||||
|
||||
Attachments go through `mcp__atlassian.confluence_upload_attachment` /
|
||||
`confluence_create_page_from_file` (with the file path) — never as base64 in
|
||||
the body. See `attachments.md`.
|
||||
|
||||
## What is NOT a macro
|
||||
|
||||
| Construct | Status |
|
||||
|-----------|--------|
|
||||
| Wiki markup (`{code}…{code}`) | Renders only on pages whose renderer is set to wiki; do not assume |
|
||||
| Markdown fences | Not interpreted; render as text |
|
||||
| HTML5 `<details>` | Rendered as plain HTML; works but no styling |
|
||||
| Inline SVG | Works but is not editable through the page editor; prefer PlantUML |
|
||||
| `<script>` / `<iframe>` | Stripped by Confluence; do not bother |
|
||||
|
||||
## Naming conventions
|
||||
|
||||
- Macro names are lowercase.
|
||||
- Parameter names are lowercase with words separated by `-`, not `_`
|
||||
(`linenumbers`, not `line_numbers`).
|
||||
- Parameter values that include spaces must be quoted.
|
||||
@@ -0,0 +1,52 @@
|
||||
# Secrets and PII
|
||||
|
||||
A draft that contains any of the patterns below is **BLOCKED** by the
|
||||
`page-reviewer` skill. Scrub before posting; the reviewer's verdict is not
|
||||
overridden by "this is a test fixture" or "this is obvious from context".
|
||||
|
||||
## Hard blocks
|
||||
|
||||
| Pattern | Example | Action |
|
||||
|---------|---------|--------|
|
||||
| AWS access key id | `AKIA[0-9A-Z]{16}` | Replace with `<AWS_KEY>` |
|
||||
| AWS secret access key | `[A-Za-z0-9/+=]{40}` in env files | Replace with `<AWS_SECRET>` |
|
||||
| Bearer / personal token | `ghp_…`, `glpat-…`, `dapi…` | Replace with `<TOKEN>` |
|
||||
| Confluence / Jira token | `ATATT…` (Cloud), long base64 | Replace with `<CONFLUENCE_TOKEN>` |
|
||||
| Slack token | `xoxb-…`, `xoxp-…` | Replace with `<SLACK_TOKEN>` |
|
||||
| OpenAI key | `sk-…` (40+ chars after) | Replace with `<OPENAI_KEY>` |
|
||||
| Service-account password | any string in `*.password=…`, `secret: …` | Replace |
|
||||
| PEM private key | `-----BEGIN … PRIVATE KEY-----` | Replace |
|
||||
| Cookie value | `connect.sid=…`, `JSESSIONID=…` | Replace |
|
||||
|
||||
## Soft blocks (review)
|
||||
|
||||
| Pattern | Why | Action |
|
||||
|---------|-----|--------|
|
||||
| Customer email | PII | Mask: `j***@example.com` or remove |
|
||||
| Customer hostname / IP | PII + internal info | Replace with `<HOST>` / `<IP>` |
|
||||
| Runbook hostname (`*.k8s.sdntest.netcracker.com`) | Internal surface | Use the public URL or `<INTERNAL_HOST>` |
|
||||
| Phone number | PII | Mask or remove |
|
||||
| Bank / payment info | PII | Remove |
|
||||
|
||||
## Why this is in the skill
|
||||
|
||||
BASS Confluence is private to Netcracker, but watchers, exported PDFs, and
|
||||
incident write-ups leak. Pages are also exported to training data when teams
|
||||
mirror content into LLMs. "It's on a private space" is not enough.
|
||||
|
||||
## If you need a realistic-looking fixture
|
||||
|
||||
Generate one with the project's placeholder vocabulary:
|
||||
|
||||
- emails: `user1@example.com`, `user2@example.com`
|
||||
- IPs: `10.0.0.1`, `192.0.2.1`
|
||||
- tokens: `<TOKEN>`, `<SECRET>`
|
||||
- hostnames: `host-a.internal`, `host-b.internal`
|
||||
|
||||
Do not use the customer's name, the production hostname, or a real-looking
|
||||
token "because it doesn't matter".
|
||||
|
||||
## What the reviewer checks
|
||||
|
||||
The `page-reviewer` skill runs a grep pass against this list. A single hit
|
||||
returns **BLOCK**; the author fixes the draft and re-runs.
|
||||
@@ -0,0 +1,25 @@
|
||||
# BASS Space Keys
|
||||
|
||||
The BASS / AVP space keys used by `mcp__atlassian.confluence_*` calls.
|
||||
|
||||
| Space key | Name | Use it for |
|
||||
|-----------|------|------------|
|
||||
| `AVP` | NDO space | NDO product docs, hub pages, runbooks |
|
||||
| `BASS` | Netcracker Confluence | Internal team / governance / how-to / Cursor / MCP pages |
|
||||
| `NDO` | (legacy) | Old NDO content; new writes go to `AVP` |
|
||||
| `GF` | GFiber space | GFiber product content; the gfiber-logging skill targets here |
|
||||
| `NCM` | NCM space | NCM product content |
|
||||
| `~seby0316` | Personal space | Sebastián; the Cursor MCPs page lives here |
|
||||
|
||||
When in doubt, search for a similar page and use the same one. The mirror
|
||||
index at `~/Netcracker/Projects/NDO/knowledge/confluence/_index.md` lists the
|
||||
spaces already in use locally.
|
||||
|
||||
## Picking a space
|
||||
|
||||
- **Top-level product page** → the product space (`AVP` for NDO).
|
||||
- **Internal how-to / governance / Cursor / MCP** → `BASS`.
|
||||
- **Customer-facing release notes** → check with the page owner; the
|
||||
default is `doc.netcracker.com` not BASS.
|
||||
- **Personal scratch** → do not post to BASS / AVP; keep in
|
||||
`~/Netcracker/Projects/NDO/knowledge/confluence/drafts/`.
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: diagram-plantuml
|
||||
description: Embed PlantUML diagrams inside a Confluence page using the {plantuml} macro in the storage body. Use when a page needs a sequence, component, class, state, activity, deployment, or timing diagram and the macro name is not in the caller's muscle memory.
|
||||
---
|
||||
|
||||
# Diagram — PlantUML in Confluence
|
||||
|
||||
PlantUML renders server-side on the Confluence PlantUML plugin. The macro is
|
||||
`{plantuml}`, the body is plain PlantUML between `@startuml` and `@enduml`,
|
||||
and the host (BASS) renders it through the bundled plugin — no external URL
|
||||
needed for private spaces.
|
||||
|
||||
## Hard rules
|
||||
|
||||
- **Macro name is `plantuml`**, lowercase. `{PlantUML}` and `{plantUml}` both
|
||||
fail to render.
|
||||
- **Body goes inside `<ac:plain-text-body><![CDATA[ … ]]></ac:plain-text-body>`**,
|
||||
not inside `<ac:rich-text-body>`. The rich-text body treats the body as
|
||||
XHTML, which mangles `<`, `>`, and `&` that PlantUML relies on.
|
||||
- **Always include `@startuml` and `@enduml`** even though PlantUML accepts
|
||||
bodies without them. The Confluence renderer is stricter than the CLI.
|
||||
- **No diagram wider than ~900 px.** Confluence content columns are narrow;
|
||||
a wide diagram overflows on smaller screens. Split or simplify.
|
||||
- **No diagram inside an info / note / warning panel.** The renderer nests
|
||||
and crops. Put the diagram at body root, then put a `{tip}` after it with
|
||||
the takeaway.
|
||||
- **No diagram inside a code block.** Same nesting failure.
|
||||
- **Never paste a base64 PNG into the body** to skip PlantUML. If PlantUML
|
||||
can't render what you drew, simplify the diagram.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<ac:structured-macro ac:name="plantuml">
|
||||
<ac:plain-text-body><![CDATA[@startuml
|
||||
!theme plain
|
||||
skinparam dpi 150
|
||||
|
||||
participant Client
|
||||
participant Service
|
||||
|
||||
Client -> Service: request
|
||||
Service --> Client: response
|
||||
@enduml]]></ac:plain-text-body>
|
||||
</ac:structured-macro>
|
||||
```
|
||||
|
||||
The `!theme plain` directive keeps diagrams legible on the BASS light
|
||||
background; the `skinparam dpi 150` is the right size for the Confluence
|
||||
column width. Drop both when a diagram already has its own `skinparam`
|
||||
block.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Decide the diagram type. See [references/diagram-types.md](references/diagram-types.md)
|
||||
for the cheat sheet (sequence, component, class, state, activity,
|
||||
deployment, timing, use case, ER, mindmap).
|
||||
2. Draft the PlantUML in a `.puml` scratch file. Run `plantuml -tpng -checkonly
|
||||
-failfast2 file.puml` if `plantuml` is on `$PATH` — fast feedback loop
|
||||
before posting.
|
||||
3. Wrap in the storage template above.
|
||||
4. Add a one-line caption directly after the macro using a `{tip}` block or
|
||||
a bolded sentence; do not rely on the title attribute (some renderers
|
||||
strip it).
|
||||
5. Hand the body to the `page-reviewer` skill. The reviewer re-runs the
|
||||
syntax check on every `{plantuml}` block.
|
||||
|
||||
## Common patterns
|
||||
|
||||
- **Sequence with notes:** use `note left of Alice: …` / `note right of
|
||||
Bob: …`. Inside an `alt`/`opt`/`loop` block, the note attaches to the
|
||||
branch.
|
||||
- **Component / C4:** use `!include <C4_Container>` only if the BASS PlantUML
|
||||
plugin has the C4 stdlib. If unsure, prefer hand-drawn `component` arrows.
|
||||
- **State:** use `state "Long label" as S1` to avoid breaking state names
|
||||
that contain spaces.
|
||||
- **Timing:** use `robust` for digital signals and `analog` for continuous;
|
||||
mixing them on one line is a render error.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Likely cause |
|
||||
|---------|--------------|
|
||||
| Macro renders as plain text | Macro name wrong, or the body is inside `<ac:rich-text-body>` instead of `<ac:plain-text-body>` |
|
||||
| Diagram renders empty | `@startuml / @enduml missing, or body has unescaped < / >` outside CDATA |
|
||||
| Diagram crops on the right | Width over the column budget — split or simplify |
|
||||
| Theme reverts to dark on dark space | Use `!theme plain` explicitly; some renderers ignore the page theme |
|
||||
| C4 include fails | Plugin doesn't ship the stdlib — switch to hand-drawn arrows |
|
||||
|
||||
Full troubleshooting table: [references/troubleshooting.md](references/troubleshooting.md).
|
||||
|
||||
## Related
|
||||
|
||||
| Skill | Role |
|
||||
|-------|------|
|
||||
| `confluence-page` | Owns the storage body; delegates diagrams here |
|
||||
| `page-reviewer` | Re-runs the syntax check on every `{plantuml}` block |
|
||||
@@ -0,0 +1,153 @@
|
||||
# PlantUML Diagram Types
|
||||
|
||||
The eight diagrams the Confluence page author reaches for, with the
|
||||
PlantUML skeleton for each. Pick the type by what the reader needs to
|
||||
*do* with the diagram, not by what the data looks like.
|
||||
|
||||
| Reader needs | Pick |
|
||||
|--------------|------|
|
||||
| Trace a request across actors | sequence |
|
||||
| Show who owns which service | component |
|
||||
| Show static structure / inheritance | class |
|
||||
| Show valid states of one object | state |
|
||||
| Show branching workflow | activity |
|
||||
| Show deployment topology | deployment |
|
||||
| Show signal timing / concurrency | timing |
|
||||
| Show domain entities | ER |
|
||||
|
||||
## Sequence
|
||||
|
||||
```
|
||||
@startuml
|
||||
participant Client
|
||||
participant Service
|
||||
participant DB
|
||||
|
||||
Client -> Service: request
|
||||
Service -> DB: query
|
||||
DB --> Service: rows
|
||||
Service --> Client: response
|
||||
@enduml
|
||||
```
|
||||
|
||||
## Component
|
||||
|
||||
```
|
||||
@startuml
|
||||
[Web] --> [API]
|
||||
[API] --> [DB]
|
||||
[API] --> [Cache]
|
||||
@enduml
|
||||
```
|
||||
|
||||
For C4, prefer hand-drawn boxes if the BASS PlantUML plugin doesn't ship the
|
||||
`C4_Container` stdlib. Test with one diagram before committing to the
|
||||
notation.
|
||||
|
||||
## Class
|
||||
|
||||
```
|
||||
@startuml
|
||||
class Order {
|
||||
+id: UUID
|
||||
+status: Status
|
||||
+total(): Money
|
||||
}
|
||||
class LineItem {
|
||||
+sku: string
|
||||
+qty: int
|
||||
}
|
||||
Order "1" *-- "*" LineItem
|
||||
@enduml
|
||||
```
|
||||
|
||||
## State
|
||||
|
||||
```
|
||||
@startuml
|
||||
[*] --> Draft
|
||||
Draft --> Submitted: submit
|
||||
Submitted --> Approved: approve
|
||||
Submitted --> Rejected: reject
|
||||
Approved --> [*]
|
||||
Rejected --> [*]
|
||||
@enduml
|
||||
```
|
||||
|
||||
## Activity
|
||||
|
||||
```
|
||||
@startuml
|
||||
start
|
||||
:parse input;
|
||||
if (valid?) then (yes)
|
||||
:process;
|
||||
else (no)
|
||||
:reject;
|
||||
stop
|
||||
endif
|
||||
:persist;
|
||||
stop
|
||||
@enduml
|
||||
```
|
||||
|
||||
## Deployment
|
||||
|
||||
```
|
||||
@startuml
|
||||
node "k8s prod" {
|
||||
[service-a] --> [service-b]
|
||||
}
|
||||
node "external" {
|
||||
[IdP]
|
||||
}
|
||||
[service-a] --> [IdP]
|
||||
@enduml
|
||||
```
|
||||
|
||||
## Timing
|
||||
|
||||
```
|
||||
@startuml
|
||||
robust "Client" as C
|
||||
robust "Service" as S
|
||||
C is Idle
|
||||
S is Idle
|
||||
@0
|
||||
C is Requesting
|
||||
@5
|
||||
S is Processing
|
||||
@10
|
||||
S is Idle
|
||||
C is Idle
|
||||
@enduml
|
||||
```
|
||||
|
||||
## ER
|
||||
|
||||
```
|
||||
@startuml
|
||||
entity "Order" {
|
||||
*id : UUID
|
||||
--
|
||||
total : Money
|
||||
}
|
||||
entity "LineItem" {
|
||||
*id : UUID
|
||||
--
|
||||
sku : string
|
||||
qty : int
|
||||
}
|
||||
Order ||--o{ LineItem : contains
|
||||
@enduml
|
||||
```
|
||||
|
||||
## What is NOT a use case
|
||||
|
||||
If the diagram needs prose between boxes, it is not a use case. Use a
|
||||
sequence or activity diagram instead.
|
||||
|
||||
## When to use multiple diagrams
|
||||
|
||||
A page that needs two diagrams is fine. A page that needs five is a wall
|
||||
— split the page.
|
||||
@@ -0,0 +1,66 @@
|
||||
# PlantUML Troubleshooting
|
||||
|
||||
Symptoms and fixes for the four classes of rendering failure on BASS
|
||||
Confluence.
|
||||
|
||||
## Macro renders as plain text
|
||||
|
||||
| Cause | Fix |
|
||||
|-------|-----|
|
||||
| Macro name wrong (`PlantUML`, `Plantuml`) | Use `plantuml`, lowercase |
|
||||
| Body inside `<ac:rich-text-body>` | Move to `<ac:plain-text-body>` |
|
||||
| Macro opened but not closed | Add the matching `</ac:structured-macro>` |
|
||||
| Page is in wiki renderer mode | Re-save in storage format (page properties → editor) |
|
||||
|
||||
## Diagram renders empty
|
||||
|
||||
| Cause | Fix |
|
||||
|-------|-----|
|
||||
| `@startuml` / `@enduml` missing | Add both, even if PlantUML accepts bodies without |
|
||||
| Body has unescaped `<` / `>` outside CDATA | Wrap entire body in `<![CDATA[ … ]]>` |
|
||||
| `!include` points to a stdlib the plugin doesn't ship | Replace with hand-drawn equivalent |
|
||||
| File-size limit exceeded (very large diagrams) | Split into multiple diagrams |
|
||||
|
||||
## Diagram crops on the right
|
||||
|
||||
| Cause | Fix |
|
||||
|-------|-----|
|
||||
| Width > ~900 px | Split the diagram horizontally into two, or simplify |
|
||||
| Long labels on long arrows | Shorten labels; move detail to body text |
|
||||
| Padding parameters set too high | Drop `skinparam Padding`, `skinparam Margin` overrides |
|
||||
|
||||
## Theme reverts to dark on dark space
|
||||
|
||||
| Cause | Fix |
|
||||
|-------|-----|
|
||||
| Page theme overrides the diagram theme | Use `!theme plain` explicitly at the top of the body |
|
||||
| BASS theme override | Hard-code colors with `skinparam` per element |
|
||||
|
||||
## C4 / standard library includes fail
|
||||
|
||||
| Cause | Fix |
|
||||
|-------|-----|
|
||||
| Plugin doesn't ship the stdlib | Switch to `component` diagram or hand-drawn boxes |
|
||||
| Include URL is blocked by network policy | Mirror the stdlib locally, use `!include /path/to/C4_Container.puml` (only if the plugin supports it) |
|
||||
|
||||
## Debugging loop
|
||||
|
||||
1. Save the `.puml` body to a file.
|
||||
2. Run `plantuml -tpng -checkonly -failfast2 file.puml`.
|
||||
3. If local parse fails, the body is wrong — fix the syntax.
|
||||
4. If local parse succeeds but Confluence fails, the wrapper is wrong — fix
|
||||
the storage macro form.
|
||||
|
||||
## When to give up on PlantUML
|
||||
|
||||
- The diagram needs interactivity (hover, click). Confluence PlantUML does
|
||||
not support this.
|
||||
- The diagram needs real images (logos, photos). Drop them in via attachment
|
||||
instead.
|
||||
- The diagram needs to be edited by non-technical authors. PlantUML is not
|
||||
the right tool.
|
||||
|
||||
## When to escalate
|
||||
|
||||
- The BASS plugin version changes and breaks a working diagram. Capture the
|
||||
diff, fix the diagram, and update this troubleshooting page.
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
name: page-reviewer
|
||||
description: Audit a Confluence-ready body before it is posted or updated. Use as the last gate before confluence_create_page_from_file or confluence_update_page_from_file; do not post a page that has not been through this skill.
|
||||
---
|
||||
|
||||
# Page reviewer
|
||||
|
||||
A Confluence page is hard to walk back once it's live: watchers, reactions,
|
||||
and links accumulate, and `minorEdit=true` will not save you from a body that
|
||||
embarrasses the team. Run this skill before every create or update.
|
||||
|
||||
The reviewer reads the draft and the page-context, and returns one of three
|
||||
verdicts:
|
||||
|
||||
- **PASS** — body is ready, post it
|
||||
- **REVISE** — specific, line-anchored changes are required before posting
|
||||
- **BLOCK** — something about the draft cannot be fixed locally (wrong space,
|
||||
wrong parent, scope creep, secret leak) — escalate
|
||||
|
||||
The reviewer never edits the draft. It returns a checklist; the human or the
|
||||
`confluence-page` skill applies the changes.
|
||||
|
||||
## Hard rules
|
||||
|
||||
- **No body that contains secrets, tokens, session cookies, customer PII, or
|
||||
internal hostnames** (`*.netcracker.com` internal suffixes are fine in
|
||||
links; IPs, hostnames and ports from runbooks are not). The reviewer
|
||||
blocks on first match.
|
||||
- **No body that references the local mirror path** (`~/Netcracker/Projects/NDO/knowledge/...`).
|
||||
Use the public BASS URL.
|
||||
- **No body larger than 300 lines** without a one-line reason in the draft
|
||||
header. Pages drift; reviewers and readers both lose when they do.
|
||||
- **No body whose title collides with an existing page** under the same
|
||||
parent — see step 2 of the workflow.
|
||||
- **No unrendered macros** — every `{plantuml}`, `{code}`, `{info}`, `{note}`,
|
||||
`{warning}` block must be in its proper storage form (see
|
||||
`confluence-page/references/macros.md`). The reviewer rejects raw wiki
|
||||
markup and raw Markdown inside storage bodies.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Identify the page.** Title, parent, space key, target id (for update).
|
||||
2. **Collision check.** If creating:
|
||||
- `mcp__atlassian.confluence_search(cql="space=<SPACE> AND title~\"<title>\"")`
|
||||
- If a page already exists under the same parent, return **BLOCK** with
|
||||
"title collision — pick a more specific title or update the existing
|
||||
page instead".
|
||||
3. **Pull upstream context.** If updating, fetch the current body with
|
||||
`mcp__atlassian.confluence_get_page_content(pageId)` and diff against the
|
||||
draft. Flag any section that was renamed or deleted upstream and carried
|
||||
forward in the draft without intent.
|
||||
4. **Lint the body.** For each of the checks below, return a line number and
|
||||
a short rationale. See [references/checks.md](references/checks.md) for the
|
||||
full list and severity table.
|
||||
5. **Slop pass.** Run the `unslop` skill on the body. If unslop returns more
|
||||
than 5 fixes for a page under 100 lines, or more than 10 for any page,
|
||||
return **REVISE** — the author should reread, not the agent.
|
||||
6. **Diagram sanity.** For every `{plantuml}` block, parse to a `.puml` temp
|
||||
file and run `plantuml -checkonly -syntax` if `plantuml` is on `$PATH`. If
|
||||
the tool is missing, skip the parse and warn — do not block on a missing
|
||||
optional tool.
|
||||
7. **Render verdict.**
|
||||
|
||||
## Verdict shape
|
||||
|
||||
```
|
||||
PASS:
|
||||
- ready to post; no blocking issues
|
||||
- (optional) minor notes for the author
|
||||
|
||||
REVISE:
|
||||
- L<line>: <rule> — <one-line fix>
|
||||
- L<line>: <rule> — <one-line fix>
|
||||
- ...
|
||||
- estimated fix effort: <s|m|l>
|
||||
|
||||
BLOCK:
|
||||
- <rule>: <what's wrong, what to do instead>
|
||||
- <rule>: ...
|
||||
```
|
||||
|
||||
The verdict is the only thing the calling skill should consume. Everything
|
||||
else (diff, lint output, slop report) goes to stderr / a side file for the
|
||||
human.
|
||||
|
||||
## What the reviewer does NOT do
|
||||
|
||||
- **Edit the draft.** The author or the `confluence-page` skill applies fixes.
|
||||
Reviewer that also edits is hard to audit.
|
||||
- **Post anything.** The reviewer never calls a write MCP tool.
|
||||
- **Judge voice.** Use `unslop` for that. The reviewer enforces structure,
|
||||
safety, and rendering correctness; unslop enforces voice.
|
||||
- **Approve secrets in test data.** Even "obvious" test fixtures get blocked.
|
||||
If you need sample data with realistic-looking identifiers, generate them
|
||||
with the project's standard placeholder vocabulary.
|
||||
|
||||
## Severity table
|
||||
|
||||
| Severity | Returns | Examples |
|
||||
|----------|---------|----------|
|
||||
| Blocker | BLOCK | secret leak, wrong parent, wrong space, title collision, raw wiki markup in storage body |
|
||||
| Major | REVISE | unrendered macro, broken internal link, image without alt text, slop cluster |
|
||||
| Minor | PASS (with note) | inconsistent heading levels, missing one-line summary, sub-optimal anchor text |
|
||||
|
||||
Full rule list: [references/checks.md](references/checks.md).
|
||||
|
||||
## Related
|
||||
|
||||
| Skill | Role |
|
||||
|-------|------|
|
||||
| `confluence-page` | Calls the reviewer before every create/update |
|
||||
| `unslop` | Voice-level pass; the reviewer delegates voice to it |
|
||||
| `diagram-plantuml` | Owns PlantUML syntax; the reviewer delegates diagram parsing to it |
|
||||
@@ -0,0 +1,77 @@
|
||||
# Page Reviewer — Checks
|
||||
|
||||
The full rule list the `page-reviewer` skill runs. Each check has a severity
|
||||
(BLOCKER / MAJOR / MINOR), the pattern it looks for, and the verdict it
|
||||
returns.
|
||||
|
||||
## BLOCKER
|
||||
|
||||
| ID | Rule | How to detect |
|
||||
|----|------|---------------|
|
||||
| `B-SECRET` | Body contains a token, key, password, or PII pattern from `confluence-page/references/secrets.md` | `grep -nE "<patterns>" <draft>` |
|
||||
| `B-MIRROR-PATH` | Body references a local mirror path (`~/Netcracker/Projects/NDO/knowledge/...`) | grep for the root path |
|
||||
| `B-COLLISION` | A page with the same title exists under the same parent | `confluence_search` for the title |
|
||||
| `B-WRONG-SPACE` | Draft targets a space that doesn't match content kind (see `confluence-page/references/space-keys.md`) | manual check by reviewer |
|
||||
| `B-WRONG-FORMAT` | Body is wiki markup or Markdown, not storage XHTML | header doesn't start with `<p`, `<h`, `<ac:`, or `<table`; presence of `---` front-matter fences |
|
||||
| `B-LOCAL-FS-LINK` | Body contains `file://`, `~/`, or `/home/masi1023/` paths | grep |
|
||||
| `B-CUSTOMER-PII` | Customer name, hostname, or payment info in body | grep + manual review |
|
||||
| `B-PARENT-LOOP` | Parent resolves to a descendant of itself | `confluence_get_page` ancestry walk |
|
||||
|
||||
## MAJOR
|
||||
|
||||
| ID | Rule | How to detect |
|
||||
|----|------|---------------|
|
||||
| `M-UNRENDERED-MACRO` | `{plantuml}`, `{code}`, `{info}`, `{note}`, etc. not in proper storage form | grep for unclosed or naked `{...}` macros |
|
||||
| `M-BROKEN-LINK` | Internal link points to a page id that doesn't exist or a URL that 404s | `confluence_search` for the target title; HEAD on the URL |
|
||||
| `M-MISSING-ALT` | Image element without `ac:alt` | grep for `<ac:image` without `ac:alt` |
|
||||
| `M-DIAGRAM-IN-PANEL` | PlantUML block inside an info / note / warning panel | grep + structure check |
|
||||
| `M-DIAGRAM-IN-CODE` | PlantUML block inside a `{code}` block | grep + structure check |
|
||||
| `M-CODE-NO-LANG` | `{code}` block without `language` parameter | grep + structure check |
|
||||
| `M-EMPTY-SECTION` | Section heading followed by nothing or a single sentence | structure walk |
|
||||
| `M-STALE-SECTION` | Section in draft was deleted from upstream since the last pull (update flow) | diff against `confluence_get_page_content` |
|
||||
| `M-SLOP-CLUSTER` | `unslop` skill returns >5 fixes for a 30-line block | unslop report count |
|
||||
| `M-NO-SUMMARY` | First paragraph is missing for a how-to or runbook | structure check |
|
||||
| `M-OVER-300` | Page body is over 300 lines and no justification header exists | `wc -l` |
|
||||
|
||||
## MINOR (PASS with note)
|
||||
|
||||
| ID | Rule | How to detect |
|
||||
|----|------|---------------|
|
||||
| `m-HEADING-LEVEL` | Skipped heading level (h1 → h3 with no h2) | structure walk |
|
||||
| `m-MISSING-ANCHOR` | Cross-page reference without an explicit anchor text | structure walk |
|
||||
| `m-LOOSE-LINK` | "click here", "this link" | grep |
|
||||
| `m-EMOJI-IN-HEADING` | Emoji in headings that (h1 / h2) | grep |
|
||||
| `m-CAPITALIZED-LINE` | Long uppercase run (more than 5 words) | grep |
|
||||
| `m-MULTI-COLON` | Multiple consecutive `:` in a sentence | grep |
|
||||
| `m-RUN-ON-LINE` | A single line over 200 chars | `awk '{ print length, NR }'` |
|
||||
|
||||
## Severity → verdict
|
||||
|
||||
```
|
||||
BLOCKER > 0 → BLOCK
|
||||
MAJOR > 0 → REVISE
|
||||
MINOR > 0 → PASS (with note)
|
||||
```
|
||||
|
||||
A single BLOCKER short-circuits. The reviewer still lists MAJOR / MINOR
|
||||
findings so the author can fix them in the same pass.
|
||||
|
||||
## Diff mode (updates)
|
||||
|
||||
When the reviewer is called for an update, also run:
|
||||
|
||||
| ID | Rule |
|
||||
|----|------|
|
||||
| `D-UNINTENDED-DROP` | A section in the upstream body that the draft does not have (and was not intentionally removed by `versionMessage`) |
|
||||
| `D-UNINTENDED-RENAME` | A heading in the upstream body that the draft has under a different name |
|
||||
| `D-STALE-VERSION` | The `versionMessage` does not match the change set |
|
||||
|
||||
`D-` rules are MAJOR by default; BLOCKER only if the dropped content was
|
||||
flagged as load-bearing by the previous reviewer.
|
||||
|
||||
## What the reviewer does NOT check
|
||||
|
||||
- Correctness of the technical content — that's an SME responsibility
|
||||
- Style / voice — that's `unslop`
|
||||
- Compliance with team conventions outside this list — escalate to the page
|
||||
owner
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
name: unslop
|
||||
description: Strip AI phrasing from prose before it is posted to a Confluence page, sent to a customer, or shared in chat. Use when a draft sounds like it was written by an LLM: ornamental hedging, breathless transitions, vague intensifiers, symmetrical bullet padding, or any of the other tells listed in references/tells.md.
|
||||
---
|
||||
|
||||
# Unslop
|
||||
|
||||
The page-reviewer catches structural problems; this skill catches voice
|
||||
problems. Both run before a page goes live.
|
||||
|
||||
The unslop pass is line-anchored, deterministic, and reversible. It returns a
|
||||
diff-style report; the author or the calling skill applies the changes.
|
||||
|
||||
## Hard rules
|
||||
|
||||
- **Never edit silently.** Every change appears in the report with the line,
|
||||
the original phrase, and the suggested replacement.
|
||||
- **Never invent voice.** The rewrite defaults to short, declarative, and
|
||||
Netcracker-house — see [references/house-style.md](references/house-style.md).
|
||||
- **Don't rewrite technical content.** If a sentence is slop but the
|
||||
technical claim is correct, fix the phrasing, not the claim.
|
||||
- **Don't rewrite quotes.** Code, command output, error messages, and
|
||||
customer-quoted text stay literal.
|
||||
- **Don't touch structured data.** Tables, lists of identifiers, file paths,
|
||||
URLs, and version numbers are not slop.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read the draft. Mark each line with one of: `clean`, `slop`, `unsure`.
|
||||
2. For each `slop` line, look up the tell in
|
||||
[references/tells.md](references/tells.md) and propose a concrete rewrite.
|
||||
3. For each `unsure` line, leave it alone and flag it for the author with a
|
||||
short rationale.
|
||||
4. Cluster check. If more than 5 slop lines appear in a 30-line block, mark
|
||||
the block `rewrite-block` — voice problems cluster, and the author should
|
||||
rewrite that section by hand rather than accept a chain of small fixes.
|
||||
5. Return the report.
|
||||
|
||||
## Report shape
|
||||
|
||||
```
|
||||
# Unslop report — <page slug>
|
||||
|
||||
L<line>: <tell> — <phrase>
|
||||
> <original>
|
||||
+ <proposed rewrite>
|
||||
L<line>: <tell> — <phrase>
|
||||
> <original>
|
||||
+ <proposed rewrite>
|
||||
|
||||
# Rewrite-block sections (cluster of >5 slop lines)
|
||||
- L<start>-L<end>: <section title>
|
||||
|
||||
# Uncertain — author decides
|
||||
- L<line>: <short rationale>
|
||||
```
|
||||
|
||||
The calling skill applies line-by-line fixes; the author rewrites the marked
|
||||
sections.
|
||||
|
||||
## What counts as slop
|
||||
|
||||
Full list with examples in [references/tells.md](references/tells.md). The
|
||||
high-frequency ones:
|
||||
|
||||
| Tell | Example | Fix |
|
||||
|------|---------|-----|
|
||||
| Ornamental hedging | "It's important to note that…" | Delete the preamble. |
|
||||
| Breathless transition | "Let's dive in!" | Replace with the next fact. |
|
||||
| Vague intensifier | "really", "very", "quite" (when not load-bearing) | Delete. |
|
||||
| Symmetric padding | "X is Y. X is also Z. Both X's are…" | Pick the one that matters. |
|
||||
| AI résumé | "With over X years of experience…" | Replace with the actual fact. |
|
||||
| Performative caveat | "It's worth mentioning that…" | Delete or move to the conclusion. |
|
||||
| Marketing tone | "seamlessly", "robust", "powerful", "leverage" | Replace with the specific capability. |
|
||||
| Triplet | "fast, reliable, and scalable" | Pick the one that is actually true, drop the rest. |
|
||||
| Heading question | "Why is X important?" | State the answer, not the question. |
|
||||
| Sign-off | "Hope this helps!", "Let me know if you have questions!" | Delete. |
|
||||
|
||||
## When to refuse
|
||||
|
||||
- The text is a customer-quoted block, a log line, or a code comment — leave
|
||||
it alone.
|
||||
- The text is technical and correct; only the framing is fluffy. Fix the
|
||||
framing, not the substance.
|
||||
- The rewrite would change the meaning. Mark it `unsure` and let the author
|
||||
decide.
|
||||
|
||||
## Related
|
||||
|
||||
| Skill | Role |
|
||||
|-------|------|
|
||||
| `page-reviewer` | Calls unslop as part of the pre-post gate |
|
||||
| `confluence-page` | Uses the report to apply line-by-line fixes |
|
||||
|
||||
## Limitations
|
||||
|
||||
Unslop is a heuristic pass, not a guarantee. A page can be technically
|
||||
slop-free and still sound corporate, and a page that sounds conversational
|
||||
can still be slop-free. Voice is not the only quality dimension; this skill
|
||||
addresses one of them.
|
||||
@@ -0,0 +1,74 @@
|
||||
# Netcracker House Style
|
||||
|
||||
The voice and shape unslop rewrites toward when nothing else is specified.
|
||||
This is the default, not a mandate — pages with a stated owner voice
|
||||
override this list.
|
||||
|
||||
## Sentence
|
||||
|
||||
- Active voice by default.
|
||||
- One idea per sentence. Two if they're tightly coupled.
|
||||
- Sentence length mostly 8–25 words. Long sentences only when the structure
|
||||
is parallel.
|
||||
- No run-on lines (>200 chars) in body paragraphs. Code and tables exempt.
|
||||
|
||||
## Paragraph
|
||||
|
||||
- First sentence carries the claim.
|
||||
- Body sentences support it.
|
||||
- Last sentence ties it to the next paragraph or to a link.
|
||||
- 3–6 sentences for most paragraphs. Lists break up long paragraphs; they do
|
||||
not replace them.
|
||||
|
||||
## Headings
|
||||
|
||||
- Verb-first when possible: "Run the migration" not "Migration".
|
||||
- Question headings only when the body answers the question in the first
|
||||
sentence.
|
||||
- No emoji in h1 / h2. Emoji ok in h3 and below when it's a stable convention.
|
||||
|
||||
## Lists
|
||||
|
||||
- Parallel grammatical form across items.
|
||||
- One concept per item. Two ideas → two items.
|
||||
- Bullet list for unordered; numbered list for steps.
|
||||
|
||||
## Tables
|
||||
|
||||
- Column headers in `Title case`.
|
||||
- Numbers right-aligned in monospace columns; labels left-aligned in prose.
|
||||
- Empty cells get `<empty>` or are filled — never blank.
|
||||
|
||||
## Code
|
||||
|
||||
- Inline code for file names, env vars, commands, identifiers.
|
||||
- Fenced blocks with language tag for anything longer than one line.
|
||||
- Comments inside code blocks explain *why*, not *what*.
|
||||
|
||||
## Links
|
||||
|
||||
- Anchor text describes the destination. "click here" is a smell.
|
||||
- External links open in same tab; the Confluence renderer adds the
|
||||
indicator.
|
||||
- Internal page links by title, not by URL — rename the page and the link
|
||||
follows.
|
||||
|
||||
## Voice
|
||||
|
||||
- First person plural ("we") when the team owns the page.
|
||||
- Third person when describing a component or a product.
|
||||
- Avoid "I" on team-owned pages.
|
||||
- Avoid the passive voice when it hides who did the thing.
|
||||
|
||||
## What unslop does not change
|
||||
|
||||
- Code blocks, command output, error messages, log lines.
|
||||
- Customer quotes (marked as such).
|
||||
- Commit messages, ticket numbers, identifiers.
|
||||
- Acronyms the audience uses.
|
||||
|
||||
## Calibration
|
||||
|
||||
A page rewritten by unslop should pass the "would a senior engineer send
|
||||
this to their team?" test. If yes, ship. If the page still reads corporate,
|
||||
escalate to the owner — unslop is not the right tool for that.
|
||||
@@ -0,0 +1,75 @@
|
||||
# Slop Tells
|
||||
|
||||
A worked catalogue of the phrases that mark prose as AI-generated. The
|
||||
`unslop` skill greps the draft for each row and reports a fix.
|
||||
|
||||
The list is heuristic. A page can match several tells and still read well;
|
||||
a page can match none and still feel corporate. Use this as a checklist, not a
|
||||
verdict.
|
||||
|
||||
## High-frequency tells
|
||||
|
||||
| Tell | Example | Default fix |
|
||||
|------|---------|-------------|
|
||||
| Ornamental hedging | "It's important to note that…" | Delete the preamble |
|
||||
| Breathless transition | "Let's dive in!", "Now, let's explore…" | Replace with the next fact |
|
||||
| Vague intensifier | "really", "very", "quite", "rather" (when not load-bearing) | Delete |
|
||||
| Symmetric padding | "X is Y. X is also Z. Both X's are…" | Pick the one that matters |
|
||||
| AI résumé | "With over X years of experience…" | Replace with the actual fact |
|
||||
| Performative caveat | "It's worth mentioning that…" | Delete or move to the conclusion |
|
||||
| Marketing tone | "seamlessly", "robust", "powerful", "leverage", "cutting-edge" | Replace with the specific capability |
|
||||
| Triplet | "fast, reliable, and scalable" | Pick the one that is actually true |
|
||||
| Heading question | "Why is X important?" | State the answer, not the question |
|
||||
| Sign-off | "Hope this helps!", "Let me know if you have questions!" | Delete |
|
||||
| Throat-clearing | "In this article, we will…" | Delete the article and start with the subject |
|
||||
| Mirror transition | "As we have seen…" | Replace with the actual finding |
|
||||
| Manufactured urgency | "In today's fast-paced world…" | Delete |
|
||||
| Generic closer | "To learn more, contact…" | Replace with the actual link or contact |
|
||||
|
||||
## Mid-frequency
|
||||
|
||||
| Tell | Example | Default fix |
|
||||
|------|---------|-------------|
|
||||
| Bureaucratic noun | "perform a verification of" | "verify" |
|
||||
| Nominalised verb | "the implementation of the feature" | "implementing the feature" |
|
||||
| Possessive hedge | "in our experience" | Drop unless backed by data |
|
||||
| Padded qualifier | "essentially", "basically", "fundamentally", "literally" | Delete |
|
||||
| Redundant pair | "each and every", "first and foremost", "any and all" | Pick one |
|
||||
| Process name as action | "we will be performing a build" | "we will build" |
|
||||
| Apology | "Apologies for the inconvenience" | Replace with the fix |
|
||||
| Hyperbole | "game-changer", "revolutionary", "paradigm shift" | Replace with the actual claim |
|
||||
| Cult of positivity | "We are excited to announce…" | Replace with the news |
|
||||
| Generic advice | "Best practices include…" | Replace with the specific practice |
|
||||
|
||||
## Low-frequency (still flag)
|
||||
|
||||
| Tell | Example | Default fix |
|
||||
|------|---------|-------------|
|
||||
| Anachronism | "in the year 2026" | Drop the year unless it disambiguates |
|
||||
| Self-reference | "this article", "this section", "as stated above" | Replace with the thing |
|
||||
| Passive that hides the actor | "It was decided that…" | "We decided…" |
|
||||
| Telegraphic metaphor | "drowning in data", "needle in a haystack" | Replace with the literal state |
|
||||
| Fake precision | "in 90% of cases" | Replace with the source |
|
||||
|
||||
## What is NOT slop
|
||||
|
||||
- Technical jargon used precisely (`asynchronous`, `idempotent`,
|
||||
`backpressure`).
|
||||
- Repetition for emphasis that the reader actually needs.
|
||||
- Headings that match a list of canonical section titles (`Overview`,
|
||||
`Steps`, `Verification`).
|
||||
- Code, command output, error messages, customer-quoted text.
|
||||
- Acronyms and abbreviations the audience knows.
|
||||
|
||||
## Cluster detection
|
||||
|
||||
Slop tends to cluster. A single slop line in 30 is a minor fix. Five slop
|
||||
lines in 10 means the author wrote the paragraph by stream-of-prompting; the
|
||||
whole section should be rewritten by hand. The `unslop` skill flags cluster
|
||||
sections as `rewrite-block` rather than proposing per-line fixes.
|
||||
|
||||
## When to escalate
|
||||
|
||||
A draft that reads well but uses a non-AAVE corporate voice should not be
|
||||
unslopped into something else; flag it for the author. The skill rewrites
|
||||
*slop*, not *voice*.
|
||||
@@ -0,0 +1,72 @@
|
||||
# How-To — Template
|
||||
|
||||
Use for step-by-step runbooks. Each step is one concrete action with the
|
||||
expected result.
|
||||
|
||||
## Sections
|
||||
|
||||
- Title — verb-first ("Configure TLS on the staging cluster", not "TLS
|
||||
Configuration")
|
||||
- Prerequisites (what must already be true before starting)
|
||||
- Steps (numbered, one action per step, with the expected output)
|
||||
- Verification (the single check that proves the change worked)
|
||||
- Troubleshooting (top 3 things that go wrong, with their fixes)
|
||||
- Related (links to sister how-tos and the owning team page)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't write steps that require a human to interpret them. "Configure the
|
||||
cluster" is not a step.
|
||||
- Don't bury the verification at the end of the page. Put it where the reader
|
||||
will see it after step 1.
|
||||
- Don't use screenshots where commands work. Screenshots go out of date;
|
||||
commands don't.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Verb-first title}</h1>
|
||||
<p>{One sentence: what this how-to does and when to use it.}</p>
|
||||
|
||||
<h2>Prerequisites</h2>
|
||||
<ul>
|
||||
<li>{what must already be true}</li>
|
||||
</ul>
|
||||
|
||||
<h2>Steps</h2>
|
||||
<ol>
|
||||
<li>
|
||||
<p>{action}</p>
|
||||
<p><em>Expected output:</em></p>
|
||||
<ac:structured-macro ac:name="code">
|
||||
<ac:parameter ac:name="language">bash</ac:parameter>
|
||||
<ac:plain-text-body><![CDATA[{expected output}]]></ac:plain-text-body>
|
||||
</ac:structured-macro>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<h2>Verification</h2>
|
||||
<p>{Single check that proves the change worked. If it fails, the rest of the
|
||||
how-to doesn't apply.}</p>
|
||||
|
||||
<h2>Troubleshooting</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Symptom</th>
|
||||
<th>Cause</th>
|
||||
<th>Fix</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{symptom}</td>
|
||||
<td>{cause}</td>
|
||||
<td>{fix}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- Diagrams: `diagram-plantuml/SKILL.md`
|
||||
@@ -0,0 +1,79 @@
|
||||
# Hub Page — Template
|
||||
|
||||
Use for top-level overview / landing pages under a space home.
|
||||
|
||||
## Sections
|
||||
|
||||
- Overview (one paragraph, last sentence ties to the next section)
|
||||
- Latest release (table or list, with link to the release page)
|
||||
- Useful Links (table: Name, Link)
|
||||
- Documentation (table: Document, Link)
|
||||
- Teams & Contacts (bullet list with links to team pages)
|
||||
- Related (links to sister pages)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't duplicate release notes here — link to the release page.
|
||||
- Don't paste the full architecture diagram — link to it.
|
||||
- Don't list every related page — only the ones a reader of this hub will need.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Page Title}</h1>
|
||||
<p>{One-paragraph overview. Last sentence points to "Useful Links" below.}</p>
|
||||
|
||||
<h2>Latest release</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Release</th>
|
||||
<th>Scope</th>
|
||||
<th>Delivery</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><ac:link><ri:page ri:content-title="NDO Release 2026.2"/></ac:link></td>
|
||||
<td><ac:link><ri:page ri:content-title="2026.2 Release Scope"/></ac:link></td>
|
||||
<td>23 June 2026</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Useful Links</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Link</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>JIRA project</td>
|
||||
<td><a href="https://psup.netcracker.com/projects/UNM">UNM</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Documentation</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Document</th>
|
||||
<th>Link</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Admin Guide</td>
|
||||
<td><a href="https://doc.netcracker.com/display/NetworkDomainOrchestrator/...">Admin Guide</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Teams & Contacts</h2>
|
||||
<ul>
|
||||
<li><ac:link><ri:page ri:content-title="NDO Teams"/></ac:link></li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- NDO Hub mirror (real example): `~/Netcracker/Projects/NDO/knowledge/confluence/AVP/network-domain-orchestrator-ndo.md`
|
||||
@@ -0,0 +1,117 @@
|
||||
# Postmortem — Template
|
||||
|
||||
Use for incident write-ups. The structure follows the standard blameless
|
||||
format: what happened, what was supposed to happen, why it didn't, what we
|
||||
change.
|
||||
|
||||
## Sections
|
||||
|
||||
- Summary (two or three sentences: who was affected, for how long, by what)
|
||||
- Impact (the numbers: users, requests, dollars, internal teams)
|
||||
- Timeline (UTC timestamps, one row per significant event)
|
||||
- Root cause (the chain of decisions and conditions that produced the
|
||||
incident; not a single "the bug")
|
||||
- Detection (how we found out, and how long after it started)
|
||||
- Response (what we did, what worked, what didn't)
|
||||
- Recovery (what we did to get back to a steady state)
|
||||
- Lessons (the things we want to remember)
|
||||
- Action items (table with owner, due date, status)
|
||||
- Related (links to the incident ticket, runbook, and follow-up docs)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't assign blame. The postmortem is about the system, not the person.
|
||||
- Don't hide the timeline. The reader's first question is "how long"; the
|
||||
timeline is the answer.
|
||||
- Don't list action items without owners. An action item without an owner
|
||||
is a wish.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Incident title — short, dated}</h1>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Date</th>
|
||||
<td>{YYYY-MM-DD}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Severity</th>
|
||||
<td>{SEV-1 / SEV-2 / SEV-3}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Duration</th>
|
||||
<td>{start} → {end} (UTC)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Incident commander</th>
|
||||
<td>{name}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Summary</h2>
|
||||
<p>{two or three sentences}</p>
|
||||
|
||||
<h2>Impact</h2>
|
||||
<ul>
|
||||
<li>{users affected}</li>
|
||||
<li>{requests failed / throttled}</li>
|
||||
<li>{internal teams paged}</li>
|
||||
</ul>
|
||||
|
||||
<h2>Timeline (UTC)</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Time</th>
|
||||
<th>Event</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{HH:MM}</td>
|
||||
<td>{event}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Root cause</h2>
|
||||
<p>{chain of decisions and conditions}</p>
|
||||
|
||||
<h2>Detection</h2>
|
||||
<p>{how we found out, and how long after the incident started}</p>
|
||||
|
||||
<h2>Response</h2>
|
||||
<p>{what we did}</p>
|
||||
|
||||
<h2>Recovery</h2>
|
||||
<p>{how we got back to steady state}</p>
|
||||
|
||||
<h2>Lessons</h2>
|
||||
<ul>
|
||||
<li>{lesson}</li>
|
||||
</ul>
|
||||
|
||||
<h2>Action items</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Action</th>
|
||||
<th>Owner</th>
|
||||
<th>Due</th>
|
||||
<th>Status</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{action}</td>
|
||||
<td>{owner}</td>
|
||||
<td>{YYYY-MM-DD}</td>
|
||||
<td>{OPEN / DONE}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- BASS / AVP page hierarchy — see the owning team's incident process doc
|
||||
@@ -0,0 +1,105 @@
|
||||
# RFC — Template
|
||||
|
||||
Use for proposals that need a written decision record. Status field goes at
|
||||
the top so the page reader sees it before the rest.
|
||||
|
||||
## Sections
|
||||
|
||||
- Status (DRAFT / REVIEW / ACCEPTED / REJECTED / SUPERSEDED)
|
||||
- Author + reviewers (the people whose names should be on the proposal)
|
||||
- Context (the problem and why now)
|
||||
- Proposal (the change, in concrete terms)
|
||||
- Alternatives considered (one paragraph each, with the reason rejected)
|
||||
- Risks and mitigations (table)
|
||||
- Rollout plan (phases, owners, rollback)
|
||||
- Open questions (the things still being decided)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't write an RFC without alternatives. A proposal that has no rejected
|
||||
alternatives either didn't think hard enough or didn't consider the reader.
|
||||
- Don't hide the status. The reader's first question is "is this decided?";
|
||||
answer it in the first line.
|
||||
- Don't open questions at the end of the proposal. Put them after the rollout
|
||||
plan, where they don't read as part of the decision.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Title — verb-first}</h1>
|
||||
|
||||
<ac:structured-macro ac:name="status">
|
||||
<ac:parameter ac:name="colour">Yellow</ac:parameter>
|
||||
<ac:parameter ac:name="title">DRAFT</ac:parameter>
|
||||
</ac:structured-macro>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Author</th>
|
||||
<td>{name}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Reviewers</th>
|
||||
<td>{names}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Status</th>
|
||||
<td>DRAFT</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Context</h2>
|
||||
<p>{problem + why now}</p>
|
||||
|
||||
<h2>Proposal</h2>
|
||||
<p>{the change in concrete terms}</p>
|
||||
|
||||
<h2>Alternatives considered</h2>
|
||||
<h3>{Alternative 1}</h3>
|
||||
<p>{why rejected}</p>
|
||||
<h3>{Alternative 2}</h3>
|
||||
<p>{why rejected}</p>
|
||||
|
||||
<h2>Risks and mitigations</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Risk</th>
|
||||
<th>Mitigation</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{risk}</td>
|
||||
<td>{mitigation}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Rollout plan</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Phase</th>
|
||||
<th>Owner</th>
|
||||
<th>Rollback</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{phase}</td>
|
||||
<td>{owner}</td>
|
||||
<td>{how to roll back}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Open questions</h2>
|
||||
<ul>
|
||||
<li>{question}</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- Status colors: `Yellow` (DRAFT), `Blue` (REVIEW), `Green` (ACCEPTED),
|
||||
`Red` (REJECTED), `Grey` (SUPERSEDED)
|
||||
Reference in New Issue
Block a user