程序员 Vasya 正在使用 Bit，这是一个用于存储代码的版本控制系统。Bit 中的修改历史可以看作一个有向无环图（DAG）。该图的节点被称为“版本”（revisions）。当 Vasya 想要修改代码时，他可以基于任意版本 $A$ 进行修改，从而产生一个新版本 $D$。在这种情况下，我们称版本 $D$ 依赖于版本 $A$。Bit 中的每个此类依赖关系都表示为从版本节点 $A$ 指向版本节点 $D$ 的一条有向边。
合并（Merger）是 Bit 中的一种特殊版本类型：Vasya 可以将任意两个版本 $A$ 和 $B$ 合并为一个新版本 $D$。在这种情况下，版本 $D$ 将依赖于两个版本：$A$ 和 $B$。仓库中还包含一个唯一的“初始”（initial）版本：它是唯一不依赖于任何其他版本的版本。Bit 中的所有其他版本都依赖于一个或多个其他版本。Vasya 已经完成了他的项目开发：有且仅有一个版本没有任何依赖它的版本（即没有后继节点）。
但有一天，事情出了差错，代码中出现了 bug。Vasya 正在努力寻找它们。Vasya 的 bug 的表现如下：如果一个 bug 出现在版本 $A$ 中，它会影响 Bit 图中从 $A$ 可达的所有版本：版本 $A$ 本身、所有依赖于 $A$ 的版本、所有依赖于“依赖 $A$ 的版本”的版本，依此类推。为了找到 bug，Vasya 可以切换到不同的版本并检查该版本中是否存在 bug，从而缩小嫌疑范围。最终，他将找到含有该 bug 的最初版本（即该 bug 首次出现的源头版本）。
Vasya 接连不断地收到用户的 bug 报告，他必须一个接一个地找出所有这些 bug。请帮助 Vasya 尽快修复代码。
下图展示了一个包含 9 个版本的示例。版本 1 是初始版本。版本 7、8 和 9 是合并版本，每个版本都依赖于另外两个版本。产生 bug 的版本 2 以及受该 bug 影响的所有依赖版本均用灰色标出。
交互
这是一道交互题。你将与一个特殊的程序——交互器（interactor）进行交互，而不是进行标准的文件输入输出。你将通过标准输入输出流与该程序进行交互。
程序启动后，将通过标准输入流读入关于版本的信息。
第一行包含一个整数 $N$——Bit 中版本的数量（$1 \le N \le 1000$）。
接下来的 $N$ 行包含版本的描述，每行以一个版本号开头——一个由 6 位十六进制数字（数字 0 到 9 以及小写英文字母 'a' 到 'f'）组成的字符串。保证描述中不包含版本号为 000000 的版本。紧接着是一个整数 $k$——当前版本所依赖的版本数量（$0 \le k \le 2$），随后是 $k$ 个用空格分隔的依赖版本号。保证在描述一个新版本时，它所依赖的所有版本的描述都已经给出。
现在 Vasya 必须找到他的 bug。保证代码中总共不超过 10,000 个 bug。
寻找 bug 的过程始于从输入流向你的程序发送的一行，其中包含字符串 bug 和发现新 bug 的版本号。如果给出的版本号为 000000，则表示所有 bug 均已找到，程序必须终止。否则，开始寻找该 bug。
接下来，你的程序必须向标准输出流发送查询。每个查询必须单占一行，包含一个命令和要对该版本执行命令的版本号。命令可以是以下之一：
check— 检查该版本是否存在 bug。如果该版本受 bug 影响，交互器将返回单行bad；如果该版本没有 bug，则返回good。fix— 表示你已经找到了产生 bug 的源头版本。在执行fix命令后，你的程序必须开始寻找下一个 bug。
对于每个 bug，你的程序最多只能进行 20 次查询，否则将获得 Wrong Answer 评测结果。
请确保在每次输出查询后打印换行符并清空输出缓冲区（使用语言的 flush 命令）。否则，程序可能会因超时（Timeout）而终止。
样例
输入样例 1
9 000001 0 000002 1 000001 000003 1 000002 000004 1 000002 000005 1 000003 000006 1 000001 000007 2 000006 000001 000008 2 000004 000005 000009 2 000007 000008 bug 000008 bad good bad bug 000009 bad good bug 000000
输出样例 1
check 000004 check 000001 check 000002 fix 000002 check 000007 check 000006 fix 000007
说明
为了便于阅读，样例中的输入和输出在实际交互中是交替进行的。